* [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