public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
* [PATCH v2 1/1] SecurityPkg: fix ZeroMem HashInterfaceHob
@ 2018-03-07 11:24 marcandre.lureau
  2018-03-07 14:55 ` Marc-André Lureau
  0 siblings, 1 reply; 5+ messages in thread
From: marcandre.lureau @ 2018-03-07 11:24 UTC (permalink / raw)
  To: edk2-devel
  Cc: Marc-André Lureau, Jiewen Yao, Chao Zhang, Star Zeng,
	Laszlo Ersek

From: Marc-André Lureau <marcandre.lureau@redhat.com>

The ZeroMem() call goes beyond the HashInterfaceHob structure, causing
HOB list corruption. The intent was to clear all but the Identifier,
that is starting from HashInterfaceCount.

Quoting Laszlo Ersek:
  Therefore I think the *first* approach to actually fixing this bug would
  be to simply add the "Count" suffix:

  > diff --git a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
  > index dbee0f2531bc..a869fffae3fe 100644
  > --- a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
  > +++ b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
  > @@ -424,7 +424,10 @@ HashLibBaseCryptoRouterPeiConstructor (
  >      // This is the second execution of this module, clear the hash interface
  >      // information registered at its first execution.
  >      //
  > -    ZeroMem (&HashInterfaceHob->HashInterface, sizeof (*HashInterfaceHob) - sizeof (EFI_GUID));
  > +    ZeroMem (
  > +      &HashInterfaceHob->HashInterfaceCount,
  > +      sizeof (*HashInterfaceHob) - sizeof (EFI_GUID)
  > +      );
  >    }
  >
  >    //

  On the other hand, I don't think such a fix would be great. First of
  all, the HASH_INTERFACE_HOB struct definition is not wrapped in

  #pragma pack (1)
  ...
  #pragma pack ()

  in other words, HASH_INTERFACE_HOB is not packed, hence there could be
  an unspecified amount of padding between "Identifier" and
  "HashInterfaceCount". That would lead to the same kind of buffer
  overflow, because "Length" includes the padding, but the "Buffer"
  argument doesn't.

  Second, even if there were no padding (and thus the byte count would be
  a perfect match for the full HOB structure), in the "Buffer" argument
  we take the address of the "HashInterfaceCount" field, and with the
  "Length" field, we still overflow that *individual* field. Although we
  wouldn't overflow the containing HOB structure, this is still (arguably)
  undefined behavior -- I seem to remember that some compilers actually
  blow up on this when you use the standard ISO C memcpy() or memset()
  functions in such contexts.

This patch takes Laszlo suggestion to fix the issue.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 .../HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c   | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
index dbee0f2531bc..84c1aaae70eb 100644
--- a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
+++ b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
@@ -397,6 +397,7 @@ HashLibBaseCryptoRouterPeiConstructor (
 {
   EFI_STATUS            Status;
   HASH_INTERFACE_HOB    *HashInterfaceHob;
+  UINTN                 ClearStartOffset;
 
   HashInterfaceHob = InternalGetHashInterfaceHob (&gZeroGuid);
   if (HashInterfaceHob == NULL) {
@@ -424,7 +425,11 @@ HashLibBaseCryptoRouterPeiConstructor (
     // This is the second execution of this module, clear the hash interface
     // information registered at its first execution.
     //
-    ZeroMem (&HashInterfaceHob->HashInterface, sizeof (*HashInterfaceHob) - sizeof (EFI_GUID));
+    ClearStartOffset = OFFSET_OF (HASH_INTERFACE_HOB, HashInterfaceCount);
+    ZeroMem (
+      (UINT8 *)HashInterfaceHob + ClearStartOffset,
+      sizeof (*HashInterfaceHob) - ClearStartOffset
+      );
   }
 
   //
-- 
2.16.2.346.g9779355e34



^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH v2 1/1] SecurityPkg: fix ZeroMem HashInterfaceHob
  2018-03-07 11:24 [PATCH v2 1/1] SecurityPkg: fix ZeroMem HashInterfaceHob marcandre.lureau
@ 2018-03-07 14:55 ` Marc-André Lureau
  2018-03-07 15:09   ` Zeng, Star
  0 siblings, 1 reply; 5+ messages in thread
From: Marc-André Lureau @ 2018-03-07 14:55 UTC (permalink / raw)
  To: edk2-devel; +Cc: Jiewen Yao, Star Zeng, Chao Zhang, Laszlo Ersek

Hi

On Wed, Mar 7, 2018 at 12:24 PM,  <marcandre.lureau@redhat.com> wrote:
> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>
> The ZeroMem() call goes beyond the HashInterfaceHob structure, causing
> HOB list corruption. The intent was to clear all but the Identifier,
> that is starting from HashInterfaceCount.
>

I see v1 is already applied. I'll send another patch to clear the mask
in the Ovmf/TPM series.

Thanks

> Quoting Laszlo Ersek:
>   Therefore I think the *first* approach to actually fixing this bug would
>   be to simply add the "Count" suffix:
>
>   > diff --git a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
>   > index dbee0f2531bc..a869fffae3fe 100644
>   > --- a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
>   > +++ b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
>   > @@ -424,7 +424,10 @@ HashLibBaseCryptoRouterPeiConstructor (
>   >      // This is the second execution of this module, clear the hash interface
>   >      // information registered at its first execution.
>   >      //
>   > -    ZeroMem (&HashInterfaceHob->HashInterface, sizeof (*HashInterfaceHob) - sizeof (EFI_GUID));
>   > +    ZeroMem (
>   > +      &HashInterfaceHob->HashInterfaceCount,
>   > +      sizeof (*HashInterfaceHob) - sizeof (EFI_GUID)
>   > +      );
>   >    }
>   >
>   >    //
>
>   On the other hand, I don't think such a fix would be great. First of
>   all, the HASH_INTERFACE_HOB struct definition is not wrapped in
>
>   #pragma pack (1)
>   ...
>   #pragma pack ()
>
>   in other words, HASH_INTERFACE_HOB is not packed, hence there could be
>   an unspecified amount of padding between "Identifier" and
>   "HashInterfaceCount". That would lead to the same kind of buffer
>   overflow, because "Length" includes the padding, but the "Buffer"
>   argument doesn't.
>
>   Second, even if there were no padding (and thus the byte count would be
>   a perfect match for the full HOB structure), in the "Buffer" argument
>   we take the address of the "HashInterfaceCount" field, and with the
>   "Length" field, we still overflow that *individual* field. Although we
>   wouldn't overflow the containing HOB structure, this is still (arguably)
>   undefined behavior -- I seem to remember that some compilers actually
>   blow up on this when you use the standard ISO C memcpy() or memset()
>   functions in such contexts.
>
> This patch takes Laszlo suggestion to fix the issue.
>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Cc: Chao Zhang <chao.b.zhang@intel.com>
> Cc: Star Zeng <star.zeng@intel.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  .../HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c   | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
> index dbee0f2531bc..84c1aaae70eb 100644
> --- a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
> +++ b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
> @@ -397,6 +397,7 @@ HashLibBaseCryptoRouterPeiConstructor (
>  {
>    EFI_STATUS            Status;
>    HASH_INTERFACE_HOB    *HashInterfaceHob;
> +  UINTN                 ClearStartOffset;
>
>    HashInterfaceHob = InternalGetHashInterfaceHob (&gZeroGuid);
>    if (HashInterfaceHob == NULL) {
> @@ -424,7 +425,11 @@ HashLibBaseCryptoRouterPeiConstructor (
>      // This is the second execution of this module, clear the hash interface
>      // information registered at its first execution.
>      //
> -    ZeroMem (&HashInterfaceHob->HashInterface, sizeof (*HashInterfaceHob) - sizeof (EFI_GUID));
> +    ClearStartOffset = OFFSET_OF (HASH_INTERFACE_HOB, HashInterfaceCount);
> +    ZeroMem (
> +      (UINT8 *)HashInterfaceHob + ClearStartOffset,
> +      sizeof (*HashInterfaceHob) - ClearStartOffset
> +      );
>    }
>
>    //
> --
> 2.16.2.346.g9779355e34
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel



-- 
Marc-André Lureau


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2 1/1] SecurityPkg: fix ZeroMem HashInterfaceHob
  2018-03-07 14:55 ` Marc-André Lureau
@ 2018-03-07 15:09   ` Zeng, Star
  2018-03-07 15:35     ` Zhang, Chao B
  0 siblings, 1 reply; 5+ messages in thread
From: Zeng, Star @ 2018-03-07 15:09 UTC (permalink / raw)
  To: Marc-André Lureau, edk2-devel@lists.01.org
  Cc: Laszlo Ersek, Yao, Jiewen, Zhang, Chao B, Zeng, Star

Yes, since the V1 has been pushed.
Just adding one line like below based on V1 should be ok.

HashInterfaceHob->SupportedHashMask = 0;


Thanks,
Star
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Marc-André Lureau
Sent: Wednesday, March 7, 2018 10:56 PM
To: edk2-devel@lists.01.org
Cc: Laszlo Ersek <lersek@redhat.com>; Yao, Jiewen <jiewen.yao@intel.com>; Zhang, Chao B <chao.b.zhang@intel.com>; Zeng, Star <star.zeng@intel.com>
Subject: Re: [edk2] [PATCH v2 1/1] SecurityPkg: fix ZeroMem HashInterfaceHob

Hi

On Wed, Mar 7, 2018 at 12:24 PM,  <marcandre.lureau@redhat.com> wrote:
> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>
> The ZeroMem() call goes beyond the HashInterfaceHob structure, causing 
> HOB list corruption. The intent was to clear all but the Identifier, 
> that is starting from HashInterfaceCount.
>

I see v1 is already applied. I'll send another patch to clear the mask in the Ovmf/TPM series.

Thanks

> Quoting Laszlo Ersek:
>   Therefore I think the *first* approach to actually fixing this bug would
>   be to simply add the "Count" suffix:
>
>   > diff --git a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
>   > index dbee0f2531bc..a869fffae3fe 100644
>   > --- a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
>   > +++ b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
>   > @@ -424,7 +424,10 @@ HashLibBaseCryptoRouterPeiConstructor (
>   >      // This is the second execution of this module, clear the hash interface
>   >      // information registered at its first execution.
>   >      //
>   > -    ZeroMem (&HashInterfaceHob->HashInterface, sizeof (*HashInterfaceHob) - sizeof (EFI_GUID));
>   > +    ZeroMem (
>   > +      &HashInterfaceHob->HashInterfaceCount,
>   > +      sizeof (*HashInterfaceHob) - sizeof (EFI_GUID)
>   > +      );
>   >    }
>   >
>   >    //
>
>   On the other hand, I don't think such a fix would be great. First of
>   all, the HASH_INTERFACE_HOB struct definition is not wrapped in
>
>   #pragma pack (1)
>   ...
>   #pragma pack ()
>
>   in other words, HASH_INTERFACE_HOB is not packed, hence there could be
>   an unspecified amount of padding between "Identifier" and
>   "HashInterfaceCount". That would lead to the same kind of buffer
>   overflow, because "Length" includes the padding, but the "Buffer"
>   argument doesn't.
>
>   Second, even if there were no padding (and thus the byte count would be
>   a perfect match for the full HOB structure), in the "Buffer" argument
>   we take the address of the "HashInterfaceCount" field, and with the
>   "Length" field, we still overflow that *individual* field. Although we
>   wouldn't overflow the containing HOB structure, this is still (arguably)
>   undefined behavior -- I seem to remember that some compilers actually
>   blow up on this when you use the standard ISO C memcpy() or memset()
>   functions in such contexts.
>
> This patch takes Laszlo suggestion to fix the issue.
>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Cc: Chao Zhang <chao.b.zhang@intel.com>
> Cc: Star Zeng <star.zeng@intel.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  .../HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c   | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git 
> a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterP
> ei.c 
> b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterP
> ei.c index dbee0f2531bc..84c1aaae70eb 100644
> --- 
> a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterP
> ei.c
> +++ b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRou
> +++ terPei.c
> @@ -397,6 +397,7 @@ HashLibBaseCryptoRouterPeiConstructor (  {
>    EFI_STATUS            Status;
>    HASH_INTERFACE_HOB    *HashInterfaceHob;
> +  UINTN                 ClearStartOffset;
>
>    HashInterfaceHob = InternalGetHashInterfaceHob (&gZeroGuid);
>    if (HashInterfaceHob == NULL) {
> @@ -424,7 +425,11 @@ HashLibBaseCryptoRouterPeiConstructor (
>      // This is the second execution of this module, clear the hash interface
>      // information registered at its first execution.
>      //
> -    ZeroMem (&HashInterfaceHob->HashInterface, sizeof (*HashInterfaceHob) - sizeof (EFI_GUID));
> +    ClearStartOffset = OFFSET_OF (HASH_INTERFACE_HOB, HashInterfaceCount);
> +    ZeroMem (
> +      (UINT8 *)HashInterfaceHob + ClearStartOffset,
> +      sizeof (*HashInterfaceHob) - ClearStartOffset
> +      );
>    }
>
>    //
> --
> 2.16.2.346.g9779355e34
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel



-- 
Marc-André Lureau
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2 1/1] SecurityPkg: fix ZeroMem HashInterfaceHob
  2018-03-07 15:09   ` Zeng, Star
@ 2018-03-07 15:35     ` Zhang, Chao B
  2018-03-07 20:55       ` Laszlo Ersek
  0 siblings, 1 reply; 5+ messages in thread
From: Zhang, Chao B @ 2018-03-07 15:35 UTC (permalink / raw)
  To: Zeng, Star, Marc-André Lureau, edk2-devel@lists.01.org
  Cc: Laszlo Ersek, Yao, Jiewen

Star:
   Why do we need to add HashInterfaceHob->SupportedHashMask = 0?  HashInterfaceHob is internally maintained and accessed by HashLibRouterPei.
There is no impact to leave the value after module has been re-shadowed.




From: Zeng, Star
Sent: Wednesday, March 7, 2018 11:10 PM
To: Marc-André Lureau <marcandre.lureau@gmail.com>; edk2-devel@lists.01.org
Cc: Laszlo Ersek <lersek@redhat.com>; Yao, Jiewen <jiewen.yao@intel.com>; Zhang, Chao B <chao.b.zhang@intel.com>; Zeng, Star <star.zeng@intel.com>
Subject: RE: [edk2] [PATCH v2 1/1] SecurityPkg: fix ZeroMem HashInterfaceHob

Yes, since the V1 has been pushed.
Just adding one line like below based on V1 should be ok.

HashInterfaceHob->SupportedHashMask = 0;


Thanks,
Star
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Marc-André Lureau
Sent: Wednesday, March 7, 2018 10:56 PM
To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>; Zhang, Chao B <chao.b.zhang@intel.com<mailto:chao.b.zhang@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
Subject: Re: [edk2] [PATCH v2 1/1] SecurityPkg: fix ZeroMem HashInterfaceHob

Hi

On Wed, Mar 7, 2018 at 12:24 PM,  <marcandre.lureau@redhat.com<mailto:marcandre.lureau@redhat.com>> wrote:
> From: Marc-André Lureau <marcandre.lureau@redhat.com<mailto:marcandre.lureau@redhat.com>>
>
> The ZeroMem() call goes beyond the HashInterfaceHob structure, causing
> HOB list corruption. The intent was to clear all but the Identifier,
> that is starting from HashInterfaceCount.
>

I see v1 is already applied. I'll send another patch to clear the mask in the Ovmf/TPM series.

Thanks

> Quoting Laszlo Ersek:
>   Therefore I think the *first* approach to actually fixing this bug would
>   be to simply add the "Count" suffix:
>
>   > diff --git a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
>   > index dbee0f2531bc..a869fffae3fe 100644
>   > --- a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
>   > +++ b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
>   > @@ -424,7 +424,10 @@ HashLibBaseCryptoRouterPeiConstructor (
>   >      // This is the second execution of this module, clear the hash interface
>   >      // information registered at its first execution.
>   >      //
>   > -    ZeroMem (&HashInterfaceHob->HashInterface, sizeof (*HashInterfaceHob) - sizeof (EFI_GUID));
>   > +    ZeroMem (
>   > +      &HashInterfaceHob->HashInterfaceCount,
>   > +      sizeof (*HashInterfaceHob) - sizeof (EFI_GUID)
>   > +      );
>   >    }
>   >
>   >    //
>
>   On the other hand, I don't think such a fix would be great. First of
>   all, the HASH_INTERFACE_HOB struct definition is not wrapped in
>
>   #pragma pack (1)
>   ...
>   #pragma pack ()
>
>   in other words, HASH_INTERFACE_HOB is not packed, hence there could be
>   an unspecified amount of padding between "Identifier" and
>   "HashInterfaceCount". That would lead to the same kind of buffer
>   overflow, because "Length" includes the padding, but the "Buffer"
>   argument doesn't.
>
>   Second, even if there were no padding (and thus the byte count would be
>   a perfect match for the full HOB structure), in the "Buffer" argument
>   we take the address of the "HashInterfaceCount" field, and with the
>   "Length" field, we still overflow that *individual* field. Although we
>   wouldn't overflow the containing HOB structure, this is still (arguably)
>   undefined behavior -- I seem to remember that some compilers actually
>   blow up on this when you use the standard ISO C memcpy() or memset()
>   functions in such contexts.
>
> This patch takes Laszlo suggestion to fix the issue.
>
> Cc: Jiewen Yao <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>
> Cc: Chao Zhang <chao.b.zhang@intel.com<mailto:chao.b.zhang@intel.com>>
> Cc: Star Zeng <star.zeng@intel.com<mailto:star.zeng@intel.com>>
> Cc: Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com<mailto:marcandre.lureau@redhat.com>>
> ---
>  .../HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c   | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git
> a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterP
> ei.c
> b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterP
> ei.c index dbee0f2531bc..84c1aaae70eb 100644
> ---
> a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterP
> ei.c
> +++ b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRou
> +++ terPei.c
> @@ -397,6 +397,7 @@ HashLibBaseCryptoRouterPeiConstructor (  {
>    EFI_STATUS            Status;
>    HASH_INTERFACE_HOB    *HashInterfaceHob;
> +  UINTN                 ClearStartOffset;
>
>    HashInterfaceHob = InternalGetHashInterfaceHob (&gZeroGuid);
>    if (HashInterfaceHob == NULL) {
> @@ -424,7 +425,11 @@ HashLibBaseCryptoRouterPeiConstructor (
>      // This is the second execution of this module, clear the hash interface
>      // information registered at its first execution.
>      //
> -    ZeroMem (&HashInterfaceHob->HashInterface, sizeof (*HashInterfaceHob) - sizeof (EFI_GUID));
> +    ClearStartOffset = OFFSET_OF (HASH_INTERFACE_HOB, HashInterfaceCount);
> +    ZeroMem (
> +      (UINT8 *)HashInterfaceHob + ClearStartOffset,
> +      sizeof (*HashInterfaceHob) - ClearStartOffset
> +      );
>    }
>
>    //
> --
> 2.16.2.346.g9779355e34
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel



--
Marc-André Lureau
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2 1/1] SecurityPkg: fix ZeroMem HashInterfaceHob
  2018-03-07 15:35     ` Zhang, Chao B
@ 2018-03-07 20:55       ` Laszlo Ersek
  0 siblings, 0 replies; 5+ messages in thread
From: Laszlo Ersek @ 2018-03-07 20:55 UTC (permalink / raw)
  To: Zhang, Chao B, Zeng, Star, Marc-André Lureau,
	edk2-devel@lists.01.org
  Cc: Yao, Jiewen

On 03/07/18 16:35, Zhang, Chao B wrote:
> Star:
>    Why do we need to add HashInterfaceHob->SupportedHashMask = 0?  HashInterfaceHob is internally maintained and accessed by HashLibRouterPei.
> There is no impact to leave the value after module has been re-shadowed.

There seems to be no functional requirement for clearing the
SupportedHashMask field, except the original (buggy) ZeroMem() call
looked like it *intended* to clear the field. So now that we have fixed
the buffer overflow, we should decide whether we want to stick with the
original intent (that would mean continuing to clear the field, one way
or another), or to depart from the original intent -- but that would
merit a comment in the code (or, it would have deserved a comment in the
commit message).

In short, it's not great to do two independent things in the same patch,
namely (a) fix the buffer overflow, (b) silently diverge from the
original intent, even if that's functionally justified.

Such changes should be split to two patches, or else explained in detail.

Thanks
Laszlo


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2018-03-07 20:48 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-03-07 11:24 [PATCH v2 1/1] SecurityPkg: fix ZeroMem HashInterfaceHob marcandre.lureau
2018-03-07 14:55 ` Marc-André Lureau
2018-03-07 15:09   ` Zeng, Star
2018-03-07 15:35     ` Zhang, Chao B
2018-03-07 20:55       ` Laszlo Ersek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox