public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Hao Wu <hao.a.wu@intel.com>
Cc: edk2-devel@ml01.01.org
Subject: Re: [PATCH v2 1/1] MdePkg: Refine casting expression result to bigger size
Date: Tue, 24 Jan 2017 10:53:50 +0100	[thread overview]
Message-ID: <04973bde-e5f1-42fc-fa73-f74aac9d5553@redhat.com> (raw)
In-Reply-To: <1485242740-10244-2-git-send-email-hao.a.wu@intel.com>

On 01/24/17 08:25, Hao Wu wrote:
> There are cases that the operands of an expression are all with rank less
> 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, like
> // UINT8, UINT16, etc.
> UINT64 c;
> c = (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 is
> 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", remove
> the explicit type casts:
> c = a + b;
> 
> 2). When the expression is possible to overflow the range of unsigned int/
> int:
> c = (UINT64)a + b;
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hao Wu <hao.a.wu@intel.com>
> ---
>  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 header.
>    PeCoffLoaderGetImageInfo() routine will do basic check for whole PE/COFF image.
>  
> -  Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.<BR>
> +  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.<BR>
>    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 the BSD License
> @@ -703,12 +703,10 @@ PeCoffLoaderGetImageInfo (
>        //
>        DebugDirectoryEntryFileOffset = 0;
>  
> -      SectionHeaderOffset = (UINTN)(
> -                               ImageContext->PeCoffHeaderOffset +
> -                               sizeof (UINT32) +
> -                               sizeof (EFI_IMAGE_FILE_HEADER) +
> -                               Hdr.Pe32->FileHeader.SizeOfOptionalHeader
> -                               );
> +      SectionHeaderOffset = ImageContext->PeCoffHeaderOffset +
> +                            sizeof (UINT32) +
> +                            sizeof (EFI_IMAGE_FILE_HEADER) +
> +                            Hdr.Pe32->FileHeader.SizeOfOptionalHeader;
>  
>        for (Index = 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.<BR>
> +  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.<BR>
>  
>    This program and the accompanying materials
>    are licensed and made available under the terms and conditions
> @@ -25,7 +25,7 @@
>  #include <Library/S3PciLib.h>
>  
>  #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) ((Address>>15) & 0x1f)) << 16) + (((UINTN) ((Address>>12) & 0x07)) << 8) + ((UINTN) (Address & 0xfff )))
>  
>  /**
>    Saves a PCI configuration value to the boot script.

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:

- 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

It might be safe, but there's no way to tell without auditing all the
call sites. So let me see...

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.

(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.)

The rest looks okay too.

Reviewed-by: Laszlo Ersek <lersek@redhat.com>

(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.)

Thanks
Laszlo


> 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.<BR>
> +  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.<BR>
>    This program and the accompanying materials                          
>    are licensed and made available under the terms and conditions of the BSD License         
>    which accompanies this distribution.  The full text of the license may be found at        
> @@ -343,7 +343,7 @@ InternalAllocateAlignedPages (
>        Status = gSmst->SmmFreePages (Memory, UnalignedPages);
>        ASSERT_EFI_ERROR (Status);
>      }
> -    Memory         = (EFI_PHYSICAL_ADDRESS) (AlignedMemory + EFI_PAGES_TO_SIZE (Pages));
> +    Memory         = AlignedMemory + EFI_PAGES_TO_SIZE (Pages);
>      UnalignedPages = 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.<BR>
> +  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.<BR>
>    This program and the accompanying materials                          
>    are licensed and made available under the terms and conditions of the BSD License         
>    which accompanies this distribution.  The full text of the license may be found at        
> @@ -216,7 +216,7 @@ InternalAllocateAlignedPages (
>        Status = gBS->FreePages (Memory, UnalignedPages);
>        ASSERT_EFI_ERROR (Status);
>      }
> -    Memory         = (EFI_PHYSICAL_ADDRESS) (AlignedMemory + EFI_PAGES_TO_SIZE (Pages));
> +    Memory         = AlignedMemory + EFI_PAGES_TO_SIZE (Pages);
>      UnalignedPages = RealPages - Pages - UnalignedPages;
>      if (UnalignedPages > 0) {
>        //
> 



  reply	other threads:[~2017-01-24  9:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-24  7:25 [PATCH v2 0/1] Refine casting expression result to bigger size Hao Wu
2017-01-24  7:25 ` [PATCH v2 1/1] MdePkg: " Hao Wu
2017-01-24  9:53   ` Laszlo Ersek [this message]
2017-01-25  0:25     ` Wu, Hao A
2017-01-25  5:57       ` Gao, Liming
2017-01-25  6:16         ` Wu, Hao A
2017-01-25  6:19           ` Gao, Liming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=04973bde-e5f1-42fc-fa73-f74aac9d5553@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox