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