summaryrefslogtreecommitdiffstats
path: root/MdePkg/Library/BaseSafeIntLib
Commit message (Collapse)AuthorAgeFilesLines
* MdePkg/BaseSafeIntLib: Add RISCV64 arch for BaseSafeIntLib.Abner Chang2020-05-071-2/+4
| | | | | | | | | | | | | | | | Add RISCV64 arch for BaseSafeIntLib library. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2672 Signed-off-by: Abner Chang <abner.chang@hpe.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Gilbert Chen <gilbert.chen@hpe.com> Cc: Daniel Helmut Schaefer <daniel.schaefer@hpe.com>
* MdePkg/BaseSafeIntLib: Fix VS20xx IA32 link failuresMichael D Kinney2020-02-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2525 SafeUint64Mult() looks for 64-bit overflows and performs several 32-bit multiples with 64-bit results to check for all possible overflow conditions. IA32 builds using VS20xx with optimizations enabled are producing a reference to the _allmull intrinsic. The fix is to use MultU64x64() instead of '*' for these operations. These are safe because the inputs are guaranteed to have the upper 32-bits clear, which means MultU64x64() can never overflow with those inputs. Cc: Liming Gao <liming.gao@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdePkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-095-90/+5
| | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdePkg: Removing ipf which is no longer supported from edk2.Chen A Chen2018-09-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Removing rules for Ipf sources file: * Remove the source file which path with "ipf" and also listed in [Sources.IPF] section of INF file. * Remove the source file which listed in [Components.IPF] section of DSC file and not listed in any other [Components] section. * Remove the embedded Ipf code for MDE_CPU_IPF. Removing rules for Inf file: * Remove IPF from VALID_ARCHITECTURES comments. * Remove DXE_SAL_DRIVER from LIBRARY_CLASS in [Defines] section. * Remove the INF which only listed in [Components.IPF] section in DSC. * Remove statements from [BuildOptions] that provide IPF specific flags. * Remove any IPF sepcific sections. Removing rules for Dec file: * Remove [Includes.IPF] section from Dec. Removing rules for Dsc file: * Remove IPF from SUPPORTED_ARCHITECTURES in [Defines] section of DSC. * Remove any IPF specific sections. * Remove statements from [BuildOptions] that provide IPF specific flags. Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chen A Chen <chen.a.chen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* MdePkg/BaseSafeIntLib: Fix VS2015 IA32 NOOPT build failureDandan Bi2018-02-283-5/+10
| | | | | | | | | | | | | | | | | | | | v2: Add [LibraryClasses] section in INF file and refine coding style. There are VS2015 NOOPT IA32 build failure like below in BaseSafeIntLib. XXX.lib(XXX.obj): error LNK2001: unresolved external symbol __allmul XXX.lib(XXX.obj): error LNK2001: unresolved external symbol __allshl XXX.lib(XXX.obj): error LNK2001: unresolved external symbol __aullshr This patch replaces direct shift/multiplication of 64-bit integer with related function call to fix these failure. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* MdePkg/BaseSafeIntLib: fix undefined behavior in SafeInt64Mult()Laszlo Ersek2018-02-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we have to negate UnsignedResult (due to exactly one of Multiplicand and Multiplier being negative), and UnsignedResult is exactly MIN_INT64_MAGNITUDE (value 2^63), then the statement *Result = - ((INT64)UnsignedResult); invokes both implementation-defined behavior and undefined behavior. First, MIN_INT64_MAGNITUDE is not representable as INT64, therefore the result of the (inner) conversion (INT64)MIN_INT64_MAGNITUDE is implementation-defined, or an implementation-defined signal is raised, according to ISO C99 6.3.1.3p3. Second, if we assume that the C language implementation defines the conversion to INT64 simply as reinterpreting the bit pattern 0x8000_0000_0000_0000 as a signed integer in two's complement representation, then the conversion immediately produces the negative value MIN_INT64 (value -(2^63)). In turn, the (outer) negation -(MIN_INT64) invokes undefined behavior, because the mathematical result of the negation, namely 2^63, cannot be represented in an INT64 object. (Not even mentioning the fact that the mathematical result would be incorrect.) In practice, the undefined negation of MIN_INT64 happens to produce an unchanged, valid-looking result on x86, i.e. (-(MIN_INT64)) == MIN_INT64. We can summarize this as the undefined -- effectless -- negation canceling out the botched -- auto-negating -- implementation-defined conversion. Instead of relying on such behavior, dedicate a branch to this situation: assign MIN_INT64 directly. The branch can be triggered e.g. by multiplying (2^62) by (-2). Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* MdePkg/BaseSafeIntLib: clean up parentheses in MIN_INT64_MAGNITUDELaszlo Ersek2018-02-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The definition of the MIN_INT64_MAGNITUDE macro is correct, but it's harder to read than necessary: the sub-expression (( (UINT64) - (MIN_INT64 + 1) )) is doubly parenthesized. Reusing one pair of the outer parens, rewrite the sub-expression (without change in meaning) so that the minus sign cannot be mistaken for subtraction: ( (UINT64)(- (MIN_INT64 + 1)) ) The resultant macro definition matches the following expressions in SafeInt64Mult(): > // > // Avoid negating the most negative number. > // > UnsignedMultiplicand = ((UINT64)(- (Multiplicand + 1))) + 1; and > // > // Avoid negating the most negative number. > // > UnsignedMultiplier = ((UINT64)(- (Multiplier + 1))) + 1; Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* MdePkg/BaseSafeIntLib: fix undefined behavior in SafeInt64Add()Laszlo Ersek2018-02-211-10/+46
| | | | | | | | | | | | | | | | | | | | | | | | | The addition in the assignment SignedResult = Augend + Addend; is performed with unchecked INT64 operands. According to ISO C, if the mathematical result of signed integer addition cannot be represented in the result type, the behavior is undefined. (Refer to ISO C99 6.5p5. 6.2.5p9 only exempts unsigned integers, and 6.3.1.3p3 does not apply because it treats the conversion of integers that have been successfully evaluated first.) Replace the after-the-fact result checking with checks on the operands, and only perform the addition if it is safe. Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* MdePkg/BaseSafeIntLib: fix undefined behavior in SafeInt64Sub()Laszlo Ersek2018-02-211-11/+39
| | | | | | | | | | | | | | | | | | | | | | | | | The subtraction in the assignment SignedResult = Minuend - Subtrahend; is performed with unchecked INT64 operands. According to ISO C, if the mathematical result of signed integer subtraction cannot be represented in the result type, the behavior is undefined. (Refer to ISO C99 6.5p5. 6.2.5p9 only exempts unsigned integers, and 6.3.1.3p3 does not apply because it treats the conversion of integers that have been successfully evaluated first.) Replace the after-the-fact result checking with checks on the operands, and only perform the subtraction if it is safe. Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* MdePkg/BaseSafeIntLib: Add SafeIntLib class and instanceSean Brogan2018-01-255-0/+5832
https://bugzilla.tianocore.org/show_bug.cgi?id=798 SafeIntLib provides helper functions to prevent integer overflow during type conversion, addition, subtraction, and multiplication. Conversion Functions ==================== * Converting from a signed type to an unsigned type of the same size, or vice-versa. * Converting to a smaller type that could possibly overflow. * Converting from a signed type to a larger unsigned type. Unsigned Addition, Subtraction, Multiplication =============================================== * Unsigned integer math functions protect from overflow and underflow (in case of subtraction). Signed Addition, Subtraction, Multiplication ============================================ * Strongly consider using unsigned numbers. * Signed numbers are often used where unsigned numbers should be used. For example file sizes and array indices should always be unsigned. Subtracting a larger positive signed number from a smaller positive signed number with SafeInt32Sub() will succeed, producing a negative number, that then must not be used as an array index (but can occasionally be used as a pointer index.) Similarly for adding a larger magnitude negative number to a smaller magnitude positive number. * SafeIntLib does not protect you from such errors. It tells you if your integer operations overflowed, not if you are doing the right thing with your non-overflowed integers. * Likewise you can overflow a buffer with a non-overflowed unsigned index. Based on content from the following branch/commits: https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport https://github.com/Microsoft/MS_UEFI/commit/21ef3a321c907b40fa93797619c9f6c686dd92e0 https://github.com/Microsoft/MS_UEFI/commit/ca516b1a61315c2d823f453e12d2135098f53d61 https://github.com/Microsoft/MS_UEFI/commit/33bab4031a417d7d5a7d356c15a14c2e60302b2d Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Sean Brogan <sean.brogan@microsoft.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-24 11:30:06 +0000