From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 1915B81F1B for ; Tue, 24 Jan 2017 16:25:42 -0800 (PST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 24 Jan 2017 16:25:41 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,281,1477983600"; d="scan'208";a="1086915099" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga001.jf.intel.com with ESMTP; 24 Jan 2017 16:25:41 -0800 Received: from fmsmsx116.amr.corp.intel.com (10.18.116.20) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 24 Jan 2017 16:25:40 -0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx116.amr.corp.intel.com (10.18.116.20) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 24 Jan 2017 16:25:40 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.59]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.177]) with mapi id 14.03.0248.002; Wed, 25 Jan 2017 08:25:38 +0800 From: "Wu, Hao A" To: Laszlo Ersek CC: "edk2-devel@ml01.01.org" Thread-Topic: [edk2] [PATCH v2 1/1] MdePkg: Refine casting expression result to bigger size Thread-Index: AQHSdhMdLgxhYXrFVkSlzlTDD01IpKFG3UQAgAF28kA= Date: Wed, 25 Jan 2017 00:25:37 +0000 Message-ID: References: <1485242740-10244-1-git-send-email-hao.a.wu@intel.com> <1485242740-10244-2-git-send-email-hao.a.wu@intel.com> <04973bde-e5f1-42fc-fa73-f74aac9d5553@redhat.com> In-Reply-To: <04973bde-e5f1-42fc-fa73-f74aac9d5553@redhat.com> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [PATCH v2 1/1] MdePkg: Refine casting expression result to bigger size X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 00:25:42 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Laszlo Ersek [mailto:lersek@redhat.com] > Sent: Tuesday, January 24, 2017 5:54 PM > To: Wu, Hao A > Cc: edk2-devel@ml01.01.org > Subject: Re: [edk2] [PATCH v2 1/1] MdePkg: Refine casting expression resu= lt to > bigger size >=20 > On 01/24/17 08:25, Hao Wu wrote: > > There are cases that the operands of an expression are all with rank le= ss > > than UINT64/INT64 and the result of the expression is explicitly casted= to > > UINT64/INT64 to fit the target size. > > > > An example will be: > > UINT32 a,b; > > // a and b can be any unsigned int type with rank less than UINT64, lik= e > > // UINT8, UINT16, etc. > > UINT64 c; > > c =3D (UINT64) (a + b); > > > > Some static code checkers may warn that the expression result might > > overflow within the rank of "int" (integer promotions) and the result i= s > > then cast to a bigger size. > > > > The commit refines codes by the following rules: > > 1). When the expression will not overflow within the rank of "int", rem= ove > > the explicit type casts: > > c =3D a + b; > > > > 2). When the expression is possible to overflow the range of unsigned i= nt/ > > int: > > c =3D (UINT64)a + b; > > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Hao Wu > > --- > > MdePkg/Library/BaseLib/String.c | 4 ++-- > > MdePkg/Library/BasePeCoffLib/BasePeCoff.c | 12 ++++= +------- > > MdePkg/Library/BaseS3PciLib/S3PciLib.c | 4 ++-- > > MdePkg/Library/SmmMemoryAllocationLib/MemoryAllocationLib.c | 4 ++-- > > MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c | 4 ++-- > > 5 files changed, 13 insertions(+), 15 deletions(-) > > > > diff --git a/MdePkg/Library/BaseLib/String.c > b/MdePkg/Library/BaseLib/String.c > > index e84bf50..4151e0e 100644 > > --- a/MdePkg/Library/BaseLib/String.c > > +++ b/MdePkg/Library/BaseLib/String.c > > @@ -586,7 +586,7 @@ InternalHexCharToUintn ( > > return Char - L'0'; > > } > > > > - return (UINTN) (10 + InternalCharToUpper (Char) - L'A'); > > + return (10 + InternalCharToUpper (Char) - L'A'); > > } > > > > /** > > @@ -1211,7 +1211,7 @@ InternalAsciiHexCharToUintn ( > > return Char - '0'; > > } > > > > - return (UINTN) (10 + InternalBaseLibAsciiToUpper (Char) - 'A'); > > + return (10 + InternalBaseLibAsciiToUpper (Char) - 'A'); > > } > > > > > > diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c > b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c > > index 33cad23..8d1daba 100644 > > --- a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c > > +++ b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c > > @@ -15,7 +15,7 @@ > > PeCoffLoaderGetPeHeader() routine will do basic check for PE/COFF he= ader. > > PeCoffLoaderGetImageInfo() routine will do basic check for whole PE/= COFF > image. > > > > - Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved. > > + Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved. > > Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.<= BR> > > This program and the accompanying materials > > are licensed and made available under the terms and conditions of th= e BSD > License > > @@ -703,12 +703,10 @@ PeCoffLoaderGetImageInfo ( > > // > > DebugDirectoryEntryFileOffset =3D 0; > > > > - SectionHeaderOffset =3D (UINTN)( > > - ImageContext->PeCoffHeaderOffset + > > - sizeof (UINT32) + > > - sizeof (EFI_IMAGE_FILE_HEADER) + > > - Hdr.Pe32->FileHeader.SizeOfOptionalHead= er > > - ); > > + SectionHeaderOffset =3D ImageContext->PeCoffHeaderOffset + > > + sizeof (UINT32) + > > + sizeof (EFI_IMAGE_FILE_HEADER) + > > + Hdr.Pe32->FileHeader.SizeOfOptionalHeader; > > > > for (Index =3D 0; Index < Hdr.Pe32->FileHeader.NumberOfSections;= Index++) > { > > // > > diff --git a/MdePkg/Library/BaseS3PciLib/S3PciLib.c > b/MdePkg/Library/BaseS3PciLib/S3PciLib.c > > index e29f7fe..27342b0 100644 > > --- a/MdePkg/Library/BaseS3PciLib/S3PciLib.c > > +++ b/MdePkg/Library/BaseS3PciLib/S3PciLib.c > > @@ -3,7 +3,7 @@ > > the PCI operations to be replayed during an S3 resume. This library = class > > maps directly on top of the PciLib class. > > > > - Copyright (c) 2006 - 2012, Intel Corporation. All rights reserved. > > + Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved. > > > > This program and the accompanying materials > > are licensed and made available under the terms and conditions > > @@ -25,7 +25,7 @@ > > #include > > > > #define PCILIB_TO_COMMON_ADDRESS(Address) \ > > - ((UINT64) ((((UINTN) ((Address>>20) & 0xff)) << 24) + (((UINTN= ) > ((Address>>15) & 0x1f)) << 16) + (((UINTN) ((Address>>12) & 0x07)) << 8) = + > ((UINTN) (Address & 0xfff )))) > > + ((((UINTN) ((Address>>20) & 0xff)) << 24) + (((UINTN) ((Addres= s>>15) & > 0x1f)) << 16) + (((UINTN) ((Address>>12) & 0x07)) << 8) + ((UINTN) (Addre= ss & > 0xfff ))) > > > > /** > > Saves a PCI configuration value to the boot script. >=20 > I think this change is potentially unsafe, without auditing all uses of > PCILIB_TO_COMMON_ADDRESS(). In a 32-bit build, the type of the result > will no longer be UINT64 but UINT32, and that can cause problems in > several contexts. For example: >=20 > - as an operand to the sizeof operator > - when it's being relied upon to cause conversion to UINT64, for example > another (UINT32) operand could be added to it > - when it is passed through a variable argument list >=20 > It might be safe, but there's no way to tell without auditing all the > call sites. So let me see... >=20 > Apparently this macro is only passed to S3BootScriptSavePciCfgWrite() as > second argument, within the same file, and that argument is covered by > the function prototype explicitly, with type UINT64. So the change > should be safe. >=20 Thanks for the checking. I did search the whole edk2 repository for the reference of "PCILIB_TO_COMMON_ADDRESS" and it is only comsumed by the function you mentioned. > (I see the same macro definition and kind of invocation in > "QuarkPlatformPkg/Acpi/DxeSmm/AcpiSmm/AcpiSmmPlatform.c"; I didn't try > to audit that file.) >=20 > The rest looks okay too. >=20 > Reviewed-by: Laszlo Ersek >=20 Many thanks for the feedbacks and the effort for reviewing the patch. > (If you go ahead and submit a 30-part series that does this kind of > fixup all over the tree, please don't expect me to review it all -- I'm > okay reviewing OvmfPkg and ArmVirtPkg changes, but I can't take on the > rest. This kind of patch cannot be reviewed without consulting a really > wide context.) >=20 I am thinking if the package level patch contains too many changes, I might break it into multiple module-level patches and include module owners/experts to help reviewing them. Best Regards, Hao Wu > Thanks > Laszlo >=20 >=20 > > diff --git > a/MdePkg/Library/SmmMemoryAllocationLib/MemoryAllocationLib.c > b/MdePkg/Library/SmmMemoryAllocationLib/MemoryAllocationLib.c > > index 937165a..592cced 100644 > > --- a/MdePkg/Library/SmmMemoryAllocationLib/MemoryAllocationLib.c > > +++ b/MdePkg/Library/SmmMemoryAllocationLib/MemoryAllocationLib.c > > @@ -12,7 +12,7 @@ > > allocation for the Reserved memory types are not supported and will > always > > return NULL. > > > > - Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved. > > + Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved. > > This program and the accompanying materials > > are licensed and made available under the terms and conditions of th= e BSD > License > > which accompanies this distribution. The full text of the license m= ay be > found at > > @@ -343,7 +343,7 @@ InternalAllocateAlignedPages ( > > Status =3D gSmst->SmmFreePages (Memory, UnalignedPages); > > ASSERT_EFI_ERROR (Status); > > } > > - Memory =3D (EFI_PHYSICAL_ADDRESS) (AlignedMemory + > EFI_PAGES_TO_SIZE (Pages)); > > + Memory =3D AlignedMemory + EFI_PAGES_TO_SIZE (Pages); > > UnalignedPages =3D RealPages - Pages - UnalignedPages; > > if (UnalignedPages > 0) { > > // > > diff --git a/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib= .c > b/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c > > index 3da5e211..3bd3aef 100644 > > --- a/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c > > +++ b/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c > > @@ -2,7 +2,7 @@ > > Support routines for memory allocation routines based > > on boot services for Dxe phase drivers. > > > > - Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved. > > + Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved. > > This program and the accompanying materials > > are licensed and made available under the terms and conditions of th= e BSD > License > > which accompanies this distribution. The full text of the license m= ay be > found at > > @@ -216,7 +216,7 @@ InternalAllocateAlignedPages ( > > Status =3D gBS->FreePages (Memory, UnalignedPages); > > ASSERT_EFI_ERROR (Status); > > } > > - Memory =3D (EFI_PHYSICAL_ADDRESS) (AlignedMemory + > EFI_PAGES_TO_SIZE (Pages)); > > + Memory =3D AlignedMemory + EFI_PAGES_TO_SIZE (Pages); > > UnalignedPages =3D RealPages - Pages - UnalignedPages; > > if (UnalignedPages > 0) { > > // > >