Re: [edk2] [PATCH edk2-platforms v1 13/14] Hisilicon/Library: Add OsBootLib

2018-02-07 Thread Peter Jones
Coming late to the party because Leif called my attention to this thread... On Mon, Jan 29, 2018 at 11:16:21AM +, Leif Lindholm wrote: > This type of system behaviour has been seen multiple times to break > installations in the real world. I can't agree more; that's why there's a pile of

Re: [edk2] [PATCH v1 1/1] CryptoPkg/BaseCryptLib: remove some duplicate initializations.

2017-10-20 Thread Peter Jones
> Assuming the maintainers are fine with the patch as well, I suggest that > they please replace the word "initializations" with "assignments" in the > subject, to be pedantic on the C-lang level. Well, that's why I said "initializations" instead of "initializers", but if it's more clear to you,

[edk2] [PATCH v1 1/1] CryptoPkg/BaseCryptLib: remove some duplicate initializations.

2017-10-20 Thread Peter Jones
-off-by: Peter Jones <pjo...@redhat.com> --- CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c b/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c index d564591cb7f9..bf67a1f569a2

Re: [edk2] investigating TPM for OVMF-on-QEMU

2017-07-14 Thread Peter Jones
On Fri, Jul 14, 2017 at 08:04:14PM +0200, Laszlo Ersek wrote: > - TPM2 is basically the standardized version of TrEE, the most > recent set of specs, and what we should focus on. 100% agreed. > (2) Drivers (and features) in edk2/SecurityPkg/Tcg. > > There are 19 modules under

[edk2] [PATCH] Pkcs7VerifyDxe: Don't allow Pkcs7Verify to install protocols twice.

2016-09-29 Thread Peter Jones
EFI_ABORTED as per Michael Kinney's feedback. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Peter Jones <pjo...@redhat.com> --- SecurityPkg/Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/Secur

Re: [edk2] [PATCH] Pkcs7VerifyDxe: Don't allow Pkcs7Verify to install protocols twice.

2016-09-29 Thread Peter Jones
On Thu, Sep 29, 2016 at 06:38:17PM +, Kinney, Michael D wrote: > Peter, > > Please use this form in your patch. The UEFI Spec does allow other error > codes than > those listed in the API to be returned. Using !EFI_ERROR (Status) is safer. > EDK II > Coding Style also requires {} for if

[edk2] [PATCH] Pkcs7VerifyDxe: Don't allow Pkcs7Verify to install protocols twice.

2016-09-29 Thread Peter Jones
: TianoCore Contribution Agreement 1.0 Signed-off-by: Peter Jones <pjo...@redhat.com> --- SecurityPkg/Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/SecurityPkg/Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c b/Secur

[edk2] [PATCH] Add Pkcs7VerifyPkg

2016-09-21 Thread Peter Jones
This patch adds a Pkcs7VerifyPkg package, which builds the Pkcs7Verify DXE API as a standalone driver. This allows us to build a driver that can be loaded on UEFI 2.4 systems, so that UEFI applications can move to the newer APIs without breaking compatibility. Signed-off-by: Peter Jones <

Re: [edk2] [PATCH] SecuritPkg: DxeImageVerificationLib: Fix wrong verification logic in DBX & DBT

2016-04-15 Thread Peter Jones
t; This is my proposal as chair of the UEFI Security Response team. For > those not familiar with us, please visit http://uefi.org/security. > Please feel free to provide input on this proposed process. > > Thanks, > Dick Wilkins > > ____ >

Re: [edk2] [PATCH] SecuritPkg: DxeImageVerificationLib: Fix wrong verification logic in DBX & DBT

2016-04-15 Thread Peter Jones
On Fri, Apr 15, 2016 at 12:40:14AM +, Zhang, Chao B wrote: > Hi all: > Thank you very much for the info. Do you agree to add "[USRT > 0001604]: Bug found in SecuritPkg: DxeImageVerificationLib" into the > log & check in this patch? What's the point of adding our internal tracker to it?

Re: [edk2] [PATCH] SecuritPkg: DxeImageVerificationLib: Fix wrong verification logic in DBX & DBT

2016-04-14 Thread Peter Jones
On Thu, Apr 14, 2016 at 01:10:02AM +, Zhang, Chao B wrote: > Laszlo: >There is no CVE number. The issue was exposed during internal code >review. The code has been existing since 11/4/2014. So... why not? This is exactly the sort of issue that needs proper tracking. -- Peter