Re: [edk2-devel] [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in confidential guests

[Yao, Jiewen]

Thank you very much for the help.

https://github.com/tianocore/edk2/pull/5595 merged.

> -Original Message-
> From: Michael Kubacki 
> Sent: Thursday, April 25, 2024 7:22 AM
> To: devel@edk2.groups.io; Yao, Jiewen ; Kinney, Michael
> D ; Sean Brogan 
> Cc: Gerd Hoffmann ; Ard Biesheuvel ;
> Oliver Steffen ; Ard Biesheuvel
> ; Srikanth Aithal 
> Subject: Re: [edk2-devel] [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load 
> driver
> in confidential guests
> 
> That issue looks different in that CodeQL did not have a problem. You
> can use the same PR, just rebase with master.
> 
> It looks like that had an issue triggering pipelines from GitHub which
> might be fixed be rerunning after the push.
> 
> Thanks,
> Michael
> 
> On 4/24/2024 7:08 PM, Yao, Jiewen wrote:
> > Ah, thank you Mike.
> >
> > Should I close/re-open my PR?
> > Or should I keep waiting?
> >
> > Thank you
> > Yao, Jiewen
> >
> >> -Original Message-
> >> From: Kinney, Michael D 
> >> Sent: Thursday, April 25, 2024 7:01 AM
> >> To: Yao, Jiewen ; devel@edk2.groups.io; Sean Brogan
> >> ; Michael Kubacki
> >> 
> >> Cc: Gerd Hoffmann ; Ard Biesheuvel ;
> >> Oliver Steffen ; Ard Biesheuvel
> >> ; Srikanth Aithal ; Kinney,
> >> Michael D 
> >> Subject: RE: [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in
> >> confidential guests
> >>
> >> Hi Jiewen,
> >>
> >> Michael Kubacki has been working on a CI issue and a change is being merged
> >> now.
> >>
> >> Mike
> >>
> >>> -Original Message-
> >>> From: Yao, Jiewen 
> >>> Sent: Wednesday, April 24, 2024 3:57 PM
> >>> To: devel@edk2.groups.io; Kinney, Michael D
> >>> ; Sean Brogan 
> >>> Cc: Gerd Hoffmann ; Ard Biesheuvel
> ;
> >>> Oliver Steffen ; Ard Biesheuvel
> >>> ; Srikanth Aithal 
> >>> Subject: RE: [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in
> >>> confidential guests
> >>>
> >>> Hi Mike/Sean
> >>> Can someone look at the EDKII CI?
> >>>
> >>> My PR has been blocked for 9 hours -
> >>> https://github.com/tianocore/edk2/pull/5595.
> >>>
> >>> Thank you
> >>> Yao, Jiewen
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: Ard Biesheuvel 
> >>>> Sent: Thursday, April 25, 2024 1:05 AM
> >>>> To: Yao, Jiewen 
> >>>> Cc: Gerd Hoffmann ; devel@edk2.groups.io; Oliver
> >>> Steffen
> >>>> ; Ard Biesheuvel ;
> >>> Srikanth
> >>>> Aithal 
> >>>> Subject: Re: [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in
> >>>> confidential guests
> >>>>
> >>>> On Wed, 24 Apr 2024 at 18:36, Yao, Jiewen 
> >>> wrote:
> >>>>>
> >>>>> Thanks Ard.
> >>>>>
> >>>>> I have submitted https://github.com/tianocore/edk2/pull/5595 3 hours
> >>> ago.
> >>>>> But it seems the CI stops working...
> >>>>>
> >>>>
> >>>> OK, I have dropped my PR.
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>> -Original Message-
> >>>>>> From: Ard Biesheuvel 
> >>>>>> Sent: Thursday, April 25, 2024 12:27 AM
> >>>>>> To: Yao, Jiewen 
> >>>>>> Cc: Gerd Hoffmann ; devel@edk2.groups.io;
> >>> Oliver
> >>>> Steffen
> >>>>>> ; Ard Biesheuvel ;
> >>>> Srikanth
> >>>>>> Aithal 
> >>>>>> Subject: Re: [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load
> >>> driver in
> >>>>>> confidential guests
> >>>>>>
> >>>>>> On Wed, 24 Apr 2024 at 08:45, Yao, Jiewen 
> >>> wrote:
> >>>>>>>
> >>>>>>> Reviewed-by: Jiewen Yao 
> >>>>>>>
> >>>>>>
> >>>>>> Thanks, I've queued this up.
> >>>>>>
> >>>>>>
> >>>>>>>> -Original Message-
> >>>>>>>> From: Gerd Hoffmann 
> >>>>>>>> Sent: Wednes

Re: [edk2-devel] [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in confidential guests

[Yao, Jiewen]

Ah, thank you Mike.

Should I close/re-open my PR?
Or should I keep waiting?

Thank you
Yao, Jiewen

> -Original Message-
> From: Kinney, Michael D 
> Sent: Thursday, April 25, 2024 7:01 AM
> To: Yao, Jiewen ; devel@edk2.groups.io; Sean Brogan
> ; Michael Kubacki
> 
> Cc: Gerd Hoffmann ; Ard Biesheuvel ;
> Oliver Steffen ; Ard Biesheuvel
> ; Srikanth Aithal ; Kinney,
> Michael D 
> Subject: RE: [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in
> confidential guests
> 
> Hi Jiewen,
> 
> Michael Kubacki has been working on a CI issue and a change is being merged
> now.
> 
> Mike
> 
> > -Original Message-
> > From: Yao, Jiewen 
> > Sent: Wednesday, April 24, 2024 3:57 PM
> > To: devel@edk2.groups.io; Kinney, Michael D
> > ; Sean Brogan 
> > Cc: Gerd Hoffmann ; Ard Biesheuvel ;
> > Oliver Steffen ; Ard Biesheuvel
> > ; Srikanth Aithal 
> > Subject: RE: [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in
> > confidential guests
> >
> > Hi Mike/Sean
> > Can someone look at the EDKII CI?
> >
> > My PR has been blocked for 9 hours -
> > https://github.com/tianocore/edk2/pull/5595.
> >
> > Thank you
> > Yao, Jiewen
> >
> >
> > > -Original Message-
> > > From: Ard Biesheuvel 
> > > Sent: Thursday, April 25, 2024 1:05 AM
> > > To: Yao, Jiewen 
> > > Cc: Gerd Hoffmann ; devel@edk2.groups.io; Oliver
> > Steffen
> > > ; Ard Biesheuvel ;
> > Srikanth
> > > Aithal 
> > > Subject: Re: [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in
> > > confidential guests
> > >
> > > On Wed, 24 Apr 2024 at 18:36, Yao, Jiewen 
> > wrote:
> > > >
> > > > Thanks Ard.
> > > >
> > > > I have submitted https://github.com/tianocore/edk2/pull/5595 3 hours
> > ago.
> > > > But it seems the CI stops working...
> > > >
> > >
> > > OK, I have dropped my PR.
> > >
> > >
> > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Ard Biesheuvel 
> > > > > Sent: Thursday, April 25, 2024 12:27 AM
> > > > > To: Yao, Jiewen 
> > > > > Cc: Gerd Hoffmann ; devel@edk2.groups.io;
> > Oliver
> > > Steffen
> > > > > ; Ard Biesheuvel ;
> > > Srikanth
> > > > > Aithal 
> > > > > Subject: Re: [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load
> > driver in
> > > > > confidential guests
> > > > >
> > > > > On Wed, 24 Apr 2024 at 08:45, Yao, Jiewen 
> > wrote:
> > > > > >
> > > > > > Reviewed-by: Jiewen Yao 
> > > > > >
> > > > >
> > > > > Thanks, I've queued this up.
> > > > >
> > > > >
> > > > > > > -Original Message-
> > > > > > > From: Gerd Hoffmann 
> > > > > > > Sent: Wednesday, April 24, 2024 2:00 PM
> > > > > > > To: devel@edk2.groups.io
> > > > > > > Cc: Oliver Steffen ; Gerd Hoffmann
> > > > > > > ; Ard Biesheuvel
> > ; Yao,
> > > > > Jiewen
> > > > > > > ; Srikanth Aithal 
> > > > > > > Subject: [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load
> > driver in
> > > > > confidential
> > > > > > > guests
> > > > > > >
> > > > > > > The VirtHstiDxe does not work in confidential guests.  There
> > also isn't
> > > > > > > anything we can reasonably test, neither flash storage nor SMM
> > mode will
> > > > > > > be used in that case.  So just skip driver load when running
> > in a
> > > > > > > confidential guest.
> > > > > > >
> > > > > > > Cc: Ard Biesheuvel 
> > > > > > > Cc: Jiewen Yao 
> > > > > > > Fixes: 506740982bba ("OvmfPkg/VirtHstiDxe: add code flash
> > check")
> > > > > > > Signed-off-by: Gerd Hoffmann 
> > > > > > > Tested-by: Srikanth Aithal 
> > > > > > > ---
> > > > > > >  OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf | 1 +
> > > > > > >  OvmfPkg/VirtHstiDxe/VirtHstiDxe.c   | 6 ++
> > > > > > >  2 files changed, 7 insertions(+)
> > &

Re: [edk2-devel] [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in confidential guests

[Yao, Jiewen]

Hi Mike/Sean
Can someone look at the EDKII CI?

My PR has been blocked for 9 hours - 
https://github.com/tianocore/edk2/pull/5595.

Thank you
Yao, Jiewen


> -Original Message-
> From: Ard Biesheuvel 
> Sent: Thursday, April 25, 2024 1:05 AM
> To: Yao, Jiewen 
> Cc: Gerd Hoffmann ; devel@edk2.groups.io; Oliver Steffen
> ; Ard Biesheuvel ; Srikanth
> Aithal 
> Subject: Re: [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in
> confidential guests
> 
> On Wed, 24 Apr 2024 at 18:36, Yao, Jiewen  wrote:
> >
> > Thanks Ard.
> >
> > I have submitted https://github.com/tianocore/edk2/pull/5595 3 hours ago.
> > But it seems the CI stops working...
> >
> 
> OK, I have dropped my PR.
> 
> 
> 
> >
> >
> > > -Original Message-
> > > From: Ard Biesheuvel 
> > > Sent: Thursday, April 25, 2024 12:27 AM
> > > To: Yao, Jiewen 
> > > Cc: Gerd Hoffmann ; devel@edk2.groups.io; Oliver
> Steffen
> > > ; Ard Biesheuvel ;
> Srikanth
> > > Aithal 
> > > Subject: Re: [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in
> > > confidential guests
> > >
> > > On Wed, 24 Apr 2024 at 08:45, Yao, Jiewen  wrote:
> > > >
> > > > Reviewed-by: Jiewen Yao 
> > > >
> > >
> > > Thanks, I've queued this up.
> > >
> > >
> > > > > -Original Message-
> > > > > From: Gerd Hoffmann 
> > > > > Sent: Wednesday, April 24, 2024 2:00 PM
> > > > > To: devel@edk2.groups.io
> > > > > Cc: Oliver Steffen ; Gerd Hoffmann
> > > > > ; Ard Biesheuvel ; Yao,
> > > Jiewen
> > > > > ; Srikanth Aithal 
> > > > > Subject: [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in
> > > confidential
> > > > > guests
> > > > >
> > > > > The VirtHstiDxe does not work in confidential guests.  There also 
> > > > > isn't
> > > > > anything we can reasonably test, neither flash storage nor SMM mode 
> > > > > will
> > > > > be used in that case.  So just skip driver load when running in a
> > > > > confidential guest.
> > > > >
> > > > > Cc: Ard Biesheuvel 
> > > > > Cc: Jiewen Yao 
> > > > > Fixes: 506740982bba ("OvmfPkg/VirtHstiDxe: add code flash check")
> > > > > Signed-off-by: Gerd Hoffmann 
> > > > > Tested-by: Srikanth Aithal 
> > > > > ---
> > > > >  OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf | 1 +
> > > > >  OvmfPkg/VirtHstiDxe/VirtHstiDxe.c   | 6 ++
> > > > >  2 files changed, 7 insertions(+)
> > > > >
> > > > > diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> > > > > b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> > > > > index 9514933011e8..b5c237288766 100644
> > > > > --- a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> > > > > +++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> > > > > @@ -49,6 +49,7 @@ [FeaturePcd]
> > > > >gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
> > > > >
> > > > >  [Pcd]
> > > > > +  gEfiMdePkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr
> > > > >gUefiOvmfPkgTokenSpaceGuid.PcdBfvBase
> > > > >gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase
> > > > >
> > > > > diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> > > > > b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> > > > > index b6e53a1219d1..efaff0d1f3cb 100644
> > > > > --- a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> > > > > +++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> > > > > @@ -17,6 +17,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> > > > >  #include 
> > > > >  #include 
> > > > >  #include 
> > > > > +#include 
> > > > >  #include 
> > > > >
> > > > >  #include 
> > > > > @@ -140,6 +141,11 @@ VirtHstiDxeEntrypoint (
> > > > >EFI_STATUS   Status;
> > > > >EFI_EVENTEvent;
> > > > >
> > > > > +  if (PcdGet64 (PcdConfidentialComputingGuestAttr)) {
> > > > > +DEBUG ((DEBUG_INFO, "%a: confidential guest\n", __func__));
> > > > > +return EFI_UNSUPPORTED;
> > > > > +  }
> > > > > +
> > > > >DevId = VirtHstiGetHostBridgeDevId ();
> > > > >switch (DevId) {
> > > > >  case INTEL_82441_DEVICE_ID:
> > > > > --
> > > > > 2.44.0
> > > >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118237): https://edk2.groups.io/g/devel/message/118237
Mute This Topic: https://groups.io/mt/105705705/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in confidential guests

[Yao, Jiewen]

Thanks Ard.

I have submitted https://github.com/tianocore/edk2/pull/5595 3 hours ago.
But it seems the CI stops working...



> -Original Message-
> From: Ard Biesheuvel 
> Sent: Thursday, April 25, 2024 12:27 AM
> To: Yao, Jiewen 
> Cc: Gerd Hoffmann ; devel@edk2.groups.io; Oliver Steffen
> ; Ard Biesheuvel ; Srikanth
> Aithal 
> Subject: Re: [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in
> confidential guests
> 
> On Wed, 24 Apr 2024 at 08:45, Yao, Jiewen  wrote:
> >
> > Reviewed-by: Jiewen Yao 
> >
> 
> Thanks, I've queued this up.
> 
> 
> > > -Original Message-
> > > From: Gerd Hoffmann 
> > > Sent: Wednesday, April 24, 2024 2:00 PM
> > > To: devel@edk2.groups.io
> > > Cc: Oliver Steffen ; Gerd Hoffmann
> > > ; Ard Biesheuvel ; Yao,
> Jiewen
> > > ; Srikanth Aithal 
> > > Subject: [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in
> confidential
> > > guests
> > >
> > > The VirtHstiDxe does not work in confidential guests.  There also isn't
> > > anything we can reasonably test, neither flash storage nor SMM mode will
> > > be used in that case.  So just skip driver load when running in a
> > > confidential guest.
> > >
> > > Cc: Ard Biesheuvel 
> > > Cc: Jiewen Yao 
> > > Fixes: 506740982bba ("OvmfPkg/VirtHstiDxe: add code flash check")
> > > Signed-off-by: Gerd Hoffmann 
> > > Tested-by: Srikanth Aithal 
> > > ---
> > >  OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf | 1 +
> > >  OvmfPkg/VirtHstiDxe/VirtHstiDxe.c   | 6 ++
> > >  2 files changed, 7 insertions(+)
> > >
> > > diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> > > b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> > > index 9514933011e8..b5c237288766 100644
> > > --- a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> > > +++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> > > @@ -49,6 +49,7 @@ [FeaturePcd]
> > >gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
> > >
> > >  [Pcd]
> > > +  gEfiMdePkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr
> > >gUefiOvmfPkgTokenSpaceGuid.PcdBfvBase
> > >gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase
> > >
> > > diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> > > b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> > > index b6e53a1219d1..efaff0d1f3cb 100644
> > > --- a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> > > +++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> > > @@ -17,6 +17,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >
> > >  #include 
> > > @@ -140,6 +141,11 @@ VirtHstiDxeEntrypoint (
> > >EFI_STATUS   Status;
> > >EFI_EVENTEvent;
> > >
> > > +  if (PcdGet64 (PcdConfidentialComputingGuestAttr)) {
> > > +DEBUG ((DEBUG_INFO, "%a: confidential guest\n", __func__));
> > > +return EFI_UNSUPPORTED;
> > > +  }
> > > +
> > >DevId = VirtHstiGetHostBridgeDevId ();
> > >switch (DevId) {
> > >  case INTEL_82441_DEVICE_ID:
> > > --
> > > 2.44.0
> >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118222): https://edk2.groups.io/g/devel/message/118222
Mute This Topic: https://groups.io/mt/105705705/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in confidential guests

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Gerd Hoffmann 
> Sent: Wednesday, April 24, 2024 2:00 PM
> To: devel@edk2.groups.io
> Cc: Oliver Steffen ; Gerd Hoffmann
> ; Ard Biesheuvel ; Yao, Jiewen
> ; Srikanth Aithal 
> Subject: [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in 
> confidential
> guests
> 
> The VirtHstiDxe does not work in confidential guests.  There also isn't
> anything we can reasonably test, neither flash storage nor SMM mode will
> be used in that case.  So just skip driver load when running in a
> confidential guest.
> 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Fixes: 506740982bba ("OvmfPkg/VirtHstiDxe: add code flash check")
> Signed-off-by: Gerd Hoffmann 
> Tested-by: Srikanth Aithal 
> ---
>  OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf | 1 +
>  OvmfPkg/VirtHstiDxe/VirtHstiDxe.c   | 6 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> index 9514933011e8..b5c237288766 100644
> --- a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> +++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> @@ -49,6 +49,7 @@ [FeaturePcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
> 
>  [Pcd]
> +  gEfiMdePkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr
>gUefiOvmfPkgTokenSpaceGuid.PcdBfvBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase
> 
> diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> index b6e53a1219d1..efaff0d1f3cb 100644
> --- a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> +++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> @@ -17,6 +17,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  #include 
> @@ -140,6 +141,11 @@ VirtHstiDxeEntrypoint (
>EFI_STATUS   Status;
>EFI_EVENTEvent;
> 
> +  if (PcdGet64 (PcdConfidentialComputingGuestAttr)) {
> +DEBUG ((DEBUG_INFO, "%a: confidential guest\n", __func__));
> +return EFI_UNSUPPORTED;
> +  }
> +
>DevId = VirtHstiGetHostBridgeDevId ();
>switch (DevId) {
>  case INTEL_82441_DEVICE_ID:
> --
> 2.44.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118182): https://edk2.groups.io/g/devel/message/118182
Mute This Topic: https://groups.io/mt/105705705/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 0/5] OvmfPkg: Add VirtHstiDxe driver

[Yao, Jiewen]

Thanks.

I notice one more thing: CodeFlash check is using PcdBfvBase, while 
VariableFlash check is using PcdOvmfFdBaseAddress.

I feel the VariableFlash check may bring confusing and potential risk, because 
PcdOvmfFdBaseAddress means the address of the full binary. There is no 
guarantee that it must be variable region. (Although the current implementation 
is.)
After check the FDF file, I highly recommend we use 
PcdOvmfFlashNvStorageVariableBase or PcdCfvBase which should guarantee it is 
variable region.

With this naming change in "VirtHstiQemuFirmwareFlashCheck (PcdGet32 
(PcdOvmfFdBaseAddress))", reviewed-by: Jiewen Yao 

Thank you
Yao, Jiewen



> -Original Message-
> From: Gerd Hoffmann 
> Sent: Friday, April 19, 2024 8:31 PM
> To: devel@edk2.groups.io
> Cc: Oliver Steffen ; Konstantin Kostiuk
> ; Ard Biesheuvel ; Yao,
> Jiewen ; Gerd Hoffmann 
> Subject: [PATCH v2 0/5] OvmfPkg: Add VirtHstiDxe driver
> 
> v2:
>  - remove 'Q35' from test bits
>  - add patch with a README.md
> 
> Gerd Hoffmann (3):
>   OvmfPkg/VirtHstiDxe: add varstore flash check
>   OvmfPkg/VirtHstiDxe: add code flash check
>   OvmfPkg/VirtHstiDxe: add README.md
> 
> Konstantin Kostiuk (2):
>   OvmfPkg: Add VirtHstiDxe driver
>   OvmfPkg: Add VirtHstiDxe to OVMF firmware build
> 
>  OvmfPkg/OvmfPkgIa32.dsc |   2 +
>  OvmfPkg/OvmfPkgIa32X64.dsc  |   2 +
>  OvmfPkg/OvmfPkgX64.dsc  |   2 +
>  OvmfPkg/OvmfPkgIa32.fdf |   1 +
>  OvmfPkg/OvmfPkgIa32X64.fdf  |   1 +
>  OvmfPkg/OvmfPkgX64.fdf  |   1 +
>  OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf |  56 +
>  OvmfPkg/VirtHstiDxe/VirtHstiDxe.h   |  94 +++
>  OvmfPkg/VirtHstiDxe/Flash.c |  90 +++
>  OvmfPkg/VirtHstiDxe/QemuCommon.c|  36 ++
>  OvmfPkg/VirtHstiDxe/QemuPC.c|  38 ++
>  OvmfPkg/VirtHstiDxe/QemuQ35.c   |  71 
>  OvmfPkg/VirtHstiDxe/VirtHstiDxe.c   | 173 
>  OvmfPkg/VirtHstiDxe/README.md   |  48 
>  14 files changed, 615 insertions(+)
>  create mode 100644 OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
>  create mode 100644 OvmfPkg/VirtHstiDxe/VirtHstiDxe.h
>  create mode 100644 OvmfPkg/VirtHstiDxe/Flash.c
>  create mode 100644 OvmfPkg/VirtHstiDxe/QemuCommon.c
>  create mode 100644 OvmfPkg/VirtHstiDxe/QemuPC.c
>  create mode 100644 OvmfPkg/VirtHstiDxe/QemuQ35.c
>  create mode 100644 OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
>  create mode 100644 OvmfPkg/VirtHstiDxe/README.md
> 
> --
> 2.44.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118051): https://edk2.groups.io/g/devel/message/118051
Mute This Topic: https://groups.io/mt/105616658/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 00/10] Add DeviceSecurity feature based on PFP 1.06 spec

[Yao, Jiewen]

All series: Reviewed-by: Jiewen Yao 

Dear Steward member
Do you have any concern on adding libspdm (https://github.com/DMTF/libspdm) as 
one more submodule?

Thank you
Yao, Jiewen

> -Original Message-
> From: Hou, Wenxing 
> Sent: Thursday, April 18, 2024 6:16 PM
> To: devel@edk2.groups.io; Andrew Fish ; Leif Lindholm
> ; Kinney, Michael D ;
> Liming Gao ; Sean Brogan
> ; Joey Vagedes ; Liu,
> Zhiguang ; Kumar, Rahul R ;
> Yao, Jiewen 
> Subject: RE: [edk2-devel] [PATCH v4 00/10] Add DeviceSecurity feature based on
> PFP 1.06 spec
> 
> Dear EDKII reviewers:
> 
> Thank you for your previous review of this patch set.
> Currently, five patches have been reviewed by.
> 
> But there are five patches need review.
>   Patch1:  MdePkg: Add SPDM1.2 support.
>   Patch2:  MdePkg: Add TCG PFP 1.06 support.
>   Patch4:  MdeModulePkg/Variable: Add TCG SPDM device measurement
> update
>   Patch8:  .gitmodule: Add libspdm submodule for EDKII
>   Patch10: ReadMe.rst: Add libspdm submodule license
> 
> Could you please review the PATCH v4?
> 
> PS: Jiewen has reviewed all the PATCH. And I have fixed his feedback in PATCH 
> v4.
> Jiewen has no questions about all the patches anymore.
> 
> Thanks,
> Wenxing
> 
> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Wenxing Hou
> Sent: Thursday, April 18, 2024 5:28 PM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Leif Lindholm ;
> Kinney, Michael D ; Liming Gao
> ; Sean Brogan ; Joey
> Vagedes ; Liu, Zhiguang ;
> Kumar, Rahul R ; Yao, Jiewen 
> Subject: [edk2-devel] [PATCH v4 00/10] Add DeviceSecurity feature based on PFP
> 1.06 spec
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2479
> 
> In PFP spec 1.06, platform firmware records the device certificate and device
> measurement for each SPDM responder.
> This PATCH set implement the DeviceSecurityLib to support spdm device
> Authentication and Measurement.
> 
> Libspdm as submodule is to support DeviceSecurity feature:
> https://github.com/DMTF/libspdm
> 
> TCG PFP spec 1.06:
> https://trustedcomputinggroup.org/resource/pc-client-specific-platform-
> firmware-profile-specification/
> 
> The POC branch:
> https://github.com/tianocore/edk2-staging/tree/DeviceSecurity
> 
> And the PATCH set has passed the EDKII CI:
> https://github.com/tianocore/edk2/pull/5508
> 
> v2 changes:
>  - Fix typo: PcdEnableSpdmDeviceAuthenticaion ->
> PcdEnableSpdmDeviceAuthentication
> v3 changes:
>  - Add new patch 10: Update ReadMe.rst for libspdm submodule license
> v4 changes:
>  - Update submodule libspdm to latest tag
> 
> PATCH 3: Reviewed-by: Liming Gao  PATCH 5:
> Reviewed-by: Jiewen Yao  PATCH 6: Reviewed-by:
> Jiewen Yao  PATCH 7: Reviewed-by: Joey Vagedes
>  PATCH 9: Reviewed-by: Jiewen Yao
> 
> 
> Cc: Andrew Fish 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Joey Vagedes 
> Cc: Zhiguang Liu 
> Cc: Rahul Kumar 
> Cc: Jiewen Yao 
> Signed-off-by: Wenxing Hou 
> 
> Wenxing Hou (10):
>   MdePkg: Add SPDM1.2 support.
>   MdePkg: Add TCG PFP 1.06 support.
>   MdePkg: Add devAuthBoot GlobalVariable
>   MdeModulePkg/Variable: Add TCG SPDM device measurement update
>   SecurityPkg: Add TCG PFP 1.06 support.
>   SecurityPkg: add DeviceSecurity support
>   .pytool/CISettings.py: add libspdm submodule.
>   .gitmodule: Add libspdm submodule for EDKII
>   SecurityPkg: Add libspdm submodule
>   ReadMe.rst: Add libspdm submodule license
> 
>  .gitmodules   |3 +
>  .pytool/CISettings.py |2 +
>  MdeModulePkg/MdeModulePkg.dec |5 +
>  .../Variable/RuntimeDxe/Measurement.c |   38 +-
>  .../RuntimeDxe/VariableRuntimeDxe.inf |3 +
>  .../RuntimeDxe/VariableSmmRuntimeDxe.inf  |3 +
>  MdePkg/Include/Guid/GlobalVariable.h  |8 +-
>  MdePkg/Include/Guid/ImageAuthentication.h |5 +-
>  MdePkg/Include/IndustryStandard/Spdm.h| 1112 -
>  .../IndustryStandard/UefiTcgPlatform.h|  186 ++-
>  ReadMe.rst|1 +
>  .../OsStub/CryptlibWrapper/CryptlibWrapper.c  |  970 ++
>  .../CryptlibWrapper/CryptlibWrapper.inf   |   38 +
>  .../OsStub/MemLibWrapper/MemLibWrapper.c  |  177 +++
>  .../OsStub/MemLibWrapper/MemLibWrapper.inf|   33 +
>  .../PlatformLibWrapper/PlatformLibWrapper.c   |   85 ++
>  .../PlatformLibWrapper/PlatformLibWrapper.inf |   33 +
>  .../SpdmLib/Include/Stub/SpdmLibStub.h|  347 +
>  .../SpdmLib/Include/hal/LibspdmStdBoolAlt.h   |   23 +
>  .../S

Re: [edk2-devel] [PATCH 0/7] General Updates based on UEFI 2.10 and PI 1.8 Specification

[Yao, Jiewen]

7/7, 4/7, 3/7 - reviewed-by: Jiewen Yao 

> -Original Message-
> From: Sachin Ganesh 
> Sent: Saturday, April 20, 2024 5:46 AM
> To: devel@edk2.groups.io
> Cc: gaolim...@byosoft.com.cn; Liu, Zhiguang ; Kinney,
> Michael D ; ardb+tianoc...@kernel.org;
> kra...@redhat.com; Yao, Jiewen ; Aktas, Erdem
> ; Xu, Min M ;
> thomas.lenda...@amd.com; POLUDOV, FELIX ; Dhanaraj V
> ; Sachin Ganesh 
> Subject: [PATCH 0/7] General Updates based on UEFI 2.10 and PI 1.8 
> Specification
> 
> This series of patches are for general updates to MdePkg and MdeModulePkg
> based on
> UEFI 2.10 and PI 1.8 Specifications
> 
> Sachin Ganesh (7):
>   MdePkg: Add definition for NVMe Over Fabric Device Path
>   MdePkg: Add new Resource Attributes defined in PI 1.8 Spec
>   MdePkg: Define Unaccepted Memory Type
>   MdeModulePkg: Use newly defined Unaccepted Memory Type
>   MdePkg: Update Delayed Dispatch PPI as per PI 1.8 Spec
>   MdePkg: Update to PI 1.8 Revision
>   OvmfPkg: Use newly defined Unaccepted Memory Type
> 
>  MdeModulePkg/Core/Dxe/Gcd/Gcd.c  | 10 +++---
>  MdeModulePkg/Core/Dxe/Mem/Page.c | 38 ++--
>  MdeModulePkg/Include/Pi/PrePiDxeCis.h| 25 -
>  MdeModulePkg/Include/Pi/PrePiHob.h   | 20 ---
>  MdePkg/Include/Pi/PiDxeCis.h | 19 +-
>  MdePkg/Include/Pi/PiHob.h| 14 +++-
>  MdePkg/Include/Pi/PiMmCis.h  |  6 ++--
>  MdePkg/Include/Pi/PiMultiPhase.h |  6 
>  MdePkg/Include/Pi/PiPeiCis.h |  6 ++--
>  MdePkg/Include/Pi/PiSmmCis.h |  2 +-
>  MdePkg/Include/Ppi/DelayedDispatch.h | 24 -
>  MdePkg/Include/Protocol/DevicePath.h | 22 
>  OvmfPkg/AmdSevDxe/AmdSevDxe.c|  4 +--
>  OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c |  8 ++---
>  OvmfPkg/Library/PeilessStartupLib/Hob.c  |  4 +--
>  OvmfPkg/Library/PlatformInitLib/IntelTdx.c   |  8 ++---
>  OvmfPkg/PlatformPei/AmdSev.c |  4 +--
>  17 files changed, 108 insertions(+), 112 deletions(-)
>  delete mode 100644 MdeModulePkg/Include/Pi/PrePiDxeCis.h
>  delete mode 100644 MdeModulePkg/Include/Pi/PrePiHob.h
> 
> --
> 2.24.1.windows.2
> -The information contained in this message may be confidential and proprietary
> to American Megatrends (AMI). This communication is intended to be read only 
> by
> the individual or entity to whom it is addressed or by their designee. If the 
> reader
> of this message is not the intended recipient, you are on notice that any
> distribution of this message, in any form, is strictly prohibited. Please 
> promptly
> notify the sender by reply e-mail or by telephone at 770-246-8600, and then
> delete or destroy all copies of the transmission.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118049): https://edk2.groups.io/g/devel/message/118049
Mute This Topic: https://groups.io/mt/105630618/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/4] OvmfPkg: Add VirtHstiDxe driver

[Yao, Jiewen]

1) Yes, I highly recommend remove Q35 keyword.
2) Got it. I think we had better add such info in the code as comment as well.

Thank you
Yao, Jiewen

> -Original Message-
> From: kra...@redhat.com 
> Sent: Thursday, April 18, 2024 7:45 PM
> To: Yao, Jiewen 
> Cc: devel@edk2.groups.io; Ard Biesheuvel ; Oliver Steffen
> 
> Subject: Re: [edk2-devel] [PATCH 0/4] OvmfPkg: Add VirtHstiDxe driver
> 
> On Wed, Apr 17, 2024 at 01:20:57PM +, Yao, Jiewen wrote:
> > That is good start. The SMRAM lock and Flash lock seem good to me.
> >
> > Comment:
> > 1) Do we really need to add "Q35" for the policy?
> > #define VIRT_HSTI_BYTE0_Q35_SMM_SMRAM_LOCK BIT0
> > #define VIRT_HSTI_BYTE0_Q35_SMM_SECURE_VARS_FLASH  BIT1
> >
> > I feel we had better remove it, since SMM_SMRAM_LOCK and
> SMM_SECURE_VARS_FLASH are common features for almost all X86 platforms.
> 
> Well, SMM mode is supported for the qemu 'q35' machine type only, the
> 'pc' machine type doesn't provide enough memory for SMM.  Which why I've
> added 'Q35' to the name.
> 
> The SMM_SMRAM_LOCK test actually is q35-specific because the control
> registers are chipset specific.  But, yes, the concept is not q35
> specific.
> 
> I can drop 'Q35' if you prefer it that way.
> 
> > 2) Would you please let me know what "READONLY_CODE_FLASH" really
> means?
> >
> > #define VIRT_HSTI_BYTE0_Q35_SMM_SECURE_VARS_FLASH  BIT1
> > #define VIRT_HSTI_BYTE0_READONLY_CODE_FLASHBIT2
> >
> > Does READONLY_CODE_FLASH mean NO write to flash even in SMM mode?
> > Or does it just mean NO write in normal operation mode, but still writable 
> > in
> SMM mode?
> 
> With qemu being configured properly flash behavior should be this:
> 
>|  OVMF_CODE.fd  |  OVMF_VARS.fd
> ---++
> SMM_REQUIRE=TRUE, SMM mode |  read-only |  writable
> SMM_REQUIRE=TRUE, normal mode  |  read-only (1) |  read-only (2)
> SMM_REQUIRE=FALSE  |  read-only (3) |  writable
> 
> VIRT_HSTI_BYTE0_READONLY_CODE_FLASH will verify (1) + (3).
> VIRT_HSTI_BYTE0_Q35_SMM_SECURE_VARS_FLASH will verify (2).
> 
> (probably a good idea to add that as comment to the patches).
> 
> take care,
>   Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117993): https://edk2.groups.io/g/devel/message/117993
Mute This Topic: https://groups.io/mt/105086174/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 6/6] OvmfPkg: Use newly defined Unaccepted Memory Type

[Yao, Jiewen]

Ah. That is good. I did not realize they are in one set.

For this one, reviewed-by: Jiewen Yao 


> -Original Message-
> From: Sachin Ganesh 
> Sent: Thursday, April 18, 2024 9:32 PM
> To: Yao, Jiewen ; devel@edk2.groups.io
> Cc: gaolim...@byosoft.com.cn; ardb+tianoc...@kernel.org; kra...@redhat.com;
> Aktas, Erdem ; Xu, Min M ;
> thomas.lenda...@amd.com; POLUDOV, FELIX ; Dhanaraj V
> 
> Subject: RE: [EXTERNAL] RE: [PATCH 6/6] OvmfPkg: Use newly defined
> Unaccepted Memory Type
> 
> Hi Jiewen,
> 
> The other patches are as follows. They are all related to UEFI 2.10 and PI 1.8
> Specification updates:
> 
> 1)  MdePkg: Add definition for NVMe Over Fabric Device Path -
> https://edk2.groups.io/g/devel/message/117845?p=%2C%2C%2C20%2C0%2C0
> %2C0%3A%3Arecentpostdate%2Fsticky%2C%2Csachin%2C20%2C2%2C0%2C105
> 551420
> 2) MdePkg: Add new Resource Attributes defined in PI 1.8 Spec -
> https://edk2.groups.io/g/devel/message/117796?p=%2C%2C%2C20%2C0%2C0
> %2C0%3A%3Arecentpostdate%2Fsticky%2C%2Csachin%2C20%2C2%2C0%2C105
> 540404
> 3) MdePkg: Use newly defined Unaccepted Memory Type -
> https://edk2.groups.io/g/devel/message/117797?p=%2C%2C%2C20%2C0%2C0
> %2C0%3A%3Arecentpostdate%2Fsticky%2C%2Csachin%2C20%2C2%2C0%2C105
> 540405
> 4) MdePkg: Update Delayed Dispatch PPI as per PI 1.8 Spec -
> https://edk2.groups.io/g/devel/message/117798?p=%2C%2C%2C20%2C0%2C0
> %2C0%3A%3Arecentpostdate%2Fsticky%2C%2Csachin%2C20%2C2%2C0%2C105
> 540406
> 5) MdePkg: Update to PI 1.8 Revision -
> https://edk2.groups.io/g/devel/message/117799?p=%2C%2C%2C20%2C0%2C0
> %2C0%3A%3Arecentpostdate%2Fsticky%2C%2Csachin%2C20%2C2%2C0%2C105
> 540407
> 
> This is the related MR - https://github.com/tianocore/edk2/pull/5569
> 
> Thank You,
> Sachin.
> 
> -Original Message-
> From: Yao, Jiewen 
> Sent: Thursday, April 18, 2024 5:44 AM
> To: Sachin Ganesh ; devel@edk2.groups.io
> Cc: gaolim...@byosoft.com.cn; ardb+tianoc...@kernel.org; kra...@redhat.com;
> Aktas, Erdem ; Xu, Min M ;
> thomas.lenda...@amd.com; Felix Polyudov ; Dhanaraj V
> 
> Subject: [EXTERNAL] RE: [PATCH 6/6] OvmfPkg: Use newly defined Unaccepted
> Memory Type
> 
> 
> **CAUTION: The e-mail below is from an external source. Please exercise
> caution before opening attachments, clicking links, or following guidance.**
> 
> Hi Sachin
> I like this clean up. Thanks for doing this.
> 
> I saw this patch is 6/6, but I did not see any other such as 1/6 ~ 5/6 in my
> mailbox. Not sure what is happening on my side.
> 
> Just double confirm, have you sent those patches?
> 
> Thank you
> Yao, Jiewen
> 
> > -----Original Message-
> > From: Sachin Ganesh 
> > Sent: Thursday, April 18, 2024 3:45 AM
> > To: devel@edk2.groups.io
> > Cc: gaolim...@byosoft.com.cn; ardb+tianoc...@kernel.org;
> > kra...@redhat.com; Yao, Jiewen ; Aktas, Erdem
> > ; Xu, Min M ;
> > thomas.lenda...@amd.com; POLUDOV, FELIX ; Dhanaraj V
> > ; Sachin Ganesh 
> > Subject: [PATCH 6/6] OvmfPkg: Use newly defined Unaccepted Memory Type
> >
> > EFI_RESOURCE_MEMORY_UNACCEPTED has been officially defined in the PI
> > 1.8 specification. So all temporary solutions have been replaced with
> > the actual definition.
> >
> > Cc: Felix Polyudov 
> > Cc: Dhanaraj V 
> > Cc: Ard Biesheuvel 
> > Cc: Jiewen Yao 
> > Cc: Gerd Hoffmann 
> > Cc: Erdem Aktas 
> > Cc: Min Xu 
> > Cc: Tom Lendacky 
> > Signed-off-by: Sachin Ganesh 
> > ---
> >  OvmfPkg/AmdSevDxe/AmdSevDxe.c| 4 ++--
> >  OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c | 8 
> >  OvmfPkg/Library/PeilessStartupLib/Hob.c  | 4 ++--
> >  OvmfPkg/Library/PlatformInitLib/IntelTdx.c   | 8 
> >  OvmfPkg/PlatformPei/AmdSev.c | 4 ++--
> >  5 files changed, 14 insertions(+), 14 deletions(-)
> >
> > diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.c
> > b/OvmfPkg/AmdSevDxe/AmdSevDxe.c index db3675ae86..d497a343d3 100644
> > --- a/OvmfPkg/AmdSevDxe/AmdSevDxe.c
> > +++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
> > @@ -20,7 +20,7 @@
> >  #include 
> >
> >  #include 
> >
> >  #include 
> >
> > -#include 
> >
> > +#include 
> >
> >  #include 
> >
> >  #include 
> >
> >  #include 
> >
> > @@ -119,7 +119,7 @@ AcceptAllMemory (
> >  CONST EFI_GCD_MEMORY_SPACE_DESCRIPTOR  *Desc;
> >
> >
> >
> >  Desc = [Index];
> >
> > -if (Desc->GcdMemoryType != EFI_GCD_MEMORY_TYPE_UNACCEPTED) {
> >
> > +if (Desc->GcdMemoryType != EfiGcdMemoryTypeUnaccepted) {
> >
> >

Re: [edk2-devel] [PATCH] OvmfPkg: Harden #VC instruction emulation somewhat (CVE-2024-25742)

[Yao, Jiewen]

Thanks Adam and Ard.

Since this #VC specific hardening, I would rely on AMD people's expertise to 
fix it.
I have no objection for the patch.

Thank you
Yao, Jiewen

> -Original Message-
> From: Adam Dunlap 
> Sent: Thursday, April 18, 2024 1:45 AM
> To: Ard Biesheuvel 
> Cc: devel@edk2.groups.io; Yao, Jiewen ; Borislav Petkov
> ; Peter Gonda ; Tom Lendacky
> ; Aktas, Erdem ; Gerd
> Hoffmann ; Michael Roth ; Xu,
> Min M 
> Subject: Re: [edk2-devel] [PATCH] OvmfPkg: Harden #VC instruction emulation
> somewhat (CVE-2024-25742)
> 
> On Wed, Apr 17, 2024 at 10:08 AM Ard Biesheuvel  wrote:
> >
> > (cc Jiewen)
> >
> > Please cc the OVMF maintainers when you send edk2 patches. (There is a
> > Maintainers file in the root of the repo)
> 
> Thanks, I added everyone returned from the GetMaintainer.py script.
> 
> > On Wed, 17 Apr 2024 at 18:54, Adam Dunlap via groups.io
> >  wrote:
> > >
> > > Ensure that when a #VC exception happens, the instruction at the
> > > instruction pointer matches the instruction that is expected given the
> > > error code. This is to mitigate the ahoi WeSee attack [1] that could
> > > allow hypervisors to breach integrity and confidentiality of the
> > > firmware by maliciously injecting interrupts. This change is a
> > > translated version of a linux patch e3ef461af35a ("x86/sev: Harden #VC
> > > instruction emulation somewhat")
> > >
> > > [1] https://ahoi-attacks.github.io/wesee/
> > >
> > > Cc: Borislav Petkov (AMD) 
> > > Cc: Tom Lendacky 
> > > Signed-off-by: Adam Dunlap 
> > > ---
> > >  OvmfPkg/Library/CcExitLib/CcExitVcHandler.c | 171 ++--
> > >  1 file changed, 160 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
> b/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
> > > index 0fc30f7bc4..bd3e9f304a 100644
> > > --- a/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
> > > +++ b/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
> > > @@ -532,8 +532,6 @@ MwaitExit (
> > >IN CC_INSTRUCTION_DATA *InstructionData
> > >)
> > >  {
> > > -  CcDecodeModRm (Regs, InstructionData);
> > > -
> > >Ghcb->SaveArea.Rax = Regs->Rax;
> > >CcExitVmgSetOffsetValid (Ghcb, GhcbRax);
> > >Ghcb->SaveArea.Rcx = Regs->Rcx;
> > > @@ -564,8 +562,6 @@ MonitorExit (
> > >IN CC_INSTRUCTION_DATA *InstructionData
> > >)
> > >  {
> > > -  CcDecodeModRm (Regs, InstructionData);
> > > -
> > >Ghcb->SaveArea.Rax = Regs->Rax;  // Identity mapped, so VA = PA
> > >CcExitVmgSetOffsetValid (Ghcb, GhcbRax);
> > >Ghcb->SaveArea.Rcx = Regs->Rcx;
> > > @@ -670,8 +666,6 @@ VmmCallExit (
> > >  {
> > >UINT64  Status;
> > >
> > > -  CcDecodeModRm (Regs, InstructionData);
> > > -
> > >Ghcb->SaveArea.Rax = Regs->Rax;
> > >CcExitVmgSetOffsetValid (Ghcb, GhcbRax);
> > >Ghcb->SaveArea.Cpl = (UINT8)(Regs->Cs & 0x3);
> > > @@ -1603,8 +1597,6 @@ Dr7WriteExit (
> > >Ext   = >Ext;
> > >SevEsData = (SEV_ES_PER_CPU_DATA *)(Ghcb + 1);
> > >
> > > -  CcDecodeModRm (Regs, InstructionData);
> > > -
> > >//
> > >// MOV DRn always treats MOD == 3 no matter how encoded
> > >//
> > > @@ -1655,8 +1647,6 @@ Dr7ReadExit (
> > >Ext   = >Ext;
> > >SevEsData = (SEV_ES_PER_CPU_DATA *)(Ghcb + 1);
> > >
> > > -  CcDecodeModRm (Regs, InstructionData);
> > > -
> > >//
> > >// MOV DRn always treats MOD == 3 no matter how encoded
> > >//
> > > @@ -1671,6 +1661,160 @@ Dr7ReadExit (
> > >return 0;
> > >  }
> > >
> > > +/**
> > > +  Check that the opcode matches the exit code for a #VC.
> > > +
> > > +  Each exit code should only be raised while executing certain 
> > > instructions.
> > > +  Verify that rIP points to a correct instruction based on the exit code 
> > > to
> > > +  protect against maliciously injected interrupts via the hypervisor. If 
> > > it does
> > > +  not, report an unsupported event to the hypervisor.
> > > +
> > > +  Decodes the ModRm byte into InstructionData if necessary.
> > > +
> > > +  @param[in, out] Ghcb Pointer to the Guest-Hypervisor
> 

Re: [edk2-devel] [PATCH 6/6] OvmfPkg: Use newly defined Unaccepted Memory Type

[Yao, Jiewen]

Hi Sachin
I like this clean up. Thanks for doing this.

I saw this patch is 6/6, but I did not see any other such as 1/6 ~ 5/6 in my 
mailbox. Not sure what is happening on my side.

Just double confirm, have you sent those patches?

Thank you
Yao, Jiewen

> -Original Message-
> From: Sachin Ganesh 
> Sent: Thursday, April 18, 2024 3:45 AM
> To: devel@edk2.groups.io
> Cc: gaolim...@byosoft.com.cn; ardb+tianoc...@kernel.org; kra...@redhat.com;
> Yao, Jiewen ; Aktas, Erdem ;
> Xu, Min M ; thomas.lenda...@amd.com; POLUDOV,
> FELIX ; Dhanaraj V ; Sachin Ganesh
> 
> Subject: [PATCH 6/6] OvmfPkg: Use newly defined Unaccepted Memory Type
> 
> EFI_RESOURCE_MEMORY_UNACCEPTED has been officially defined in the PI
> 1.8 specification. So all temporary solutions have been replaced with
> the actual definition.
> 
> Cc: Felix Polyudov 
> Cc: Dhanaraj V 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Gerd Hoffmann 
> Cc: Erdem Aktas 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Signed-off-by: Sachin Ganesh 
> ---
>  OvmfPkg/AmdSevDxe/AmdSevDxe.c| 4 ++--
>  OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c | 8 
>  OvmfPkg/Library/PeilessStartupLib/Hob.c  | 4 ++--
>  OvmfPkg/Library/PlatformInitLib/IntelTdx.c   | 8 
>  OvmfPkg/PlatformPei/AmdSev.c | 4 ++--
>  5 files changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.c
> b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
> index db3675ae86..d497a343d3 100644
> --- a/OvmfPkg/AmdSevDxe/AmdSevDxe.c
> +++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
> @@ -20,7 +20,7 @@
>  #include 
> 
>  #include 
> 
>  #include 
> 
> -#include 
> 
> +#include 
> 
>  #include 
> 
>  #include 
> 
>  #include 
> 
> @@ -119,7 +119,7 @@ AcceptAllMemory (
>  CONST EFI_GCD_MEMORY_SPACE_DESCRIPTOR  *Desc;
> 
> 
> 
>  Desc = [Index];
> 
> -if (Desc->GcdMemoryType != EFI_GCD_MEMORY_TYPE_UNACCEPTED) {
> 
> +if (Desc->GcdMemoryType != EfiGcdMemoryTypeUnaccepted) {
> 
>continue;
> 
>  }
> 
> 
> 
> diff --git a/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> b/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> index 3372cee2f7..b6085eab44 100644
> --- a/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> +++ b/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> @@ -19,7 +19,7 @@
>  #include 
> 
>  #include 
> 
>  #include 
> 
> -#include 
> 
> +#include 
> 
>  #include 
> 
>  #include 
> 
>  #include 
> 
> @@ -351,7 +351,7 @@ AcceptMemoryForAPsStack (
>  if (Hob.Header->HobType == EFI_HOB_TYPE_RESOURCE_DESCRIPTOR) {
> 
>DEBUG ((DEBUG_INFO, "\nResourceType: 0x%x\n", Hob.ResourceDescriptor-
> >ResourceType));
> 
> 
> 
> -  if (Hob.ResourceDescriptor->ResourceType ==
> BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED) {
> 
> +  if (Hob.ResourceDescriptor->ResourceType ==
> EFI_RESOURCE_MEMORY_UNACCEPTED) {
> 
>  ResourceLength = Hob.ResourceDescriptor->ResourceLength;
> 
>  PhysicalStart  = Hob.ResourceDescriptor->PhysicalStart;
> 
>  PhysicalEnd= PhysicalStart + ResourceLength;
> 
> @@ -427,7 +427,7 @@ AcceptMemory (
>//
> 
>while (!END_OF_HOB_LIST (Hob)) {
> 
>  if (Hob.Header->HobType == EFI_HOB_TYPE_RESOURCE_DESCRIPTOR) {
> 
> -  if (Hob.ResourceDescriptor->ResourceType ==
> BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED) {
> 
> +  if (Hob.ResourceDescriptor->ResourceType ==
> EFI_RESOURCE_MEMORY_UNACCEPTED) {
> 
>  PhysicalStart = Hob.ResourceDescriptor->PhysicalStart;
> 
>  PhysicalEnd   = PhysicalStart + 
> Hob.ResourceDescriptor->ResourceLength;
> 
> 
> 
> @@ -563,7 +563,7 @@ ValidateHobList (
>  EFI_RESOURCE_MEMORY_MAPPED_IO_PORT,
> 
>  EFI_RESOURCE_MEMORY_RESERVED,
> 
>  EFI_RESOURCE_IO_RESERVED,
> 
> -BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED
> 
> +EFI_RESOURCE_MEMORY_UNACCEPTED
> 
>};
> 
> 
> 
>if (VmmHobList == NULL) {
> 
> diff --git a/OvmfPkg/Library/PeilessStartupLib/Hob.c
> b/OvmfPkg/Library/PeilessStartupLib/Hob.c
> index 318b74c95d..725927da73 100644
> --- a/OvmfPkg/Library/PeilessStartupLib/Hob.c
> +++ b/OvmfPkg/Library/PeilessStartupLib/Hob.c
> @@ -20,7 +20,7 @@
>  #include 
> 
>  #include 
> 
>  #include 
> 
> -#include 
> 
> +#include 
> 
>  #include "PeilessStartupInternal.h"
> 
> 
> 
>  /**
> 
> @@ -92,7 +92,7 @@ ConstructFwHobList (
>//
> 
>while (!END_OF_HOB_LIST (Hob)) {
> 
>  if (Hob.Header->HobType == EFI_HOB_TYPE_RESOURCE_DES

Re: [edk2-devel] [PATCH 0/4] OvmfPkg: Add VirtHstiDxe driver

[Yao, Jiewen]

That is good start. The SMRAM lock and Flash lock seem good to me.

Comment:
1) Do we really need to add "Q35" for the policy?
#define VIRT_HSTI_BYTE0_Q35_SMM_SMRAM_LOCK BIT0
#define VIRT_HSTI_BYTE0_Q35_SMM_SECURE_VARS_FLASH  BIT1

I feel we had better remove it, since SMM_SMRAM_LOCK and SMM_SECURE_VARS_FLASH 
are common features for almost all X86 platforms.

2) Would you please let me know what "READONLY_CODE_FLASH" really means?

#define VIRT_HSTI_BYTE0_Q35_SMM_SECURE_VARS_FLASH  BIT1
#define VIRT_HSTI_BYTE0_READONLY_CODE_FLASHBIT2

Does READONLY_CODE_FLASH mean NO write to flash even in SMM mode?
Or does it just mean NO write in normal operation mode, but still writable in 
SMM mode?

Thank you
Yao, Jiewen

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Gerd
> Hoffmann
> Sent: Wednesday, April 17, 2024 4:18 PM
> To: devel@edk2.groups.io; Ard Biesheuvel ;
> jie...@dobby.home.kraxel.org
> Cc: Oliver Steffen 
> Subject: Re: [edk2-devel] [PATCH 0/4] OvmfPkg: Add VirtHstiDxe driver
> 
> On Fri, Mar 22, 2024 at 03:27:31PM +0100, Gerd Hoffmann wrote:
> >
> >
> > Gerd Hoffmann (2):
> >   OvmfPkg/VirtHstiDxe: add varstore flash check
> >   OvmfPkg/VirtHstiDxe: add code flash check
> >
> > Konstantin Kostiuk (2):
> >   OvmfPkg: Add VirtHstiDxe driver
> >   OvmfPkg: Add VirtHstiDxe to OVMF firmware build
> 
> Ping.  Any comments on this series?
> 
> take care,
>   Gerd
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117919): https://edk2.groups.io/g/devel/message/117919
Mute This Topic: https://groups.io/mt/105086174/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V1 0/5] Move Tdx specific lib from SecurityPkg to OvmfPkg

[Yao, Jiewen]

I have merged this one https://github.com/tianocore/edk2/pull/5566

Hi Gerd
If you prefer that we move all TDX / SEV specific component to IntelTdx and 
AmdSev, I am OK with that.

Personally, I like your idea. Please submit Bugzilla and work on it, if you 
would like to.

Thank you
Yao, Jiewen


> -Original Message-
> From: Yao, Jiewen
> Sent: Tuesday, April 16, 2024 11:40 PM
> To: Gerd Hoffmann ; devel@edk2.groups.io; Xu, Min M
> 
> Cc: Ard Biesheuvel 
> Subject: RE: [edk2-devel] [PATCH V1 0/5] Move Tdx specific lib from 
> SecurityPkg
> to OvmfPkg
> 
> Yeah, I also considered that before. But after look at current code 
> structure, I give
> up.
> 
> Since following SEV component are NOT in AmdSev directory (especially the TCG
> one), I do not see a strong reason to put them to IntelTdx dir.
> https://github.com/tianocore/edk2/tree/master/OvmfPkg/AmdSevDxe
> https://github.com/tianocore/edk2/tree/master/OvmfPkg/Tcg/TpmMmioSevDec
> ryptPei
> https://github.com/tianocore/edk2/tree/master/OvmfPkg/Library/BaseMemEncr
> yptSevLib
> 
> I think we can follow the existing code structure in this patch set.
> 
> Thank you
> Yao, Jiewen
> 
> 
> > -Original Message-
> > From: Gerd Hoffmann 
> > Sent: Tuesday, April 16, 2024 6:16 PM
> > To: devel@edk2.groups.io; Xu, Min M 
> > Cc: Ard Biesheuvel ; Yao, Jiewen
> > 
> > Subject: Re: [edk2-devel] [PATCH V1 0/5] Move Tdx specific lib from 
> > SecurityPkg
> > to OvmfPkg
> >
> > On Mon, Apr 15, 2024 at 03:55:49PM +0800, Min Xu wrote:
> > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4752
> > >
> > > HashLibTdx and TdTcg2Dxe are designed for Intel TDX enlightened OVMF.
> > > They're more reasonable to be put in OvmfPkg than in SecurityPkg.
> > >
> > > SecTpmMeasurementLibTdx is not used anymore. So it is deleted in this
> > > patch-set.
> > >
> >
> > >  rename {SecurityPkg => OvmfPkg}/Library/HashLibTdx/HashLibTdx.c (100%)
> > >  rename {SecurityPkg => OvmfPkg}/Library/HashLibTdx/HashLibTdx.inf (100%)
> > >  rename {SecurityPkg => OvmfPkg}/Tcg/TdTcg2Dxe/MeasureBootPeCoff.c
> > (100%)
> > >  rename {SecurityPkg => OvmfPkg}/Tcg/TdTcg2Dxe/TdTcg2Dxe.c (100%)
> > >  rename {SecurityPkg => OvmfPkg}/Tcg/TdTcg2Dxe/TdTcg2Dxe.inf (100%)
> >
> > Better place them in OvmfPkg/IntelTdx ?
> >
> > Otherwise looks fine to me.
> >
> > take care,
> >   Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117892): https://edk2.groups.io/g/devel/message/117892
Mute This Topic: https://groups.io/mt/105531957/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V1 0/5] Move Tdx specific lib from SecurityPkg to OvmfPkg

[Yao, Jiewen]

Yeah, I also considered that before. But after look at current code structure, 
I give up.

Since following SEV component are NOT in AmdSev directory (especially the TCG 
one), I do not see a strong reason to put them to IntelTdx dir.
https://github.com/tianocore/edk2/tree/master/OvmfPkg/AmdSevDxe
https://github.com/tianocore/edk2/tree/master/OvmfPkg/Tcg/TpmMmioSevDecryptPei
https://github.com/tianocore/edk2/tree/master/OvmfPkg/Library/BaseMemEncryptSevLib

I think we can follow the existing code structure in this patch set.

Thank you
Yao, Jiewen


> -Original Message-
> From: Gerd Hoffmann 
> Sent: Tuesday, April 16, 2024 6:16 PM
> To: devel@edk2.groups.io; Xu, Min M 
> Cc: Ard Biesheuvel ; Yao, Jiewen
> 
> Subject: Re: [edk2-devel] [PATCH V1 0/5] Move Tdx specific lib from 
> SecurityPkg
> to OvmfPkg
> 
> On Mon, Apr 15, 2024 at 03:55:49PM +0800, Min Xu wrote:
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4752
> >
> > HashLibTdx and TdTcg2Dxe are designed for Intel TDX enlightened OVMF.
> > They're more reasonable to be put in OvmfPkg than in SecurityPkg.
> >
> > SecTpmMeasurementLibTdx is not used anymore. So it is deleted in this
> > patch-set.
> >
> 
> >  rename {SecurityPkg => OvmfPkg}/Library/HashLibTdx/HashLibTdx.c (100%)
> >  rename {SecurityPkg => OvmfPkg}/Library/HashLibTdx/HashLibTdx.inf (100%)
> >  rename {SecurityPkg => OvmfPkg}/Tcg/TdTcg2Dxe/MeasureBootPeCoff.c
> (100%)
> >  rename {SecurityPkg => OvmfPkg}/Tcg/TdTcg2Dxe/TdTcg2Dxe.c (100%)
> >  rename {SecurityPkg => OvmfPkg}/Tcg/TdTcg2Dxe/TdTcg2Dxe.inf (100%)
> 
> Better place them in OvmfPkg/IntelTdx ?
> 
> Otherwise looks fine to me.
> 
> take care,
>   Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117887): https://edk2.groups.io/g/devel/message/117887
Mute This Topic: https://groups.io/mt/105531957/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/9] Add DeviceSecurity feature based on PFP 1.06 spec

[Yao, Jiewen]

Hi Wenxing
I just realized that this libspdm submodule does NOT use the latest tag.

Since DMTF release 3.3.0 for libspdm 
https://github.com/DMTF/libspdm/releases/tag/3.3.0, I recommend we update to 
the latest one.

Thank you
Yao, Jiewen

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Yao, Jiewen
> Sent: Tuesday, April 16, 2024 5:26 PM
> To: Hou, Wenxing ; Kinney, Michael D
> ; devel@edk2.groups.io
> Cc: Sean Brogan ; Joey Vagedes
> ; Liming Gao ; Andrew
> Fish ; Liu, Zhiguang ; Kumar, Rahul R
> 
> Subject: Re: [edk2-devel] [PATCH 0/9] Add DeviceSecurity feature based on PFP
> 1.06 spec
> 
> Reviewed-by: Jiewen Yao 
> 
> > -Original Message-
> > From: Hou, Wenxing 
> > Sent: Monday, April 15, 2024 10:08 AM
> > To: Kinney, Michael D ; devel@edk2.groups.io
> > Cc: Sean Brogan ; Joey Vagedes
> > ; Liming Gao ; Andrew
> > Fish ; Liu, Zhiguang ; Kumar, Rahul
> R
> > ; Yao, Jiewen 
> > Subject: RE: [PATCH 0/9] Add DeviceSecurity feature based on PFP 1.06 spec
> >
> > Hi Mike,
> >
> > I have submitted PATCH v3, which updated the Readme.rst for libspdm
> submodule
> > license.  And I have added Leif.
> > Please review the PATCH v3.
> >
> > For your second feedback, I have investigate the situation.
> >
> > If we use 'git submodule update --init' to clone the submodule, the
> > mbedtls/openssl/cmocka in libspdm will not  be cloned due to the absence of
> the
> > '--recursive' option.
> > And it will not affect the build and use of DeviceSecurity.
> >
> >
> > Thanks,
> > Wenxing
> >
> >
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Tuesday, April 9, 2024 11:14 PM
> > To: Hou, Wenxing ; devel@edk2.groups.io
> > Cc: Sean Brogan ; Joey Vagedes
> > ; Liming Gao ; Andrew
> > Fish ; Liu, Zhiguang ; Kumar, Rahul
> R
> > ; Yao, Jiewen ; Kinney,
> > Michael D 
> > Subject: RE: [PATCH 0/9] Add DeviceSecurity feature based on PFP 1.06 spec
> >
> > +Leif
> >
> > Adding a new submodule requires review by the stewards to review the license
> > and the health and support of the submodule project.
> >
> > The top level Readme also requires updates.  It lists all the submodules and
> > licenses used. Please update this series with the Readme changes.
> >
> > https://github.com/tianocore/edk2?tab=readme-ov-file#license-details
> >
> > I also notice that libspdm has its own .gitmodules file that pulls in more
> > submodules.
> >
> > [submodule "os_stub/openssllib/openssl"]
> > path = os_stub/openssllib/openssl
> > url = https://github.com/openssl/openssl
> > [submodule "os_stub/mbedtlslib/mbedtls"]
> > path = os_stub/mbedtlslib/mbedtls
> > url = https://github.com/ARMmbed/mbedtls
> > [submodule "unit_test/cmockalib/cmocka"]
> > path = unit_test/cmockalib/cmocka
> > url = https://git.cryptomilk.org/projects/cmocka.git
> >
> >
> > edk2 already had openssl and mbedtls as submodules, does this mean that
> > openssl and mbedtls will be cloned twice in 2 different locations now?
> >
> > The edk2 project had issues with the stability of the cmocka server and 
> > changed
> > to a tianocore mirror of the cmocka submodule to improve CI stability. This 
> > is
> > another submodule that will be cloned twice and may reintroduce the 
> > potential
> > for CI stability issues.
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: Hou, Wenxing 
> > > Sent: Monday, April 1, 2024 7:31 PM
> > > To: devel@edk2.groups.io
> > > Cc: Sean Brogan ; Joey Vagedes
> > > ; Kinney, Michael D
> > > ; Liming Gao ;
> > > Andrew Fish ; Liu, Zhiguang ;
> > > Kumar, Rahul R ; Yao, Jiewen
> > > 
> > > Subject: [PATCH 0/9] Add DeviceSecurity feature based on PFP 1.06 spec
> > >
> > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2479
> > >
> > > In PFP spec 1.06, platform firmware records the device certificate and
> > > device measurement for each SPDM responder.
> > > This PATCH set implement the DeviceSecurityLib to support spdm device
> > > Authentication and Measurement.
> > >
> > > Libspdm as submodule is to support DeviceSecurity feature:
> > > https://github.com/DMTF/libspdm
> > >
> > > TCG PFP spec 1.06:
> > > https://trustedcomputinggroup.org/resource/pc-client-specific-
> > > platf

Re: [edk2-devel] [PATCH 0/9] Add DeviceSecurity feature based on PFP 1.06 spec

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Hou, Wenxing 
> Sent: Monday, April 15, 2024 10:08 AM
> To: Kinney, Michael D ; devel@edk2.groups.io
> Cc: Sean Brogan ; Joey Vagedes
> ; Liming Gao ; Andrew
> Fish ; Liu, Zhiguang ; Kumar, Rahul R
> ; Yao, Jiewen 
> Subject: RE: [PATCH 0/9] Add DeviceSecurity feature based on PFP 1.06 spec
> 
> Hi Mike,
> 
> I have submitted PATCH v3, which updated the Readme.rst for libspdm submodule
> license.  And I have added Leif.
> Please review the PATCH v3.
> 
> For your second feedback, I have investigate the situation.
> 
> If we use 'git submodule update --init' to clone the submodule, the
> mbedtls/openssl/cmocka in libspdm will not  be cloned due to the absence of 
> the
> '--recursive' option.
> And it will not affect the build and use of DeviceSecurity.
> 
> 
> Thanks,
> Wenxing
> 
> 
> -Original Message-
> From: Kinney, Michael D 
> Sent: Tuesday, April 9, 2024 11:14 PM
> To: Hou, Wenxing ; devel@edk2.groups.io
> Cc: Sean Brogan ; Joey Vagedes
> ; Liming Gao ; Andrew
> Fish ; Liu, Zhiguang ; Kumar, Rahul R
> ; Yao, Jiewen ; Kinney,
> Michael D 
> Subject: RE: [PATCH 0/9] Add DeviceSecurity feature based on PFP 1.06 spec
> 
> +Leif
> 
> Adding a new submodule requires review by the stewards to review the license
> and the health and support of the submodule project.
> 
> The top level Readme also requires updates.  It lists all the submodules and
> licenses used. Please update this series with the Readme changes.
> 
> https://github.com/tianocore/edk2?tab=readme-ov-file#license-details
> 
> I also notice that libspdm has its own .gitmodules file that pulls in more
> submodules.
> 
> [submodule "os_stub/openssllib/openssl"]
> path = os_stub/openssllib/openssl
> url = https://github.com/openssl/openssl
> [submodule "os_stub/mbedtlslib/mbedtls"]
> path = os_stub/mbedtlslib/mbedtls
> url = https://github.com/ARMmbed/mbedtls
> [submodule "unit_test/cmockalib/cmocka"]
> path = unit_test/cmockalib/cmocka
> url = https://git.cryptomilk.org/projects/cmocka.git
> 
> 
> edk2 already had openssl and mbedtls as submodules, does this mean that
> openssl and mbedtls will be cloned twice in 2 different locations now?
> 
> The edk2 project had issues with the stability of the cmocka server and 
> changed
> to a tianocore mirror of the cmocka submodule to improve CI stability. This is
> another submodule that will be cloned twice and may reintroduce the potential
> for CI stability issues.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Hou, Wenxing 
> > Sent: Monday, April 1, 2024 7:31 PM
> > To: devel@edk2.groups.io
> > Cc: Sean Brogan ; Joey Vagedes
> > ; Kinney, Michael D
> > ; Liming Gao ;
> > Andrew Fish ; Liu, Zhiguang ;
> > Kumar, Rahul R ; Yao, Jiewen
> > 
> > Subject: [PATCH 0/9] Add DeviceSecurity feature based on PFP 1.06 spec
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2479
> >
> > In PFP spec 1.06, platform firmware records the device certificate and
> > device measurement for each SPDM responder.
> > This PATCH set implement the DeviceSecurityLib to support spdm device
> > Authentication and Measurement.
> >
> > Libspdm as submodule is to support DeviceSecurity feature:
> > https://github.com/DMTF/libspdm
> >
> > TCG PFP spec 1.06:
> > https://trustedcomputinggroup.org/resource/pc-client-specific-
> > platform-firmware-profile-specification/
> >
> > The POC branch:
> > https://github.com/tianocore/edk2-staging/tree/DeviceSecurity
> >
> > And the PATCH set has passed the EDKII CI:
> > https://github.com/tianocore/edk2/pull/5508
> >
> > Cc: Sean Brogan 
> > Cc: Joey Vagedes 
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Andrew Fish 
> > Cc: Zhiguang Liu 
> > Cc: Rahul Kumar 
> > Cc: Jiewen Yao 
> > Signed-off-by: Wenxing Hou 
> >
> > Wenxing Hou (9):
> >   MdePkg: Add SPDM1.2 support.
> >   MdePkg: Add TCG PFP 1.06 support.
> >   MdePkg: Add devAuthBoot GlobalVariable
> >   MdeModulePkg/Variable: Add TCG SPDM device measurement update
> >   SecurityPkg: Add TCG PFP 1.06 support.
> >   SecurityPkg: add DeviceSecurity support
> >   .pytool/CISettings.py: add libspdm submodule.
> >   .gitmodule: Add libspdm submodule for EDKII
> >   SecurityPkg: Add libspdm submodule
> >
> >  .gitmodules   |3 +
> >  .pytool/CISettings.py 

Re: [edk2-devel] [PATCH V1 0/5] Move Tdx specific lib from SecurityPkg to OvmfPkg

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Xu, Min M 
> Sent: Monday, April 15, 2024 3:59 PM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Yao, Jiewen
> ; Gerd Hoffmann 
> Subject: RE: [PATCH V1 0/5] Move Tdx specific lib from SecurityPkg to OvmfPkg
> 
> The code is at: https://github.com/mxu9/edk2/tree/move_tdx.v1
> 
> > -Original Message-
> > From: Xu, Min M 
> > Sent: Monday, April 15, 2024 3:56 PM
> > To: devel@edk2.groups.io
> > Cc: Xu, Min M ; Ard Biesheuvel
> > ; Yao, Jiewen ; Gerd
> > Hoffmann 
> > Subject: [PATCH V1 0/5] Move Tdx specific lib from SecurityPkg to OvmfPkg
> >
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4752
> >
> > HashLibTdx and TdTcg2Dxe are designed for Intel TDX enlightened OVMF.
> > They're more reasonable to be put in OvmfPkg than in SecurityPkg.
> >
> > SecTpmMeasurementLibTdx is not used anymore. So it is deleted in this
> > patch-set.
> >
> > Cc: Ard Biesheuvel 
> > Cc: Jiewen Yao 
> > Cc: Gerd Hoffmann 
> > Signed-off-by: Min Xu 
> >
> > Min M Xu (5):
> >   Security/SecTpmMeasurementLibTdx: Delete unused
> > SecTpmMeasurementLibTdx
> >   OmvfPkg/HashLibTdx: Add HashLibTdx
> >   OvmfPkg/TdTcg2Dxe: Add TdTcg2Dxe
> >   OvmfPkg: Update TdTcg2Dxe path in OvmfPkgX64 and IntelTdxX64.dsc
> >   SecurityPkg: Delete TdTcg2Dxe and HashLibTdx in SecurityPkg
> >
> >  OvmfPkg/IntelTdx/IntelTdxX64.dsc  |   4 +-
> >  OvmfPkg/IntelTdx/IntelTdxX64.fdf  |   2 +-
> >  .../Library/HashLibTdx/HashLibTdx.c   |   0
> >  .../Library/HashLibTdx/HashLibTdx.inf |   0
> >  OvmfPkg/OvmfPkgX64.dsc|   4 +-
> >  OvmfPkg/OvmfPkgX64.fdf|   2 +-
> >  .../Tcg/TdTcg2Dxe/MeasureBootPeCoff.c |   0
> >  .../Tcg/TdTcg2Dxe/TdTcg2Dxe.c |   0
> >  .../Tcg/TdTcg2Dxe/TdTcg2Dxe.inf   |   0
> >  .../SecTpmMeasurementLibTdx.c | 175 --
> >  .../SecTpmMeasurementLibTdx.inf   |  34 
> >  SecurityPkg/SecurityPkg.dsc   |  16 --
> >  12 files changed, 6 insertions(+), 231 deletions(-)  rename {SecurityPkg =>
> > OvmfPkg}/Library/HashLibTdx/HashLibTdx.c (100%)  rename {SecurityPkg =>
> > OvmfPkg}/Library/HashLibTdx/HashLibTdx.inf (100%)  rename {SecurityPkg =>
> > OvmfPkg}/Tcg/TdTcg2Dxe/MeasureBootPeCoff.c (100%)  rename {SecurityPkg
> > => OvmfPkg}/Tcg/TdTcg2Dxe/TdTcg2Dxe.c (100%)  rename {SecurityPkg =>
> > OvmfPkg}/Tcg/TdTcg2Dxe/TdTcg2Dxe.inf (100%)  delete mode 100644
> > SecurityPkg/Library/SecTpmMeasurementLib/SecTpmMeasurementLibTdx.c
> >  delete mode 100644
> > SecurityPkg/Library/SecTpmMeasurementLib/SecTpmMeasurementLibTdx.inf
> >
> > --
> > 2.44.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117870): https://edk2.groups.io/g/devel/message/117870
Mute This Topic: https://groups.io/mt/105531957/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 0/2] SecurityPkg/OpalPasswordDxe: Update according to UEFI spec

[Yao, Jiewen]

Merged https://github.com/tianocore/edk2/pull/5563

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Cindy Kuo
> Sent: Tuesday, April 16, 2024 1:03 PM
> To: devel@edk2.groups.io
> Cc: Kuo, CindyX 
> Subject: [edk2-devel] [PATCH v5 0/2] SecurityPkg/OpalPasswordDxe: Update
> according to UEFI spec
> 
> For opalHii current design, it will display all NVME disks when the user 
> enters TCG
> Drive Management dynamically.
> Also, the related disk info form will be created along with the disks.
> These actions will call get/set browser to refresh the display, which is not 
> allowed
> in ACTION_FORM_OPEN callback function.
> 
> To meet UEFI 2.9 spec, a latency issue will be observed if the browser 
> callback
> action changes from ACTION_FORM_OPEN to ACTION_RETRIEVE.
> The NVNE disks will not be displayed when the user enters the formset at the 
> first
> time. Revisit the formset can see the update.
> So need to force reparsing the IFR binary when RETRIEVE.
> 
> v2:
> Format code with Uncrustify.
> 
> v3:
> Code refine based on comments from Dandan and Tina.
> 
> v4:
> Split solution into two patches as different purpose.
> 
> v5:
> Update commit message.
> 
> Cindy Kuo (2):
>   SecurityPkg/OpalPasswordDxe: Change callback action to meet UEFI spec
>   SecurityPkg/OpalPasswordDxe: Force reparsing IFR binary when RETRIEVE
> 
>  .../Tcg/Opal/OpalPassword/OpalDriver.h|  1 +
>  SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c   | 84 ---
>  .../Tcg/Opal/OpalPassword/OpalHiiFormValues.h |  6 ++
>  .../Tcg/Opal/OpalPassword/OpalPasswordDxe.inf |  1 +
>  .../Opal/OpalPassword/OpalPasswordForm.vfr|  8 +-
>  5 files changed, 87 insertions(+), 13 deletions(-)
> 
> --
> 2.44.0.windows.1
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117869): https://edk2.groups.io/g/devel/message/117869
Mute This Topic: https://groups.io/mt/105551557/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] SecurityPkg/Tcg2Config: Hide BIOS unsupported hash algorithm from UI

[Yao, Jiewen]

Merged https://github.com/tianocore/edk2/pull/5556

> -Original Message-
> From: Xu, Wei6 
> Sent: Friday, April 12, 2024 3:15 PM
> To: devel@edk2.groups.io
> Cc: Xu, Wei6 ; Kumar, Rahul R ;
> Yao, Jiewen 
> Subject: [PATCH v2 1/1] SecurityPkg/Tcg2Config: Hide BIOS unsupported hash
> algorithm from UI
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4731
> 
> TCG2 configuration UI shows all the hash algorithms that TPM hardware
> supports in the checkbox. If user only selects one algorithm that is
> supported by TPM hardware but not supported by BIOS and uncheck the
> others, the SyncPcrAllocationsAndPcrMask in Tcg2Pei will not be able
> to decide a viable PCR to activate, then an assert occurs.
> 
> Add check against PcdTcg2HashAlgorithmBitmap when deciding whether
> to suppress the hash algorithm checkbox to avoid user to select the
> hash algorithm which may cause an assert.
> 
> Cc: Rahul Kumar 
> Cc: Jiewen Yao 
> Signed-off-by: Wei6 Xu 
> Reviewed-by: Rahul Kumar 
> ---
>  SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c | 61 ++---
>  1 file changed, 41 insertions(+), 20 deletions(-)
> 
> diff --git a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c
> b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c
> index 6eb04c014448..aec7a903cf89 100644
> --- a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c
> +++ b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c
> @@ -722,33 +722,50 @@ FillBufferWithBootHashAlg (
>  }
> 
>  /**
> -  Set ConfigInfo according to TpmAlgHash.
> +  Set ConfigInfo according to TpmAlgHash and Tcg2HashAlgBitmap.
> 
>@param[in,out] Tcg2ConfigInfo   TCG2 config info.
>@param[in] TpmAlgHash   TpmAlgHash.
> +  @param[in] Tcg2HashAlgBitmapTCG2 Hash Algorithm Bitmap.
> 
>  **/
>  VOID
>  SetConfigInfo (
>IN OUT TCG2_CONFIGURATION_INFO  *Tcg2ConfigInfo,
> -  IN UINT32   TpmAlgHash
> +  IN UINT32   TpmAlgHash,
> +  IN UINT32   Tcg2HashAlgBitmap
>)
>  {
>switch (TpmAlgHash) {
>  case TPM_ALG_SHA1:
> -  Tcg2ConfigInfo->Sha1Supported = TRUE;
> +  if ((Tcg2HashAlgBitmap & HASH_ALG_SHA1) != 0) {
> +Tcg2ConfigInfo->Sha1Supported = TRUE;
> +  }
> +
>break;
>  case TPM_ALG_SHA256:
> -  Tcg2ConfigInfo->Sha256Supported = TRUE;
> +  if ((Tcg2HashAlgBitmap & HASH_ALG_SHA256) != 0) {
> +Tcg2ConfigInfo->Sha256Supported = TRUE;
> +  }
> +
>break;
>  case TPM_ALG_SHA384:
> -  Tcg2ConfigInfo->Sha384Supported = TRUE;
> +  if ((Tcg2HashAlgBitmap & HASH_ALG_SHA384) != 0) {
> +Tcg2ConfigInfo->Sha384Supported = TRUE;
> +  }
> +
>break;
>  case TPM_ALG_SHA512:
> -  Tcg2ConfigInfo->Sha512Supported = TRUE;
> +  if ((Tcg2HashAlgBitmap & HASH_ALG_SHA512) != 0) {
> +Tcg2ConfigInfo->Sha512Supported = TRUE;
> +  }
> +
>break;
>  case TPM_ALG_SM3_256:
> -  Tcg2ConfigInfo->Sm3Supported = TRUE;
> +  if ((Tcg2HashAlgBitmap & HASH_ALG_SM3_256) != 0) {
> +Tcg2ConfigInfo->Sm3Supported = TRUE;
> +  }
> +
>break;
>}
>  }
> @@ -809,16 +826,17 @@ InstallTcg2ConfigForm (
>IN OUT TCG2_CONFIG_PRIVATE_DATA  *PrivateData
>)
>  {
> -  EFI_STATUS  Status;
> -  EFI_HII_HANDLE  HiiHandle;
> -  EFI_HANDLE  DriverHandle;
> -  EFI_HII_CONFIG_ACCESS_PROTOCOL  *ConfigAccess;
> -  UINTN   Index;
> -  TPML_PCR_SELECTION  Pcrs;
> -  CHAR16  TempBuffer[1024];
> -  TCG2_CONFIGURATION_INFO Tcg2ConfigInfo;
> -  TPM2_PTP_INTERFACE_TYPE TpmDeviceInterfaceDetected;
> -  BOOLEAN IsCmdImp = FALSE;
> +  EFI_STATUS   Status;
> +  EFI_HII_HANDLE   HiiHandle;
> +  EFI_HANDLE   DriverHandle;
> +  EFI_HII_CONFIG_ACCESS_PROTOCOL   *ConfigAccess;
> +  UINTNIndex;
> +  TPML_PCR_SELECTION   Pcrs;
> +  CHAR16   TempBuffer[1024];
> +  TCG2_CONFIGURATION_INFO  Tcg2ConfigInfo;
> +  TPM2_PTP_INTERFACE_TYPE  TpmDeviceInterfaceDetected;
> +  BOOLEAN  IsCmdImp;
> +  EFI_TCG2_EVENT_ALGORITHM_BITMAP  Tcg2HashAlgorithmBitmap;
> 
>DriverHandle = NULL;
>ConfigAccess = >ConfigAccess;
> @@ -879,6 +897,8 @@ InstallTcg2ConfigForm (
>break;
>}
> 
> +  Tcg2HashAlgorithmBitmap = PcdGet32 (PcdTcg2HashAlgorithmBitmap);
> +
>ZeroMem (, sizeof (Tcg

Re: [edk2-devel] [PATCH v4 0/1] SecurityPkg/OpalPasswordDxe: Update UI according to UEFI spec

[Yao, Jiewen]

I am not sure why patch 0/1 contains the code. It should be the cover letter.

Also, if Dandan has already reviewed that, you may add R-B tag.

> -Original Message-
> From: Kuo, CindyX 
> Sent: Friday, April 12, 2024 4:31 PM
> To: devel@edk2.groups.io
> Cc: Kuo, CindyX ; Yao, Jiewen ;
> Kumar, Rahul R ; Bi, Dandan ;
> Tan, Ming ; Chen, Arthur G ;
> Chen, Xiao X ; Chen, Tina 
> Subject: [PATCH v4 0/1] SecurityPkg/OpalPasswordDxe: Update UI according to
> UEFI spec
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4735
> 
> Should not call HiiGetBrowserData() and HiiSetBrowserData() in FORM_OPEN
> call back function.
> Those APIs are called within OpalHiiSetBrowserData/OpalHiiGetBrowserData
> which have been used by OpalHii.c.
> 
> Change callback action from FORM_OPEN to RETRIEVE.
> 
> Cc: Jiewen Yao 
> Cc: Rahul Kumar 
> Cc: Dandan Bi 
> Cc: Ming Tan 
> Cc: Arthur Chen 
> Cc: Xiao X Chen 
> Cc: Tina Chen 
> Signed-off-by: CindyX Kuo 
> ---
>  SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c
> b/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c
> index 8035f44ebe..56ada1a9f3 100644
> --- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c
> +++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c
> @@ -632,7 +632,7 @@ DriverCallback (
>HiiKey.Raw = QuestionId;
>HiiKeyId   = (UINT8)HiiKey.KeyBits.Id;
> 
> -  if (Action == EFI_BROWSER_ACTION_FORM_OPEN) {
> +  if (Action == EFI_BROWSER_ACTION_RETRIEVE) {
>  switch (HiiKeyId) {
>case HII_KEY_ID_VAR_SUPPORTED_DISKS:
>  DEBUG ((DEBUG_INFO, "HII_KEY_ID_VAR_SUPPORTED_DISKS\n"));
> --
> 2.44.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117787): https://edk2.groups.io/g/devel/message/117787
Mute This Topic: https://groups.io/mt/105478921/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3] SecurityPkg/OpalPasswordDxe: Update UI according to UEFI spec

[Yao, Jiewen]

Thanks to explain the background to me. I appreciate that.
Also I trust Dandan's judgement as the UI expert.

But my question remains: Are 2 and 3 related to UEFI spec update? IMHO, they 
are NOT required if we just want to do update for UEFI spec.
If it is such case, please file a new issue, or split them into different patch.

In each patch, please explain as clear as possible, on why it is needed.
That will help reviewer or maintainer to have better understanding.

Last but not least, please describe what test you have done for the patch.

Thank you
Yao, Jiewen

> -Original Message-
> From: Chen, Tina 
> Sent: Friday, April 12, 2024 11:25 AM
> To: Yao, Jiewen ; Bi, Dandan ;
> Kuo, CindyX ; devel@edk2.groups.io
> Cc: Kumar, Rahul R ; Tan, Ming
> ; Chen, Arthur G ; Chen, Xiao X
> 
> Subject: RE: [PATCH v3] SecurityPkg/OpalPasswordDxe: Update UI according to
> UEFI spec
> 
> Hi JieWen,
> 
> For opalHii current design, it will display all NVME disks when the user 
> enters TCG
> Drive Management dynamically.
> Also, the related disk info form will be created along with the disks.
> These actions will call get/set browser to refresh the display.
> To meet UEFI 2.9 spec, a latency issue will be observed if the browser action
> changes from ACTION_FORM_OPEN to ACTION_RETRIEVE due to the current Hii
> browser design flow.
> The NVNE disks will not be able to display when the user enters the formset.
> (Revisit the formset can see the update.)
> After discussing with Dandan, came up with a solution to force reparsing the 
> IFR
> binary when RETRIEVE.
> That's why it needs to have additional changes besides changing the execute
> action only.
> Thanks.
> 
> Sincerely,
> Tina
> 
> -Original Message-
> From: Yao, Jiewen 
> Sent: Thursday, April 11, 2024 23:45
> To: Bi, Dandan ; Kuo, CindyX ;
> devel@edk2.groups.io
> Cc: Kumar, Rahul R ; Tan, Ming
> ; Chen, Arthur G ; Chen, Xiao X
> ; Chen, Tina 
> Subject: RE: [PATCH v3] SecurityPkg/OpalPasswordDxe: Update UI according to
> UEFI spec
> 
> Hi
> It seems this patch adds more change than just "update UI according to UEFI
> spec".
> 
> Please help me understand why we need below 2 and 3. Are you required for
> UEFI spec update?
> 
> > 2. Create dummy label with suppressif statement in VFR for form update 
> > usage.
> > 3. Add HiiUpdateForm() to force reparsing the IFR binary.
> 
> Thank you
> Yao, Jiewen
> 
> 
> > -Original Message-
> > From: Bi, Dandan 
> > Sent: Thursday, April 11, 2024 7:15 PM
> > To: Kuo, CindyX ; devel@edk2.groups.io
> > Cc: Yao, Jiewen ; Kumar, Rahul R
> > ; Tan, Ming ; Chen,
> > Arthur G ; Chen, Xiao X
> > ; Chen, Tina 
> > Subject: RE: [PATCH v3] SecurityPkg/OpalPasswordDxe: Update UI
> > according to UEFI spec
> >
> > Reviewed-by: Dandan Bi 
> >
> >
> > Thanks,
> > Dandan
> > -Original Message-
> > From: Kuo, CindyX 
> > Sent: Thursday, April 11, 2024 11:11 AM
> > To: devel@edk2.groups.io
> > Cc: Kuo, CindyX ; Yao, Jiewen
> > ; Kumar, Rahul R ; Bi,
> > Dandan ; Tan, Ming ; Chen,
> > Arthur G ; Chen, Xiao X
> > ; Chen, Tina 
> > Subject: [PATCH v3] SecurityPkg/OpalPasswordDxe: Update UI according
> > to UEFI spec
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4735
> >
> > Should not call HiiGetBrowserData() and HiiSetBrowserData() in
> > FORM_OPEN call back function.
> > Those APIs are called within
> > OpalHiiSetBrowserData/OpalHiiGetBrowserData
> > which have been used by OpalHii.c.
> >
> > 1. Change callback action from FORM_OPEN to RETRIEVE.
> > 2. Create dummy label with suppressif statement in VFR for form update 
> > usage.
> > 3. Add HiiUpdateForm() to force reparsing the IFR binary.
> >
> > Cc: Jiewen Yao 
> > Cc: Rahul Kumar 
> > Cc: Dandan Bi 
> > Cc: Ming Tan 
> > Cc: Arthur Chen 
> > Cc: Xiao X Chen 
> > Cc: Tina Chen 
> > Signed-off-by: CindyX Kuo 
> > ---
> >  .../Tcg/Opal/OpalPassword/OpalDriver.h|  1 +
> >  SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c   | 84 ---
> >  .../Tcg/Opal/OpalPassword/OpalHiiFormValues.h |  6
> > ++  .../Tcg/Opal/OpalPassword/OpalPasswordDxe.inf |  1 +
> >  .../Opal/OpalPassword/OpalPasswordForm.vfr|  8 +-
> >  5 files changed, 87 insertions(+), 13 deletions(-)
> >
> > diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.h
> > b/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.h
> > index 2089bd81b6..1a4671c602 100644
> > --- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriv

Re: [edk2-devel] [PATCH v3] SecurityPkg/OpalPasswordDxe: Update UI according to UEFI spec

[Yao, Jiewen]

Hi
It seems this patch adds more change than just "update UI according to UEFI 
spec".

Please help me understand why we need below 2 and 3. Are you required for UEFI 
spec update?

> 2. Create dummy label with suppressif statement in VFR for form update usage.
> 3. Add HiiUpdateForm() to force reparsing the IFR binary.

Thank you
Yao, Jiewen


> -Original Message-
> From: Bi, Dandan 
> Sent: Thursday, April 11, 2024 7:15 PM
> To: Kuo, CindyX ; devel@edk2.groups.io
> Cc: Yao, Jiewen ; Kumar, Rahul R
> ; Tan, Ming ; Chen, Arthur G
> ; Chen, Xiao X ; Chen, Tina
> 
> Subject: RE: [PATCH v3] SecurityPkg/OpalPasswordDxe: Update UI according to
> UEFI spec
> 
> Reviewed-by: Dandan Bi 
> 
> 
> Thanks,
> Dandan
> -Original Message-
> From: Kuo, CindyX 
> Sent: Thursday, April 11, 2024 11:11 AM
> To: devel@edk2.groups.io
> Cc: Kuo, CindyX ; Yao, Jiewen ;
> Kumar, Rahul R ; Bi, Dandan ;
> Tan, Ming ; Chen, Arthur G ;
> Chen, Xiao X ; Chen, Tina 
> Subject: [PATCH v3] SecurityPkg/OpalPasswordDxe: Update UI according to UEFI
> spec
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4735
> 
> Should not call HiiGetBrowserData() and HiiSetBrowserData() in FORM_OPEN call
> back function.
> Those APIs are called within OpalHiiSetBrowserData/OpalHiiGetBrowserData
> which have been used by OpalHii.c.
> 
> 1. Change callback action from FORM_OPEN to RETRIEVE.
> 2. Create dummy label with suppressif statement in VFR for form update usage.
> 3. Add HiiUpdateForm() to force reparsing the IFR binary.
> 
> Cc: Jiewen Yao 
> Cc: Rahul Kumar 
> Cc: Dandan Bi 
> Cc: Ming Tan 
> Cc: Arthur Chen 
> Cc: Xiao X Chen 
> Cc: Tina Chen 
> Signed-off-by: CindyX Kuo 
> ---
>  .../Tcg/Opal/OpalPassword/OpalDriver.h|  1 +
>  SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c   | 84 ---
>  .../Tcg/Opal/OpalPassword/OpalHiiFormValues.h |  6
> ++  .../Tcg/Opal/OpalPassword/OpalPasswordDxe.inf |  1 +
>  .../Opal/OpalPassword/OpalPasswordForm.vfr|  8 +-
>  5 files changed, 87 insertions(+), 13 deletions(-)
> 
> diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.h
> b/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.h
> index 2089bd81b6..1a4671c602 100644
> --- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.h
> +++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.h
> @@ -23,6 +23,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  #include 
>  #include 
> +#include 
> 
>  #include 
>  #include 
> diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c
> b/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c
> index 8035f44ebe..47af4fee40 100644
> --- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c
> +++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c
> @@ -40,6 +40,7 @@ EFI_HII_HANDLE  gHiiPackageListHandle = NULL;  //
>  const EFI_GUID  gHiiPackageListGuid   = PACKAGE_LIST_GUID;
>  const EFI_GUID  gHiiSetupVariableGuid = SETUP_VARIABLE_GUID;
> +const EFI_GUID  gOpalSetupFormSetGuid = SETUP_FORMSET_GUID;
> 
>  //
>  // Structure that contains state of the HII @@ -611,10 +612,15 @@
> DriverCallback (
>EFI_BROWSER_ACTION_REQUEST*ActionRequest
>)
>  {
> -  HII_KEYHiiKey;
> -  UINT8  HiiKeyId;
> -  UINT32 PpRequest;
> -  OPAL_DISK  *OpalDisk;
> +  HII_KEY HiiKey;
> +  UINT8   HiiKeyId;
> +  UINT32  PpRequest;
> +  OPAL_DISK   *OpalDisk;
> +  EFI_STATUS  Status;
> +  VOID*StartOpCodeHandle;
> +  VOID*EndOpCodeHandle;
> +  EFI_IFR_GUID_LABEL  *StartLabel;
> +  EFI_IFR_GUID_LABEL  *EndLabel;
> 
>if (ActionRequest != NULL) {
>  *ActionRequest = EFI_BROWSER_ACTION_REQUEST_NONE; @@ -632,15
> +638,69 @@ DriverCallback (
>HiiKey.Raw = QuestionId;
>HiiKeyId   = (UINT8)HiiKey.KeyBits.Id;
> 
> -  if (Action == EFI_BROWSER_ACTION_FORM_OPEN) {
> -switch (HiiKeyId) {
> -  case HII_KEY_ID_VAR_SUPPORTED_DISKS:
> -DEBUG ((DEBUG_INFO, "HII_KEY_ID_VAR_SUPPORTED_DISKS\n"));
> -return HiiPopulateMainMenuForm ();
> +  if (Action == EFI_BROWSER_ACTION_RETRIEVE) {
> +if ((HiiKeyId == HII_KEY_ID_VAR_SUPPORTED_DISKS) || (HiiKeyId ==
> HII_KEY_ID_VAR_SELECTED_DISK_AVAILABLE_ACTIONS)) {
> +  //
> +  // Allocate space for creation of UpdateData Buffer
> +  //
> +  StartOpCodeHandle = HiiAllocateOpCodeHandle ();
> +  if (StartOpCodeHandle == NULL) {
> +return EFI_OUT_OF_RESOURCES;
> +  }
> +
> +  EndOpCodeHandle = HiiAllocateOpCodeHandle ();
> +  if (EndOpCodeHandle == NULL) {
> +return EFI_OUT_OF_RESOURCES;
> +  }
&

Re: [edk2-devel] [RFC PATCH] OvmfPkg/SecurityPkg: Add build option for coexistance of vTPM and RTMR.

[Yao, Jiewen]

Please allow me to clarify what you are proposing:
Do you mean in vTPM case, we extend both, but we only need TCG event log, NOT 
CC event log?




> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Gerd
> Hoffmann
> Sent: Thursday, April 11, 2024 4:08 PM
> To: Ard Biesheuvel 
> Cc: devel@edk2.groups.io; Yao, Jiewen ; Dionna Amalie
> Glaze ; Mikko Ylinen ;
> James Bottomley ; Tom Lendacky
> ; Michael Roth ; qinkun
> Bao ; linux-c...@lists.linux.dev; Aktas, Erdem
> ; Peter Gonda ; Johnson,
> Simon P ; Xiang, Qinglan
> 
> Subject: Re: [edk2-devel] [RFC PATCH] OvmfPkg/SecurityPkg: Add build option 
> for
> coexistance of vTPM and RTMR.
> 
>   Hi,
> 
> > Given that RTMR is a proper subset of vTPM (modulo the PCR/RTMR index
> > conversion), I feel that it should be the CoCo firmware's
> > responsibility to either:
> > - expose RTMR and not vTPM
> > - expose vTPM, and duplicate each measurement into RTMR as they are taken
> 
> That approach looks good to me.  It will make sure vTPM and RTMR
> measurements are consistent and it also solves the event log issue
> (we don't need separate vTPM and RTMR entries then).
> 
> take care,
>   Gerd
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117628): https://edk2.groups.io/g/devel/message/117628
Mute This Topic: https://groups.io/mt/105070442/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [RFC PATCH] OvmfPkg/SecurityPkg: Add build option for coexistance of vTPM and RTMR.

[Yao, Jiewen]

Hi Dionna/Qinkun
I am not sure if systemd is the last software in guest we need to patch to 
support coexistence to extend the measurement.
Are you aware of any other Linux guest software needs to be updated? Such as 
Linux IMA (Integrity Measurement Architecture)?

To move this forward.

In Intel, we had discussed and we did see the potential security risk. As I 
mentioned in the first email, "In case that any the guest component only knows 
one of vTPM or RTMR, and only extends one of vTPM or RTMR, but the other one 
only verifies the other, then the chain of trust is broken."

At same time, we also respect that it might be a valid use case for Google.
I would like to ask the opinion in the EDKII community, especially the OVMF and 
CC maintainer and reviewer.


Hi Ard Biesheuvel
Do you think Kernel is OK with this coexistence proposal?
Are you willing to give "reviewed-by"?

Hi Gerd Hoffman
Do you think RedHat is OK with this coexistence proposal?
Are you willing to give "reviewed-by"?

Hi James Bottomley
Do you think IBM is OK with this coexistence proposal?
Are you willing to give "reviewed-by"?

Hi Tom Lendacky/Michael Roth
Do you think AMD is OK with this coexistence proposal?
Are you willing to give "reviewed-by"?


Thank you
Yao, Jiewen


> -Original Message-
> From: Dionna Amalie Glaze 
> Sent: Monday, March 25, 2024 11:29 PM
> To: Mikko Ylinen 
> Cc: Gerd Hoffmann ; Yao, Jiewen ;
> qinkun Bao ; devel@edk2.groups.io; linux-
> c...@lists.linux.dev; Aktas, Erdem ; Ard Biesheuvel
> ; Peter Gonda ; James Bottomley
> ; Tom Lendacky ; Michael
> Roth 
> Subject: Re: [RFC PATCH] OvmfPkg/SecurityPkg: Add build option for coexistance
> of vTPM and RTMR.
> 
> On Mon, Mar 25, 2024 at 6:07 AM Mikko Ylinen
>  wrote:
> >
> > > >
> > > > Looking at systemd-boot I see it will likewise not measure to both RTMR
> > > > and vTPM, but with reversed priority (use vTPM not RTMR in case both are
> > > > present).
> > > >
> > >
> > > Interesting. Thanks for this report. We'll push for the changed
> > > semantics here if the spec is indeed changed, and request partner
> > > distros in the CCC to include the updated systemd-boot.
> >
> > FWIW, my RTMRs patch to systemd was merged quite recently so it's not
> > included in any systemd release yet. (It was mainly implemented for the
> > UKI case that allows TDVF to boot a UKI image directly and then have the
> > image sections measured separately.)
> >
> 
> Thank you, I've proposed a change in
> https://github.com/systemd/systemd/pull/31939
> 
> 
> --
> -Dionna Glaze, PhD (she/her)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117606): https://edk2.groups.io/g/devel/message/117606
Mute This Topic: https://groups.io/mt/105070442/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 00/13] Add SmmRelocationLib

[Yao, Jiewen]

Hello
Would you please describe what test has been done for OvmfPkg?
For example, have you validated OVMF with SMM enabled?


> -Original Message-
> From: Wu, Jiaxin 
> Sent: Wednesday, April 10, 2024 9:57 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Zeng, Star ; Gerd
> Hoffmann ; Kumar, Rahul R ;
> Dong, Guo ; Rhodes, Sean ; Lu,
> James ; Guo, Gua ; Ard Biesheuvel
> ; Yao, Jiewen 
> Subject: [PATCH v1 00/13] Add SmmRelocationLib
> 
> Intel plans to separate the smbase relocation logic from
> PiSmmCpuDxeSmm driver, and the related behavior will be
> moved to the new interface defined by the SmmRelocationLib
> class.
> 
> The SmmRelocationLib class provides the SmmRelocationInit()
> interface for platform to do the smbase relocation, which
> shall provide below 2 functionalities:
> 1. Relocate smbases for each processor.
> 2. Create the gSmmBaseHobGuid HOB.
> 
> With SmmRelocationLib, PiSmmCpuDxeSmm driver (which runs at
> a later phase) can be simplfied as below for SMM init:
> 1. Consume the gSmmBaseHobGuid HOB for the relocated smbases
> for each Processor.
> 2. Execute the early SMM Init.
> 
> Cc: Ray Ni 
> Cc: Zeng Star 
> Cc: Gerd Hoffmann 
> Cc: Rahul Kumar 
> Cc: Guo Dong 
> Cc: Sean Rhodes 
> Cc: James Lu 
> Cc: Gua Guo 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Signed-off-by: Jiaxin Wu 
> 
> Jiaxin Wu (13):
>   UefiCpuPkg: Add SmmRelocationLib class
>   UefiCpuPkg/SmmRelocationLib: Add SmmRelocationLib library instance
>   UefiCpuPkg/SmmRelocationLib: Add library instance for OVMF
>   UefiCpuPkg/SmmRelocationLib: Add library instance for AMD
>   UefiCpuPkg/UefiCpuPkg.dsc: Include SmmRelocationLib in UefiCpuPkg
>   UefiPayloadPkg/UefiPayloadPkg.dsc: Include SmmRelocationLib
>   OvmfPkg: Include SmmRelocationLib in OvmfPkg
>   OvmfPkg/PlatformInitLib: Create gEfiSmmSmramMemoryGuid
>   OvmfPkg/SmmAccess: Consume gEfiSmmSmramMemoryGuid
>   OvmfPkg/PlatformInitLib: Create gEfiAcpiVariableGuid
>   OvmfPkg/SmmCpuFeaturesLib: Check Smbase Relocation is done or not
>   OvmfPkg/PlatformPei: Relocate SmBases in PEI phase
>   UefiCpuPkg/PiSmmCpuDxeSmm: Remove SmBases relocation logic
> 
>  OvmfPkg/AmdSev/AmdSevX64.dsc   |   1 +
>  OvmfPkg/CloudHv/CloudHvX64.dsc |   1 +
>  OvmfPkg/Library/PlatformInitLib/MemDetect.c| 104 ++--
>  .../Library/PlatformInitLib/PlatformInitLib.inf|   6 +-
>  .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c  |  33 +-
>  OvmfPkg/Microvm/MicrovmX64.dsc |   1 +
>  OvmfPkg/OvmfPkgIa32.dsc|   1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc |   1 +
>  OvmfPkg/OvmfPkgX64.dsc |   1 +
>  OvmfPkg/PlatformPei/Platform.c |   1 +
>  OvmfPkg/PlatformPei/Platform.h |   5 +
>  OvmfPkg/PlatformPei/PlatformPei.inf|   5 +-
>  OvmfPkg/PlatformPei/SmmRelocation.c|  80 +++
>  OvmfPkg/SmmAccess/SmmAccess2Dxe.c  |   4 +-
>  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf|   5 +
>  OvmfPkg/SmmAccess/SmmAccessPei.c   |  88 +--
>  OvmfPkg/SmmAccess/SmmAccessPei.inf |   7 +-
>  OvmfPkg/SmmAccess/SmramInternal.c  |  73 +--
>  OvmfPkg/SmmAccess/SmramInternal.h  |  18 +-
>  UefiCpuPkg/Include/Library/SmmRelocationLib.h  |  42 ++
>  .../SmmRelocationLib/AmdSmmRelocationLib.inf   |  61 ++
>  .../SmmRelocationLib/AmdSmramSaveStateConfig.c | 109 
>  .../SmmRelocationLib}/Ia32/Semaphore.c |  13 +-
>  .../Library/SmmRelocationLib/Ia32/SmmInit.nasm | 157 +
>  .../SmmRelocationLib/InternalSmmRelocationLib.h| 141 +
>  .../SmmRelocationLib/OvmfSmmRelocationLib.inf  |  61 ++
>  .../SmmRelocationLib/OvmfSmramSaveStateConfig.c| 107 
>  .../Library/SmmRelocationLib/SmmRelocationLib.c| 659
> +
>  .../Library/SmmRelocationLib/SmmRelocationLib.inf  |  61 ++
>  .../SmmRelocationLib/SmramSaveStateConfig.c|  91 +++
>  .../SmmRelocationLib}/X64/Semaphore.c  |  13 +-
>  .../SmmRelocationLib}/X64/SmmInit.nasm |  93 ++-
>  UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c  |  21 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmInit.nasm|  96 ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  |   6 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 322 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  98 ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf   |   4 -
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmramSaveState.c |  69 ---
>  UefiCpuPkg/UefiCpuPkg.dec  |   3 +
>  UefiCpuPkg/Ue

Re: [edk2-devel] [PATCH v4] SecurityPkg/SecureBootConfigDxe: Update UI according to UEFI spec

[Yao, Jiewen]

Thanks.https://github.com/tianocore/edk2/pull/5533

> -Original Message-
> From: Bi, Dandan 
> Sent: Sunday, April 7, 2024 10:07 AM
> To: Tan, Ming ; devel@edk2.groups.io
> Cc: Xu, Min M ; Yao, Jiewen ;
> POLUDOV, FELIX 
> Subject: RE: [PATCH v4] SecurityPkg/SecureBootConfigDxe: Update UI according
> to UEFI spec
> 
> Reviewed-by: Dandan Bi 
> 
> -Original Message-
> From: Tan, Ming 
> Sent: Tuesday, April 2, 2024 4:32 PM
> To: devel@edk2.groups.io
> Cc: Xu, Min M ; Yao, Jiewen ; Bi,
> Dandan ; POLUDOV, FELIX 
> Subject: [PATCH v4] SecurityPkg/SecureBootConfigDxe: Update UI according to
> UEFI spec
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4713
> 
> In UEFI_Spec_2_10_Aug29.pdf page 1694 section 35.5.4 for
> EFI_BROWSER_ACTION_FORM_OPEN:
> NOTE: EFI_FORM_BROWSER2_PROTOCOL.BrowserCallback() cannot be used
> with this browser action because question values have not been retrieved yet.
> 
> So should not call HiiGetBrowserData() and HiiSetBrowserData() in FORM_OPEN
> call back function.
> 
> Now call SecureBootExtractConfigFromVariable() and update
> IfrNvData->ListCount to save the change to EFI variable, then HII use
> IfrNvData->EFI
> variable to control the UI.
> 
> Cc: Min Xu 
> Cc: Jiewen Yao 
> Cc: Dandan Bi 
> Cc: Felix Polyudov 
> Signed-off-by: Ming Tan 
> ---
>   PR: https://github.com/tianocore/edk2/pull/5411
> 
>   V4: Fix a Cc issue of miss a space.
>   V3: According to Dandan Bi's feedback, does not call
> SecureBootExtractConfigFromVariable() at last, but call it as needed.
>   And add more code for update IfrNvData->ListCount.
>   V2: Change code style to pass uncrustify check.
> 
>  .../SecureBootConfigImpl.c| 42 +++
>  1 file changed, 25 insertions(+), 17 deletions(-)
> 
> diff --git
> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigIm
> pl.c
> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigIm
> pl.c
> index 2c11129526..6d4560c39b 100644
> ---
> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigIm
> pl.c
> +++ b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCo
> +++ nfigImpl.c
> @@ -3366,6 +3366,8 @@ SecureBootExtractConfigFromVariable (
>  ConfigData->FileEnrollType = UNKNOWN_FILE_TYPE;   } +  ConfigData-
> >ListCount = Private->ListCount;+   //   // If it is Physical Presence User, 
> >set the
> PhysicalPresent to true.   //@@ -4541,12 +4543,13 @@ SecureBootCallback (
>EFI_HII_POPUP_PROTOCOL  *HiiPopup;   EFI_HII_POPUP_SELECTION
> UserSelection; -  Status = EFI_SUCCESS;-  SecureBootEnable   = 
> NULL;-
> SecureBootMode = NULL;-  SetupMode  = NULL;-  File   
> = NULL;-
> EnrollKeyErrorCode = None_Error;+  Status   = EFI_SUCCESS;+
> SecureBootEnable = NULL;+  SecureBootMode   = NULL;+  SetupMode
> = NULL;+  File = NULL;+  EnrollKeyErrorCode   = None_Error;+
> GetBrowserDataResult = FALSE;if ((This == NULL) || (Value == NULL) ||
> (ActionRequest == NULL)) { return EFI_INVALID_PARAMETER;@@ -4565,15
> +4568,12 @@ SecureBootCallback (
>  return EFI_OUT_OF_RESOURCES;   } -  GetBrowserDataResult =
> HiiGetBrowserData (,
> mSecureBootStorageName, BufferSize, (UINT8 *)IfrNvData);-   if (Action ==
> EFI_BROWSER_ACTION_FORM_OPEN) { if (QuestionId ==
> KEY_SECURE_BOOT_MODE) {   //   // Update secure boot strings when
> opening this form   //-  Status = UpdateSecureBootString (Private);-
> SecureBootExtractConfigFromVariable (Private, IfrNvData);+  Status
>  =
> UpdateSecureBootString (Private);   mIsEnterSecureBootForm = TRUE; } 
> else
> {   //@@ -4587,23 +4587,22 @@ SecureBootCallback (
>(QuestionId == KEY_SECURE_BOOT_DBT_OPTION))
> { CloseEnrolledFile (Private->FileContext);-  } else if 
> (QuestionId ==
> KEY_SECURE_BOOT_DELETE_ALL_LIST) {-//-// Update ListCount 
> field in
> varstore-// Button "Delete All Signature List" is-// enable 
> when ListCount
> is greater than 0.-//-IfrNvData->ListCount = 
> Private->ListCount;   } }
> goto EXIT;   } +  GetBrowserDataResult = HiiGetBrowserData
> (, mSecureBootStorageName, BufferSize,
> (UINT8 *)IfrNvData);+   if (Action == EFI_BROWSER_ACTION_RETRIEVE)
> { Status = EFI_UNSUPPORTED; if (QuestionId == KEY_SECURE_BOOT_MODE)
> {   if (mIsEnterSecureBootForm) {+if (GetBrowserDataResult) {+
> SecureBootExtractConfigFromVariable (Private, IfrNvData);+}+ 
> Value-
> >u8 = SECURE_BOOT_

Re: [edk2-devel] [RFC PATCH] OvmfPkg/SecurityPkg: Add build option for coexistance of vTPM and RTMR.

[Yao, Jiewen]

Please aware that this option will cause potential security risk.

In case that any the guest component only knows one of vTPM or RTMR, and only 
extends one of vTPM or RTMR, but the other one only verifies the other, then 
the chain of trust is broken.
This solution is secure if and only if all guest components aware of 
coexistence, and can ensure all measurements are extended to both vTPM and RTMR.
But I am not sure if all guest components are ready today.

Since this option caused a potential risk / misuse breaking the chain of trust, 
I recommend we have at least one more company to endorse the runtime 
co-existence of vTPM and RTMR.
Also, I would like to hear the opinions from other companies.


BTW: A small comment: In EDKII, we don’t use MACRO. Please change to PCD 
(default false), after you get endorsement from other compony.

Thank you
Yao, Jiewen

> -Original Message-
> From: Dionna Amalie Glaze 
> Sent: Friday, March 22, 2024 1:47 AM
> To: qinkun Bao 
> Cc: devel@edk2.groups.io; linux-c...@lists.linux.dev; Aktas, Erdem
> ; Yao, Jiewen ; Ard
> Biesheuvel ; Peter Gonda ; James
> Bottomley ; Gerd Hoffmann ; Tom
> Lendacky ; Michael Roth
> 
> Subject: Re: [RFC PATCH] OvmfPkg/SecurityPkg: Add build option for coexistance
> of vTPM and RTMR.
> 
> On Thu, Mar 21, 2024 at 9:59 AM qinkun Bao  wrote:
> >
> > From: Qinkun Bao 
> >
> > The UEFI v2.10 spec defines the protocol EFI_CC_MEASUREMENT_PROTOCOL
> > to enable (for example) RTMR-based boot measurement for TDX VMs.
> > With the current UEFI spec’s “should not” wording and EDK2
> > implementation, TPM measurement in TDVF is disabled when
> > RTMR measurement is enabled.
> >
> > Mutual exclusion of the CC measurement protocol and TCG measurement
> > protocol breaks backwards compatibility, which makes adoption of RTMRs
> > challenging. A virtualized TPM device (vTPM) managed by the host VMM
> > makes boot measurements visible to the VMM operator, but this is an
> > oft-requested feature that users can choose to accept.
> >
> > The TPM has been a standard for over a decade and many existing
> > applications rely on the TPM. Both inside and outside Google,
> > we have many users that require vTPM, including features that are
> > not easily available via RTMRs (e.g. sealing using keys that the
> > guest OS cannot access).
> >
> > This patch adds a non-default build option to allow the coexistence
> > of both the CC measurement and TCG protocols. Not included is a
> > vendor-specific measured event in the CC event log that indicates
> > whether a vTPM is attached or not.
> 
> Thank you very much for starting this conversation. I'll carry forward
> more context from our more senior engineers.
> 
> '
> Not measuring into all possible measurement banks led to
> (CVE-2021-42299) with TPM PCR banks. Let's not repeat this problem.
> Requiring a monumental shift of all attestation-based applications to
> CC_MEASUREMENT_PROTOCOL and CEL in one step is going to make the
> technology very difficult to adopt.
> '
> 
> The combination of these requirements means careful rollout of
> attestation verification policies to match the updated behavior of the
> firmware.
> The measured boot components have to be known to correctly measure
> into all available measurement protocols and register banks.
> The firmware has to be known specifically which protocols it makes available.
> 
> Now, how this is done is a vendor matter for now. If there is strong
> demand for making vTPM attachment status known for folks who really
> don't want a TPM and don't trust the VMM to not attach one anyway,
> we'll need to agree that the CEL should have an entry for an RTMR0
> update detailing the combination of measurement protocols in use.
> Likewise PCR1 should have an event detailing the protocols in use if
> we want to make CC_MEASUREMENT_PROTOCOL usage configurable.
> 
> Philosophizing aside that both protocols should be allowed to be
> active and that the spec should be updated to say something along the
> lines of "all measurement protocols that are active (i.e., any
> combination of EFI_CC_MEASUREMENT_PROTOCOL, EFI_TCG_PROTOCOL,
> EFI_TCG2_PROTOCOL) should have comparable events measured if any one
> protocol receives measurements. All measurement protocols that are
> active MUST measure comparable separator events if any protocol
> receives a separator event." This is crossing a spec boundary between
> USWG and TCG, so I don't know where specifically the language needs to
> go, but we need some language that implementers can use as
> justification for measuring into any found protocol and not just at
> most one.
> 
> It's not lost on me that it is sim

Re: [edk2-devel] [PATCH 1/2] OvmfPkg: Add VirtHstiDxe driver

[Yao, Jiewen]

I agree that not all bits make sense to virtual machine.
However, I do see some bits should be there if we really want to add HSTI to 
report security propery.

Please take a look at the HSTI spec - 
https://learn.microsoft.com/en-us/windows-hardware/test/hlk/testref/hardware-security-testability-specification
For example:
Do you use RSA 2048 and SHA256 only (or higher but not lower than this)
Compatibility Support Modules (CSM)
Firmware Code must be present in protected storage
Secure firmware update process
Do you have backdoors to override SecureBoot
Protection from internal and external DMA


Another question: I notice you report platform as “Intel(R) 9-Series v1”.
Is that right configuration for current OVMF?
I think there is some configuration detection, such as 
https://github.com/tianocore/edk2/blob/master/OvmfPkg/PlatformPei/Platform.c.


All in all, I don’t think it is a right way to provide an *empty* one just to 
pass the SVVP.
That totally looses the value to having HSTI in the SVVP program.

I recommend we provide a real HSTI based on the OVMF threat model (without and 
with configuration computing) and current real implementation.

Thank you
Yao, Jiewen


From: Konstantin Kostiuk 
Sent: Thursday, March 14, 2024 7:43 PM
To: Yao, Jiewen 
Cc: devel@edk2.groups.io; Yan Vugenfirer ; Ard Biesheuvel 
; Gerd Hoffmann 
Subject: Re: [PATCH 1/2] OvmfPkg: Add VirtHstiDxe driver



On Thu, Mar 14, 2024 at 12:28 PM Yao, Jiewen 
mailto:jiewen@intel.com>> wrote:
Question: What is the value to provide an *empty* HSTI table?

IMHO, If the goal is to perform some security check, I think we need provide a 
*real* HSTI table.

HSTI is very vendor-specific and depends on features that a vendor supports. 
Looking at
the HSTI spec a lot of the bits don't make sense for virtual machines. Some 
feature depends on
hardware configuration and this check is a dummy in a virtual environment.

So, the main goal is to pass Microsoft SVVP with OVMF+QEMU.

Best Regards,
Konstantin Kostiuk.


Thank you
Yao, Jiewen

> -Original Message-
> From: Konstantin Kostiuk mailto:kkost...@redhat.com>>
> Sent: Thursday, March 14, 2024 6:25 PM
> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> Cc: Yan Vugenfirer mailto:yvuge...@redhat.com>>; Ard 
> Biesheuvel
> mailto:ardb%2btianoc...@kernel.org>>; Yao, Jiewen 
> mailto:jiewen@intel.com>>; Gerd
> Hoffmann mailto:kra...@redhat.com>>
> Subject: [PATCH 1/2] OvmfPkg: Add VirtHstiDxe driver
>
> The driver provides empty HSTI table.
>
> Signed-off-by: Konstantin Kostiuk 
> mailto:kkost...@redhat.com>>
> ---
>  OvmfPkg/VirtHstiDxe/VirtHstiDxe.c   | 75 +
>  OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf | 64 
>  2 files changed, 139 insertions(+)
>  create mode 100644 OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
>  create mode 100644 OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
>
> diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> new file mode 100644
> index 00..b9ed189f33
> --- /dev/null
> +++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> @@ -0,0 +1,75 @@
> +/** @file
>
> +  This file contains DXE driver for publishing empty HSTI table
>
> +
>
> +Copyright (c) 2017, Intel Corporation. All rights reserved.
>
> +Copyright (c) 2024, Red Hat. Inc
>
> +
>
> +SPDX-License-Identifier: BSD-2-Clause-Patent
>
> +
>
> +**/
>
> +
>
> +#include 
>
> +#include 
>
> +#include 
>
> +#include 
>
> +#include 
>
> +#include 
>
> +#include 
>
> +#include 
>
> +#include 
>
> +
>
> +#define HSTI_PLATFORM_NAME  L"Intel(R) 9-Series v1"
>
> +#define HSTI_SECURITY_FEATURE_SIZE  1
>
> +
>
> +ADAPTER_INFO_PLATFORM_SECURITY  mHstiBase = {
>
> +  PLATFORM_SECURITY_VERSION_VNEXTCS,
>
> +  PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE,
>
> +  { HSTI_PLATFORM_NAME },
>
> +  HSTI_SECURITY_FEATURE_SIZE,
>
> +};
>
> +
>
> +/**
>
> +  The driver's entry point.
>
> +
>
> +  @param[in] ImageHandle  The firmware allocated handle for the EFI image.
>
> +  @param[in] SystemTable  A pointer to the EFI System Table.
>
> +
>
> +  @retval EFI_SUCCESS The entry point is executed successfully.
>
> +  @retval other   Some error occurs when executing this entry point.
>
> +**/
>
> +EFI_STATUS
>
> +EFIAPI
>
> +VirtHstiDxeEntrypoint (
>
> +  IN EFI_HANDLEImageHandle,
>
> +  IN EFI_SYSTEM_TABLE  *SystemTable
>
> +  )
>
> +{
>
> +  EFI_STATUS  Status;
>
> +
>
> +  // Allocate memory for HSTI struct
>
> +  // 3 * sizeof (UINT8) * HSTI_SECURITY_FEATURE_SIZE is for the 3 arrays
>
> +  //   UINT8   Securit

Re: [edk2-devel] [PATCH 1/2] OvmfPkg: Add VirtHstiDxe driver

[Yao, Jiewen]

Question: What is the value to provide an *empty* HSTI table?

IMHO, If the goal is to perform some security check, I think we need provide a 
*real* HSTI table.

Thank you
Yao, Jiewen

> -Original Message-
> From: Konstantin Kostiuk 
> Sent: Thursday, March 14, 2024 6:25 PM
> To: devel@edk2.groups.io
> Cc: Yan Vugenfirer ; Ard Biesheuvel
> ; Yao, Jiewen ; Gerd
> Hoffmann 
> Subject: [PATCH 1/2] OvmfPkg: Add VirtHstiDxe driver
> 
> The driver provides empty HSTI table.
> 
> Signed-off-by: Konstantin Kostiuk 
> ---
>  OvmfPkg/VirtHstiDxe/VirtHstiDxe.c   | 75 +
>  OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf | 64 
>  2 files changed, 139 insertions(+)
>  create mode 100644 OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
>  create mode 100644 OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> 
> diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> new file mode 100644
> index 00..b9ed189f33
> --- /dev/null
> +++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> @@ -0,0 +1,75 @@
> +/** @file
> 
> +  This file contains DXE driver for publishing empty HSTI table
> 
> +
> 
> +Copyright (c) 2017, Intel Corporation. All rights reserved.
> 
> +Copyright (c) 2024, Red Hat. Inc
> 
> +
> 
> +SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> +
> 
> +**/
> 
> +
> 
> +#include 
> 
> +#include 
> 
> +#include 
> 
> +#include 
> 
> +#include 
> 
> +#include 
> 
> +#include 
> 
> +#include 
> 
> +#include 
> 
> +
> 
> +#define HSTI_PLATFORM_NAME  L"Intel(R) 9-Series v1"
> 
> +#define HSTI_SECURITY_FEATURE_SIZE  1
> 
> +
> 
> +ADAPTER_INFO_PLATFORM_SECURITY  mHstiBase = {
> 
> +  PLATFORM_SECURITY_VERSION_VNEXTCS,
> 
> +  PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE,
> 
> +  { HSTI_PLATFORM_NAME },
> 
> +  HSTI_SECURITY_FEATURE_SIZE,
> 
> +};
> 
> +
> 
> +/**
> 
> +  The driver's entry point.
> 
> +
> 
> +  @param[in] ImageHandle  The firmware allocated handle for the EFI image.
> 
> +  @param[in] SystemTable  A pointer to the EFI System Table.
> 
> +
> 
> +  @retval EFI_SUCCESS The entry point is executed successfully.
> 
> +  @retval other   Some error occurs when executing this entry point.
> 
> +**/
> 
> +EFI_STATUS
> 
> +EFIAPI
> 
> +VirtHstiDxeEntrypoint (
> 
> +  IN EFI_HANDLEImageHandle,
> 
> +  IN EFI_SYSTEM_TABLE  *SystemTable
> 
> +  )
> 
> +{
> 
> +  EFI_STATUS  Status;
> 
> +
> 
> +  // Allocate memory for HSTI struct
> 
> +  // 3 * sizeof (UINT8) * HSTI_SECURITY_FEATURE_SIZE is for the 3 arrays
> 
> +  //   UINT8   SecurityFeaturesRequired[];
> 
> +  //   UINT8   SecurityFeaturesImplemented[];
> 
> +  //   UINT8   SecurityFeaturesVerified[];
> 
> +  // sizeof (CHAR16) is for the NULL terminator of ErrorString
> 
> +  //   CHAR16 ErrorString[]
> 
> +  UINTN  HstiSize = sizeof (ADAPTER_INFO_PLATFORM_SECURITY) +
> 
> +3 * sizeof (UINT8) * HSTI_SECURITY_FEATURE_SIZE +
> 
> +sizeof (CHAR16);
> 
> +  VOID  *HstiStruct = AllocateZeroPool (HstiSize);
> 
> +
> 
> +  if (HstiStruct == NULL) {
> 
> +return EFI_OUT_OF_RESOURCES;
> 
> +  }
> 
> +
> 
> +  CopyMem (HstiStruct, , sizeof
> (ADAPTER_INFO_PLATFORM_SECURITY));
> 
> +
> 
> +  Status = HstiLibSetTable (HstiStruct, HstiSize);
> 
> +  if (EFI_ERROR (Status)) {
> 
> +if (Status != EFI_ALREADY_STARTED) {
> 
> +  ASSERT_EFI_ERROR (Status);
> 
> +}
> 
> +  }
> 
> +
> 
> +  return EFI_SUCCESS;
> 
> +}
> 
> diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> new file mode 100644
> index 00..270aa60026
> --- /dev/null
> +++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> @@ -0,0 +1,64 @@
> +## @file
> 
> +#  Component description file for Virt Hsti Driver
> 
> +#
> 
> +# Copyright (c) 2017, Intel Corporation. All rights reserved.
> 
> +# Copyright (c) Microsoft Corporation.
> 
> +# Copyright (c) 2024, Red Hat. Inc
> 
> +#
> 
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> +#
> 
> +##
> 
> +
> 
> +[Defines]
> 
> +  INF_VERSION= 0x00010005
> 
> +  BASE_NAME  = VirtHstiDxe
> 
> +  FILE_GUID  = 60740CF3-D428-4500-80E6-04A5798241ED
> 
> +  MODULE_TYPE= DXE_DRIVER
> 
> +  VERSI

Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/QemuBootOrderLib: Measure the etc/boot-menu-wait

[Yao, Jiewen]

Thanks for the patch.

Is this the only missing configuration data?
Or do you have more on the way?



> -Original Message-
> From: Sun, CepingX 
> Sent: Wednesday, March 13, 2024 7:52 AM
> To: devel@edk2.groups.io
> Cc: Sun, CepingX ; Aktas, Erdem
> ; Yao, Jiewen ; Xu, Min M
> ; Gerd Hoffmann ; Reshetova, Elena
> 
> Subject: [PATCH V1 1/1] OvmfPkg/QemuBootOrderLib: Measure the etc/boot-
> menu-wait
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4415
> 
> Refer to the section 8.3.4 of tdx-virtual-firmware-design-guide spec,
> OVMF would uses FW_CFG_IO_SELECTOR(0x510) and FW_CFG_IO_DATA(0x511)
> to get configuration data from QEMU. From the security perspective,
> if TDVF uses this method, configuration data must be measured into
> RTMR[0].
> 
> Currently, the etc/boot-menu-wait is using in TDVF, it required to be
> measured into RTMR[0].
> 
> This is the first patch and will continue to be updated to measure
> additional configuration data.
> 
> Refernce:
> spec: https://cdrdv2.intel.com/v1/dl/getContent/733585
> 
> Cc: Erdem Aktas 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Gerd Hoffmann 
> Cc: Elena Reshetova 
> Signed-off-by: Ceping Sun 
> ---
>  .../QemuBootOrderLib/QemuBootOrderLib.c   | 21 ++-
>  .../QemuBootOrderLib/QemuBootOrderLib.inf |  1 +
>  2 files changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
> b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
> index 2fe6ab30c032..63a290712002 100644
> --- a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
> +++ b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
> @@ -20,6 +20,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> 
>  #include "ExtraRootBusMap.h"
> 
> @@ -41,6 +43,9 @@
>  #define REQUIRED_MMIO_OFW_NODES  1
>  #define EXAMINED_OFW_NODES   6
> 
> +#define EV_POSTCODE_INFO_QEMU_BOOTMENU_WAIT_TIME_DATA  "QEMU
> BOOTMENU WAIT TIME"
> +#define QEMU_BOOTMENU_WAIT_DATA_LEN
> (sizeof(EV_POSTCODE_INFO_QEMU_BOOTMENU_WAIT_TIME_DATA) - 1)
> +
>  /**
>Simple character classification routines, corresponding to POSIX class 
> names
>and ASCII encoding.
> @@ -2418,5 +2423,19 @@ GetFrontPageTimeoutFromQemu (
>// seconds, round N up.
>//
>QemuFwCfgSelectItem (BootMenuWaitItem);
> -  return (UINT16)((QemuFwCfgRead16 () + 999) / 1000);
> +  Timeout = QemuFwCfgRead16 ();
> +  //
> +  // Measure the Timeout which is downloaded from QEMU.
> +  // It has to be done before it is consumed.
> +  //
> +  TpmMeasureAndLogData (
> +1,
> +EV_PLATFORM_CONFIG_FLAGS,
> +EV_POSTCODE_INFO_QEMU_BOOTMENU_WAIT_TIME_DATA,
> +QEMU_BOOTMENU_WAIT_DATA_LEN,
> +(VOID *)(UINTN),
> +BootMenuWaitSize
> +);
> +
> +  return (UINT16)((Timeout + 999) / 1000);
>  }
> diff --git a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> index 6e320e3e8514..0231c9d5c5b8 100644
> --- a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> +++ b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> @@ -45,6 +45,7 @@
>DevicePathLib
>BaseMemoryLib
>OrderedCollectionLib
> +  TpmMeasurementLib
> 
>  [Guids]
>gEfiGlobalVariableGuid
> --
> 2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116670): https://edk2.groups.io/g/devel/message/116670
Mute This Topic: https://groups.io/mt/104880546/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V1 0/3] OvmfPkg: Update TDVMCALL to avoid leaking secrets to the VMM

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Xu, Min M 
> Sent: Tuesday, February 27, 2024 2:49 PM
> To: Sun, CepingX ; devel@edk2.groups.io
> Cc: Liming Gao ; Kinney, Michael D
> ; Aktas, Erdem ; James
> Bottomley ; Yao, Jiewen ; Tom
> Lendacky ; Michael Roth
> ; Gerd Hoffmann ; Yamahata,
> Isaku 
> Subject: RE: [PATCH V1 0/3] OvmfPkg: Update TDVMCALL to avoid leaking secrets
> to the VMM
> 
> Reviewed-by: Min Xu 
> 
> > -Original Message-
> > From: Sun, CepingX 
> > Sent: Tuesday, February 27, 2024 5:19 AM
> > To: devel@edk2.groups.io
> > Cc: Sun, CepingX ; Liming Gao
> > ; Kinney, Michael D
> > ; Aktas, Erdem ;
> > James Bottomley ; Yao, Jiewen
> > ; Xu, Min M ; Tom Lendacky
> > ; Michael Roth ;
> > Gerd Hoffmann ; Yamahata, Isaku
> > 
> > Subject: [PATCH V1 0/3] OvmfPkg: Update TDVMCALL to avoid leaking secrets
> > to the VMM
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4696
> >
> > According to section 2.4.1 of [GHCI] spec, RBP register is usually used as a
> > frame pointer according to the C language calling convention.
> > The software should not use RBP as an input/output parameter and should
> > clear BIT5 (RBP) in the GPR mask in RCX.
> >
> > Reference:
> > [GHCI]: TDX Guest-Host-Communication Interface v1.5
> > https://cdrdv2.intel.com/v1/dl/getContent/726792
> >
> >
> > Cc: Liming Gao 
> > Cc: Michael D Kinney 
> > Cc: Erdem Aktas 
> > Cc: James Bottomley 
> > Cc: Jiewen Yao 
> > Cc: Min Xu 
> > Cc: Tom Lendacky 
> > Cc: Michael Roth 
> > Cc: Gerd Hoffmann 
> > Cc: Isaku Yamahata 
> > Signed-off-by: Ceping Sun 
> >
> > Ceping Sun (3):
> >   MdePkg/BaseLib: Update TDVMCALL_EXPOSE_REGS_MASK
> >   OvmfPkg/CcExitLib: Update TDVMCALL_EXPOSE_REGS_MASK
> >   OvmfPkg/TdxDxe: Clear the registers before tdcall
> >
> >  MdePkg/Library/BaseLib/X64/TdVmcall.nasm  |  2 +-
> >  .../Library/CcExitLib/X64/TdVmcallCpuid.nasm  |  2 +-
> >  OvmfPkg/TdxDxe/X64/ApRunLoop.nasm | 30 ---
> >  3 files changed, 28 insertions(+), 6 deletions(-)
> >
> > --
> > 2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116668): https://edk2.groups.io/g/devel/message/116668
Mute This Topic: https://groups.io/mt/104577516/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] Maintainers.txt: remove Laszlo's entries

[Yao, Jiewen]

Indeed. Appreciate your great contribution to make EDKII better.

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ard
> Biesheuvel
> Sent: Friday, March 8, 2024 5:38 PM
> To: devel@edk2.groups.io; ler...@redhat.com
> Cc: Kinney, Michael D ; Andrew Fish
> ; Gerd Hoffmann ; Yao, Jiewen
> ; Leif Lindholm ; Kumar,
> Rahul R ; Ni, Ray ; Sami Mujawar
> 
> Subject: Re: [edk2-devel] [PATCH] Maintainers.txt: remove Laszlo's entries
> 
> On Fri, 8 Mar 2024 at 10:14, Laszlo Ersek  wrote:
> >
> > On 3/6/24 23:22, Michael D Kinney wrote:
> > > Reviewed-by: Michael D Kinney 
> >
> > Merged as commit ccf91b518f22, via
> > <https://github.com/tianocore/edk2/pull/5450>.
> >
> > Thank you all for everything,
> 
> Goodbye Laszlo. It was great to have you back, even if only for a short while.
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116503): https://edk2.groups.io/g/devel/message/116503
Mute This Topic: https://groups.io/mt/104775206/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 00/10] clean up ProcessLibraryConstructorList() declarations in SEC modules

[Yao, Jiewen]

For OvmfPkg, reviewed-by: Jiewen Yao 

> -Original Message-
> From: Laszlo Ersek 
> Sent: Tuesday, March 5, 2024 7:39 PM
> To: edk2-devel-groups-io 
> Cc: Warkentin, Andrei ; Andrew Fish
> ; Ard Biesheuvel ; S, Ashraf Ali
> ; Feng, Bob C ; West, Catharine
> ; Chiu, Chasel ; Duggapu,
> Chinni B ; Aktas, Erdem
> ; Gerd Hoffmann ; Guo, Gua
> ; Dong, Guo ; Lu, James
> ; Yao, Jiewen ; Joey Vagedes
> ; Leif Lindholm ; Liming
> Gao ; Kinney, Michael D
> ; Michael Roth ; Xu, Min
> M ; Desimone, Nathaniel L
> ; Kumar, Rahul R ;
> Ni, Ray ; Rebecca Cran ; Sami Mujawar
> ; Sean Brogan ;
> Rhodes, Sean ; Zeng, Star ; Sunil
> V L ; Mohapatra, Susovan
> ; Kuo, Ted ; Tom Lendacky
> ; Chen, Christine 
> Subject: [PATCH v2 00/10] clean up ProcessLibraryConstructorList() 
> declarations
> in SEC modules
> 
> Bugzillas:
> - https://bugzilla.tianocore.org/show_bug.cgi?id=990
> - https://bugzilla.tianocore.org/show_bug.cgi?id=991
> - https://bugzilla.tianocore.org/show_bug.cgi?id=4643
> 
> CI:
> - https://github.com/tianocore/edk2/pull/5442
> 
> Branch:
> - https://github.com/lersek/edk2/tree/ProcessLibraryConstructorList-SEC-990-
> 991-v2
> 
> This patch series puts the recent BaseTools feature to use in which
> AutoGen generates the ProcessLibraryConstructorList() declaration in
> "AutoGen.h" for such non-library SEC modules whose INF_VERSION is at
> least 1.30. The BaseTools feature is present in both edk2 [1] and
> edk2-basetools [2], and has been documented in the Build spec [3] and
> the Inf spec [4]. Kudos to Rebecca for tagging a new edk2-basetools
> release [5] [6] with the new feature.
> 
> [1] edk2 commit bac9c74080cf
> [2] edk2-basetools commit 5b7161de22ee
> [3] edk2-BuildSpecification commit range db69f5661cae..7a7165a7d199
> [4] edk2-InfSpecification commit range a31e3c842bee..1ea6546578fe
> [5] https://github.com/tianocore/edk2-basetools/releases/tag/v0.1.51
> [6] https://pypi.org/project/edk2-basetools/0.1.51/
> 
> The edk2-basetools part is adopted in the first patch (for
> "pip-requirements.txt").
> 
> The rest of the patches clean up -- superfluous, or even incorrect --
> ProcessLibraryConstructorList() declarations (and, in some cases,
> incorrect calls), together with raising the INF_VERSIONs in the related
> SEC module INF files to 1.30.
> 
> Comparing this version to v1 is not useful, as the compatibility
> approach is different, and so this version is structured differently.
> Please review any patches for your subsystem from scratch (they are not
> difficult or large).
> 
> Cc: Andrei Warkentin 
> Cc: Andrew Fish 
> Cc: Ard Biesheuvel 
> Cc: Ashraf Ali S 
> Cc: Bob Feng 
> Cc: Catharine West 
> Cc: Chasel Chiu 
> Cc: Duggapu Chinni B 
> Cc: Erdem Aktas 
> Cc: Gerd Hoffmann 
> Cc: Gua Guo 
> Cc: Guo Dong 
> Cc: James Lu 
> Cc: Jiewen Yao 
> Cc: Joey Vagedes 
> Cc: Leif Lindholm 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Cc: Michael Roth 
> Cc: Min Xu 
> Cc: Nate DeSimone 
> Cc: Rahul Kumar 
> Cc: Ray Ni 
> Cc: Rebecca Cran 
> Cc: Sami Mujawar 
> Cc: Sean Brogan 
> Cc: Sean Rhodes 
> Cc: Star Zeng 
> Cc: Sunil V L 
> Cc: Susovan Mohapatra 
> Cc: Ted Kuo 
> Cc: Tom Lendacky 
> Cc: Yuwei Chen 
> 
> Thanks,
> Laszlo
> 
> Laszlo Ersek (10):
>   pip-requirements.txt: require edk2-basetools version 0.1.51
>   OvmfPkg: auto-generate (and fix) SEC ProcessLibraryConstructorList()
> decl
>   OvmfPkg/IntelTdx: auto-gen & fix SEC ProcessLibraryConstructorList()
> decl
>   OvmfPkg/RiscVVirt/Sec: clean up ProcessLibraryConstructorList() decl
>   ArmPlatformPkg: auto-generate SEC ProcessLibraryConstructorList() decl
>   ArmVirtPkg: auto-generate SEC ProcessLibraryConstructorList() decl
>   EmulatorPkg: auto-generate SEC ProcessLibraryConstructorList() decl
>   IntelFsp2Pkg: auto-generate SEC ProcessLibraryConstructorList() decl
>   UefiCpuPkg: auto-generate SEC ProcessLibraryConstructorList() decl
>   UefiPayloadPkg: auto-generate SEC ProcessLibraryConstructorList() decl
> 
>  ArmPlatformPkg/PrePeiCore/PrePeiCore.h   | 10 --
>  ArmPlatformPkg/PrePeiCore/PrePeiCoreMPCore.inf   |  2 +-
>  ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf  |  2 +-
>  ArmPlatformPkg/PrePi/PeiMPCore.inf   |  2 +-
>  ArmPlatformPkg/PrePi/PeiUniCore.inf  |  2 +-
>  ArmPlatformPkg/PrePi/PrePi.h |  6 --
>  ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf  |  2 +-
>  ArmVirtPkg/PrePi/PrePi.c |  6 --
>  EmulatorPkg/Sec/Sec.h   

Re: [edk2-devel] [RFC PATCH 1/1] ArmPkg,MdePkg: move ArmLib.h to MdePkg

[Yao, Jiewen]

Right, if it is only required by ARM, then it should under ARM section.

Thank you
Yao, Jiewen

> -Original Message-
> From: Leif Lindholm 
> Sent: Friday, March 1, 2024 7:45 PM
> To: Yao, Jiewen ; Pierre Gondois
> ; devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Liming Gao
> ; Kinney, Michael D ;
> Sami Mujawar ; Liu, Zhiguang
> 
> Subject: Re: [RFC PATCH 1/1] ArmPkg,MdePkg: move ArmLib.h to MdePkg
> 
> Thank you.
> 
> OK, that's logically consistent.
> So we'd need an ArmLibNull in MdePkg until ArmLib itself migrates there
> (ideally subsumed into BaseLib).
> 
> But the dependency in .inf should still be able to be declared under
> [LibraryClasses.AArch64, LibraryClasses.ARM]?
> 
> Regards,
> 
> Leif
> 
> On 2024-03-01 01:00, Yao, Jiewen wrote:
> > Sure.
> >
> > When we say "dependency", what we really mean is the dependency in INF file,
> not "dependency" in DSC file.
> >
> >  From package release perspective, only INF is the interface to other 
> > package.
> > The DSC is only the package internal stuff, you can create multiple DSCs or
> add/remove DSC freely.
> >
> > Having "dependency" in DSC does not matter.
> > Having dependency in INF is something we should care about.
> >
> > Thank you
> > Yao, Jiewen
> >
> >
> >> -Original Message-
> >> From: Leif Lindholm 
> >> Sent: Tuesday, February 13, 2024 1:38 AM
> >> To: Pierre Gondois ; devel@edk2.groups.io; Yao,
> >> Jiewen 
> >> Cc: Ard Biesheuvel ; Liming Gao
> >> ; Kinney, Michael D
> ;
> >> Sami Mujawar ; Liu, Zhiguang
> >> 
> >> Subject: Re: [RFC PATCH 1/1] ArmPkg,MdePkg: move ArmLib.h to MdePkg
> >>
> >> Jiewen, can you clarify what you said back in
> >> https://edk2.groups.io/g/devel/message/111551
> >> ?
> >>
> >> On 2024-02-12 17:24, Pierre Gondois wrote:
> >>>>> A ArmLibNull.inf library might also need to be created. If the
> >>>>> OpensslLibFullAccel.inf module will depend on the ArmLib library,
> >>>>> a Null implementation will be necessary for non-Arm architectures.
> >>>>
> >>>> Can ArmLib be declared under a [LibraryClasses.AArch64,
> >>>> LibraryClasses.ARM]? Have I forgotten something that we discussed back
> >>>> in ... November?
> >>>
> >>>   From [1], it seems the MdePkg/CryptoPkg should build without a
> dependency
> >>> on the ArmPkg. This is currently not really the case. cf. [2].
> >>>
> >>> However, having a ArmLibNull implementation in the MdePkg would allow to
> >>> avoid going in this direction when providing libraries to CryptoPkg.dsc.
> >>>
> >>> (Just in case, I think this ArmLibNull is a minor point.)
> >>
> >> Well, sure, it is now.
> >> Until we need a RiscV64LibNull, LoongarchLibNull, ...
> >>
> >>> [1] https://edk2.groups.io/g/devel/message/111545
> >>> [2]
> >>>
> >>
> https://github.com/tianocore/edk2/blob/8801c75b4d77c2e6e06b3ddc8560e0db
> >> 590f6342/CryptoPkg/CryptoPkg.dsc#L117
> >>>
> >>>>
> >>>>> Otherwise I could apply and run the CryptoPkg/Arm native instructions
> >>>>> patchset on top of this patch.
> >>>>>
> >>>>> ---
> >>>>>
> >>>>> As a side note, it also seems that:
> >>>>> - ArmPkg/Include/Chipset/ArmCortexA5x.h
> >>>>>      isn't used anymore in edk2/edk2-platorms
> >>>>> - ArmPkg/Include/Chipset/ArmCortexA9.h
> >>>>>      is barely used in edk2-platforms.
> >>>>> Maybe the files should have been removed/simplified as part of
> >>>>> - cffa7925a293 ("ArmPkg: remove ArmCpuLib header and
> implementations")
> >>>>> - a913ad02479d ("ArmPlatformPkg: remove ArmVExpressPkg")
> >>>>
> >>>> I think you're right.
> >>>> Well, ArmCortexA9.h is still *used*, but I can't imagine the Arm branch
> >>>> of ArmVExpressLib has been build by anyone for some time. And surely the
> >>>> inclusion of ArmVExpressLibSec in ArmVExpress-FVP-AArch64.dsc is
> >>>> superfluous (such that that .inf can be deleted)?
> >>>
> >>> The file could just be moved in the Library. I assume you/Sami/Ard
> >>> will know more on the usage of the library itself,
> >>
> >> Sami?
> >>
> >> /
> >>   Leif
> >>
> >



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116261): https://edk2.groups.io/g/devel/message/116261
Mute This Topic: https://groups.io/mt/102731845/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [RFC PATCH 1/1] ArmPkg,MdePkg: move ArmLib.h to MdePkg

[Yao, Jiewen]

Sure.

When we say "dependency", what we really mean is the dependency in INF file, 
not "dependency" in DSC file.

>From package release perspective, only INF is the interface to other package. 
The DSC is only the package internal stuff, you can create multiple DSCs or 
add/remove DSC freely.

Having "dependency" in DSC does not matter.
Having dependency in INF is something we should care about.

Thank you
Yao, Jiewen


> -Original Message-
> From: Leif Lindholm 
> Sent: Tuesday, February 13, 2024 1:38 AM
> To: Pierre Gondois ; devel@edk2.groups.io; Yao,
> Jiewen 
> Cc: Ard Biesheuvel ; Liming Gao
> ; Kinney, Michael D ;
> Sami Mujawar ; Liu, Zhiguang
> 
> Subject: Re: [RFC PATCH 1/1] ArmPkg,MdePkg: move ArmLib.h to MdePkg
> 
> Jiewen, can you clarify what you said back in
> https://edk2.groups.io/g/devel/message/111551
> ?
> 
> On 2024-02-12 17:24, Pierre Gondois wrote:
> >>> A ArmLibNull.inf library might also need to be created. If the
> >>> OpensslLibFullAccel.inf module will depend on the ArmLib library,
> >>> a Null implementation will be necessary for non-Arm architectures.
> >>
> >> Can ArmLib be declared under a [LibraryClasses.AArch64,
> >> LibraryClasses.ARM]? Have I forgotten something that we discussed back
> >> in ... November?
> >
> >  From [1], it seems the MdePkg/CryptoPkg should build without a dependency
> > on the ArmPkg. This is currently not really the case. cf. [2].
> >
> > However, having a ArmLibNull implementation in the MdePkg would allow to
> > avoid going in this direction when providing libraries to CryptoPkg.dsc.
> >
> > (Just in case, I think this ArmLibNull is a minor point.)
> 
> Well, sure, it is now.
> Until we need a RiscV64LibNull, LoongarchLibNull, ...
> 
> > [1] https://edk2.groups.io/g/devel/message/111545
> > [2]
> >
> https://github.com/tianocore/edk2/blob/8801c75b4d77c2e6e06b3ddc8560e0db
> 590f6342/CryptoPkg/CryptoPkg.dsc#L117
> >
> >>
> >>> Otherwise I could apply and run the CryptoPkg/Arm native instructions
> >>> patchset on top of this patch.
> >>>
> >>> ---
> >>>
> >>> As a side note, it also seems that:
> >>> - ArmPkg/Include/Chipset/ArmCortexA5x.h
> >>>     isn't used anymore in edk2/edk2-platorms
> >>> - ArmPkg/Include/Chipset/ArmCortexA9.h
> >>>     is barely used in edk2-platforms.
> >>> Maybe the files should have been removed/simplified as part of
> >>> - cffa7925a293 ("ArmPkg: remove ArmCpuLib header and implementations")
> >>> - a913ad02479d ("ArmPlatformPkg: remove ArmVExpressPkg")
> >>
> >> I think you're right.
> >> Well, ArmCortexA9.h is still *used*, but I can't imagine the Arm branch
> >> of ArmVExpressLib has been build by anyone for some time. And surely the
> >> inclusion of ArmVExpressLibSec in ArmVExpress-FVP-AArch64.dsc is
> >> superfluous (such that that .inf can be deleted)?
> >
> > The file could just be moved in the Library. I assume you/Sami/Ard
> > will know more on the usage of the library itself,
> 
> Sami?
> 
> /
>  Leif
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116193): https://edk2.groups.io/g/devel/message/116193
Mute This Topic: https://groups.io/mt/102731845/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 00/23] Provide SEV-SNP support for running under an SVSM

[Yao, Jiewen]

Below:

> -Original Message-
> From: Tom Lendacky 
> Sent: Thursday, February 29, 2024 12:20 AM
> To: Yao, Jiewen ; devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Aktas, Erdem
> ; Gerd Hoffmann ; Laszlo Ersek
> ; Liming Gao ; Kinney, Michael
> D ; Xu, Min M ; Liu,
> Zhiguang ; Kumar, Rahul R ;
> Ni, Ray ; Michael Roth 
> Subject: Re: [PATCH v2 00/23] Provide SEV-SNP support for running under an
> SVSM
> 
> On 2/28/24 00:14, Yao, Jiewen wrote:
> > Some feedback:
> >
> > 1) 0002-MdePkg-GHCB-APIC-ID-retrieval-support-definitions
> >
> > MdePkg only contains the definition in the standard.
> >
> > Question: Is EFI_APIC_IDS_GUID definition in some AMD/SVSM specification?
> 
> The structure is documented in the GHCB specification, but the GUID is not.
> 
> Is the request to move the GUID to someplace other than MdePkg?

[Jiewen] Right. If the GUID is NOT in GHCB spec, then it should be in other 
place, such as OvmfPkg.


> 
> >
> > 2) 0012-UefiCpuPkg-CcSvsmLib-Create-the-CcSvsmLib-library-to-support-an-
> SVSM
> >
> > I am not sure the position of SVSM.
> > If the SVSM interface is AMD specific, the it should be AmdSvsmLib.
> 
> I believe TDX is also looking at the SVSM for TDX partitioning, but I'm
> not certain of that.
> 
> > If the SVSM interface is generic, then we should define everything in a 
> > generic
> way.
> >
> > It is very confusing to mix a generic CcSvsm lib with AMD specific
> .
> 
> I can certainly change the name to be AMD specific fow now. It can always
> be changed to something else later if need be, much like VmgExitLib was
> changed to CcExitLib.

[Jiewen] Yes, Intel is planning for SVSM. But it is NOT ready yet.
It is hard for me to discuss it now.

Maybe, please help me understand:
Is CcSvsmLib a generic library / common protocol between OVMF and Coconut-SVSM? 
- Option 1
Or is CcSvsmLib an implementation specific library, and the current API cannot 
be shared with Intel TDX in future? - Option 2

I notice that some API is for option 1 - CcSvsmIsSvsmPresent().
But some API is for option 2 - CcSvsmSnpGetVmpl(), CcSvsmSnpGetCaa(), 
CcSvsmSnpPvalidate(), CcSvsmSnpVmsaRmpAdjust().

How do you plan if TDX need to support SVSM later?
How do you plan if we need to add some generic interaction between OVMF and 
coconut-SVSM, such as vTPM?



> 
> Thanks,
> Tom
> 
> >
> >
> > Thank you
> > Yao, Jiewen
> >
> >> -Original Message-
> >> From: Tom Lendacky 
> >> Sent: Friday, February 23, 2024 1:30 AM
> >> To: devel@edk2.groups.io
> >> Cc: Ard Biesheuvel ; Aktas, Erdem
> >> ; Gerd Hoffmann ; Yao,
> Jiewen
> >> ; Laszlo Ersek ; Liming Gao
> >> ; Kinney, Michael D
> ;
> >> Xu, Min M ; Liu, Zhiguang ;
> >> Kumar, Rahul R ; Ni, Ray ;
> Michael
> >> Roth 
> >> Subject: [PATCH v2 00/23] Provide SEV-SNP support for running under an SVSM
> >>
> >>
> >> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
> >>
> >> This series adds SEV-SNP support for running OVMF under an Secure VM
> >> Service Module (SVSM) at a less privileged VM Privilege Level (VMPL).
> >> By running at a less priviledged VMPL, the SVSM can be used to provide
> >> services, e.g. a virtual TPM, for the guest OS within the SEV-SNP
> >> confidential VM (CVM) rather than trust such services from the hypervisor.
> >>
> >> Currently, OVMF expects to run at the highest VMPL, VMPL0, and there are
> >> certain SNP related operations that require that VMPL level. Specifically,
> >> the PVALIDATE instruction and the RMPADJUST instruction when setting the
> >> the VMSA attribute of a page (used when starting APs).
> >>
> >> If OVMF is to run at a less privileged VMPL, e.g. VMPL2, then it must
> >> use an SVSM (which is running at VMPL0) to perform the operations that
> >> it is no longer able to perform.
> >>
> >> When running under an SVSM, OVMF must know the APIC IDs of the vCPUs
> that
> >> it will be starting. As a result, the GHCB APIC ID retrieval action must
> >> be performed. Since this service can also work with SEV-SNP running at
> >> VMPL0, the patches to make use of this feature are near the beginning of
> >> the series.
> >>
> >> How OVMF interacts with and uses the SVSM is documented in the SVSM
> >> specification [1] and the GHCB specification [2].
> >>
> >> This support creates a new CcSvsmLib library that is used by MpInitLib.
> >> This requires an update to the edk2-platform DSC files to add the new

Re: [edk2-devel] [PATCH v2 00/23] Provide SEV-SNP support for running under an SVSM

[Yao, Jiewen]

Some feedback:

1) 0002-MdePkg-GHCB-APIC-ID-retrieval-support-definitions

MdePkg only contains the definition in the standard.

Question: Is EFI_APIC_IDS_GUID definition in some AMD/SVSM specification?

2) 0012-UefiCpuPkg-CcSvsmLib-Create-the-CcSvsmLib-library-to-support-an-SVSM

I am not sure the position of SVSM.
If the SVSM interface is AMD specific, the it should be AmdSvsmLib.
If the SVSM interface is generic, then we should define everything in a generic 
way.

It is very confusing to mix a generic CcSvsm lib with AMD specific 
.


Thank you
Yao, Jiewen

> -Original Message-
> From: Tom Lendacky 
> Sent: Friday, February 23, 2024 1:30 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Aktas, Erdem
> ; Gerd Hoffmann ; Yao, Jiewen
> ; Laszlo Ersek ; Liming Gao
> ; Kinney, Michael D ;
> Xu, Min M ; Liu, Zhiguang ;
> Kumar, Rahul R ; Ni, Ray ; Michael
> Roth 
> Subject: [PATCH v2 00/23] Provide SEV-SNP support for running under an SVSM
> 
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
> 
> This series adds SEV-SNP support for running OVMF under an Secure VM
> Service Module (SVSM) at a less privileged VM Privilege Level (VMPL).
> By running at a less priviledged VMPL, the SVSM can be used to provide
> services, e.g. a virtual TPM, for the guest OS within the SEV-SNP
> confidential VM (CVM) rather than trust such services from the hypervisor.
> 
> Currently, OVMF expects to run at the highest VMPL, VMPL0, and there are
> certain SNP related operations that require that VMPL level. Specifically,
> the PVALIDATE instruction and the RMPADJUST instruction when setting the
> the VMSA attribute of a page (used when starting APs).
> 
> If OVMF is to run at a less privileged VMPL, e.g. VMPL2, then it must
> use an SVSM (which is running at VMPL0) to perform the operations that
> it is no longer able to perform.
> 
> When running under an SVSM, OVMF must know the APIC IDs of the vCPUs that
> it will be starting. As a result, the GHCB APIC ID retrieval action must
> be performed. Since this service can also work with SEV-SNP running at
> VMPL0, the patches to make use of this feature are near the beginning of
> the series.
> 
> How OVMF interacts with and uses the SVSM is documented in the SVSM
> specification [1] and the GHCB specification [2].
> 
> This support creates a new CcSvsmLib library that is used by MpInitLib.
> This requires an update to the edk2-platform DSC files to add the new
> library. The edk2-platform change would be needed after patch 12, but
> before patch 15.
> 
> This series introduces support to run OVMF under an SVSM. It consists
> of:
>   - Retrieving the list of vCPU APIC IDs and starting up all APs without
> performing a broadcast SIPI
>   - Reorganizing the page state change support to not directly use the
> GHCB buffer since an SVSM will use the calling area buffer, instead
>   - Detecting the presence of an SVSM
>   - When not running at VMPL0, invoking the SVSM for page validation and
> VMSA page creation/deletion
>   - Detecting and allowing OVMF to run in a VMPL other than 0 when an
> SVSM is present
> 
> The series is based off of commit:
> 
>   2ca8d5597443 ("UefiCpuPkg/PiSmmCpuDxeSmm: Check BspIndex first before
> lock cmpxchg")
> 
> [1] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-
> docs/specifications/58019.pdf
> [2] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-
> docs/specifications/56421.pdf
> 
> ---
> 
> Changes in v2:
> - Move the APIC IDs retrieval support to the beginning of the patch series
> - Use a GUIDed HOB to hold the APIC ID list instead of a PCD
> - Split up Page State Change reorganization into multiple patches
> - Created CcSvsmLib library instead of extending CcExitLib
> - This will require a corresponding update to edk2-platform DSC files
> - Removed Ray Ni's Acked-by since it is not a minor change
> - Variable name changes and other misc changes
> 
> Tom Lendacky (23):
>   OvmfPkg/BaseMemEncryptLib: Fix error check from AsmRmpAdjust()
>   MdePkg: GHCB APIC ID retrieval support definitions
>   OvmfPkg/PlatformPei: Retrieve APIC IDs from the hypervisor
>   UefiCpuPkg/MpInitLib: Always use AP Create if PcdSevSnpApicIds is set
>   OvmfPkg/BaseMemEncryptSevLib: Fix uncrustify errors
>   OvmfPkg/BaseMemEncryptSevLib: Calculate memory size for Page State
> Change
>   MdePkg: Avoid hardcoded value for number of Page State Change entries
>   OvmfPkg/BaseMemEncryptSevLib: Re-organize page state change support
>   OvmfPkg/BaseMemEncryptSevLib: Maximize Page State Change efficiency
>   MdePkg/Register/Amd: Define the SVSM related information
>   MdePkg/BaseLib: Add a new VMGE

Re: [edk2-devel] [PATCH v4 3/3] SecurityPkg: Update ReceiveData and SendData function description

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Shang, Qingyu 
> Sent: Monday, February 26, 2024 11:06 AM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen 
> Subject: [PATCH v4 3/3] SecurityPkg: Update ReceiveData and SendData function
> description
> 
> Refer to Uefi spec 2.10 section 13.14, update the parameter 'MediaId'
> description for EFI_STORAGE_SECURITY_COMMAND_PROTOCOL function
> ReceiveData
> and SendData.
> 
> Cc: Jiewen Yao 
> Signed-off-by: Qingyu 
> ---
>  SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordPei.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordPei.c
> b/SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordPei.c
> index 0fb6b1bf41d5..1ee55105e435 100644
> --- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordPei.c
> +++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordPei.c
> @@ -49,7 +49,9 @@ EFI_GUID  mOpalDeviceLockBoxGuid =
> OPAL_DEVICE_LOCKBOX_GUID;
>function shall return EFI_DEVICE_ERROR.
> 
>@param  This Indicates a pointer to the calling 
> context.
> -  @param  MediaId  ID of the medium to receive data from.
> +  @param  MediaId  ID of the medium to receive data 
> from. If there is
> no
> +   block IO protocol supported by the 
> physical device, the
> +   value of MediaId is undefined.
>@param  Timeout  The timeout, in 100ns units, to use 
> for the
> execution
> of the security protocol command. A 
> Timeout value of 0
> means that this function will wait 
> indefinitely for the
> @@ -148,7 +150,9 @@ SecurityReceiveData (
>shall return EFI_DEVICE_ERROR.
> 
>@param  This Indicates a pointer to the calling 
> context.
> -  @param  MediaId  ID of the medium to receive data from.
> +  @param  MediaId  ID of the medium to receive data 
> from. If there is
> no
> +   block IO protocol supported by the 
> physical device, the
> +   value of MediaId is undefined.
>@param  Timeout  The timeout, in 100ns units, to use 
> for the
> execution
> of the security protocol command. A 
> Timeout value of 0
> means that this function will wait 
> indefinitely for the
> --
> 2.39.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116091): https://edk2.groups.io/g/devel/message/116091
Mute This Topic: https://groups.io/mt/104581211/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2] SecurityPkg/SecureBootConfigDxe: Update UI according to UEFI spec

[Yao, Jiewen]

Thanks for the update.

First, would you please clarify which test you have done for this patch set.
Have you tested all previous function to ensure it still works?

Second, would you please clarify if there is any compatibility issue to follow 
the new UEFI 2.10?
For example, what if the core HII is still UEFI 2.9? would that still work?

Third, because I am not HII expert, I would like to have HII expert to comment 
the HII/Browser related change.

Thank you
Yao, Jiewen

> -Original Message-
> From: Tan, Ming 
> Sent: Tuesday, February 27, 2024 10:59 AM
> To: devel@edk2.groups.io
> Cc: Xu, Min M ; Yao, Jiewen 
> Subject: [PATCH v2] SecurityPkg/SecureBootConfigDxe: Update UI according to
> UEFI spec
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4713
> 
> In UEFI_Spec_2_10_Aug29.pdf page 1694 section 35.5.4 for
> EFI_BROWSER_ACTION_FORM_OPEN:
> NOTE: EFI_FORM_BROWSER2_PROTOCOL.BrowserCallback() cannot be used
> with
> this browser action because question values have not been retrieved yet.
> 
> So should not call HiiGetBrowserData() and HiiSetBrowserData() in FORM_OPEN
> call back function.
> 
> Now call SecureBootExtractConfigFromVariable() to save the change to EFI
> variable, then HII use EFI variable to control the UI.
> 
> Cc: Min Xu 
> Cc: Jiewen Yao 
> Signed-off-by: Ming Tan 
> ---
>   V2: Change code style to pass uncrustify check.
> 
>  .../SecureBootConfigImpl.c| 37 ++-
>  1 file changed, 20 insertions(+), 17 deletions(-)
> 
> diff --git
> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigIm
> pl.c
> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigIm
> pl.c
> index 2c11129526..e2e61d1e07 100644
> ---
> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigIm
> pl.c
> +++
> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigIm
> pl.c
> @@ -3366,6 +3366,8 @@ SecureBootExtractConfigFromVariable (
>  ConfigData->FileEnrollType = UNKNOWN_FILE_TYPE;
> 
>}
> 
> 
> 
> +  ConfigData->ListCount = Private->ListCount;
> 
> +
> 
>//
> 
>// If it is Physical Presence User, set the PhysicalPresent to true.
> 
>//
> 
> @@ -4541,12 +4543,13 @@ SecureBootCallback (
>EFI_HII_POPUP_PROTOCOL  *HiiPopup;
> 
>EFI_HII_POPUP_SELECTION UserSelection;
> 
> 
> 
> -  Status = EFI_SUCCESS;
> 
> -  SecureBootEnable   = NULL;
> 
> -  SecureBootMode = NULL;
> 
> -  SetupMode  = NULL;
> 
> -  File   = NULL;
> 
> -  EnrollKeyErrorCode = None_Error;
> 
> +  Status   = EFI_SUCCESS;
> 
> +  SecureBootEnable = NULL;
> 
> +  SecureBootMode   = NULL;
> 
> +  SetupMode= NULL;
> 
> +  File = NULL;
> 
> +  EnrollKeyErrorCode   = None_Error;
> 
> +  GetBrowserDataResult = FALSE;
> 
> 
> 
>if ((This == NULL) || (Value == NULL) || (ActionRequest == NULL)) {
> 
>  return EFI_INVALID_PARAMETER;
> 
> @@ -4565,15 +4568,12 @@ SecureBootCallback (
>  return EFI_OUT_OF_RESOURCES;
> 
>}
> 
> 
> 
> -  GetBrowserDataResult = HiiGetBrowserData
> (, mSecureBootStorageName, BufferSize,
> (UINT8 *)IfrNvData);
> 
> -
> 
>if (Action == EFI_BROWSER_ACTION_FORM_OPEN) {
> 
>  if (QuestionId == KEY_SECURE_BOOT_MODE) {
> 
>//
> 
>// Update secure boot strings when opening this form
> 
>//
> 
> -  Status = UpdateSecureBootString (Private);
> 
> -  SecureBootExtractConfigFromVariable (Private, IfrNvData);
> 
> +  Status = UpdateSecureBootString (Private);
> 
>mIsEnterSecureBootForm = TRUE;
> 
>  } else {
> 
>//
> 
> @@ -4587,23 +4587,22 @@ SecureBootCallback (
>(QuestionId == KEY_SECURE_BOOT_DBT_OPTION))
> 
>{
> 
>  CloseEnrolledFile (Private->FileContext);
> 
> -  } else if (QuestionId == KEY_SECURE_BOOT_DELETE_ALL_LIST) {
> 
> -//
> 
> -// Update ListCount field in varstore
> 
> -// Button "Delete All Signature List" is
> 
> -// enable when ListCount is greater than 0.
> 
> -//
> 
> -IfrNvData->ListCount = Private->ListCount;
> 
>}
> 
>  }
> 
> 
> 
>  goto EXIT;
> 
>}
> 
> 
> 
> +  GetBrowserDataResult = HiiGetBrowserData
> (, mSecureBootStorageName, BufferSize,
> (UINT8 *)IfrNvData);
> 
> +
> 
>if (Action == EFI_BROWSER_ACTION_RETRIEVE) {

Re: [edk2-devel] The API in BaseCryptLib can't seed the pseudorandom number generator properly

[Yao, Jiewen]

Thanks Laslo and Eddie.

I am just back from Chinese New Year vocation, still checking email.

If you can file a Bugzilla (https://bugzilla.tianocore.org/) with source code 
of your app, that would be very helpful for us to investigate this issue.


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
> Sent: Tuesday, February 20, 2024 4:18 AM
> To: eddie wang 
> Cc: devel@edk2.groups.io
> Subject: Re: [edk2-devel] The API in BaseCryptLib can't seed the pseudorandom
> number generator properly
> 
> On 2/17/24 10:17, eddie wang wrote:
> > Hi Laszlo,
> > After digging dipper,  we found that the *EVP_RAND_fetch *in
> > "rand_new_seed" and "rand_new_drbg" both got NULL in our case. It's
> > meant the DRBG implementation could
> > not be fetched. We also compared it to the case on Linux, and they could
> > both fetched DRBG implementation correctly. Is it possible that the
> > opensslLib 3.0.9 caused any compatibility issues with edk2?  Or has
> > anyone else encountered the same problem with these openssl services?
> 
> Sorry, I can't say.
> 
> If you have a small reproducer UEFI application that works fine when
> built with edk2-stable202305, but does not work when built against
> either edk2-stable202308 or current master, then filing a TianoCore BZ
> (regression) seems justified. (AFAICT it was edk2-stable202308 that
> incorporated the OpenSSL 3.0.9 upgrade, from 1.1.1u.) Attaching the
> source code of the small repro application to the ticket would likely be
> helpful.
> 
> Laszlo
> 
> > Laszlo Ersek mailto:ler...@redhat.com>> 於 2024年2月
> > 15日 週四 下午7:48寫道：
> >
> > On 2/15/24 12:09, eddie wang wrote:
> > > Hi Laszlo,
> > > Thanks for your reply. How can I enable the DEBUGs at RandomSeed()
> > ? Or
> > > any suggesting information that I can provide?
> >
> > Sorry, upon a closer look, I see you had already narrowed it down to
> > RAND_seed() and RAND_status(), which are direct OpenSSL APIs. So my
> > suggestion would amount to adding DEBUGs to OpenSSL, such as to
> > RAND_seed() in
> > "CryptoPkg/Library/OpensslLib/openssl/crypto/rand/rand_lib.c".
> >
> > But, I think you may be able to do just that.
> > "CryptoPkg/Library/Include/CrtLibSupport.h" already includes
> > , and DebugLib is listed under [LibraryClasses] in each
> > instance of OpensslLib. So if you modify your
> > "CryptoPkg/Library/OpensslLib/openssl" submodule directory tree locally,
> > with the following patch:
> >
> > | diff --git a/crypto/rand/rand_lib.c b/crypto/rand/rand_lib.c
> > | index 0fcf4fe3bc1e..e5f105268f52 100644
> > | --- a/crypto/rand/rand_lib.c
> > | +++ b/crypto/rand/rand_lib.c
> > | @@ -257,6 +257,8 @@ void RAND_seed(const void *buf, int num)
> > |      drbg = RAND_get0_primary(NULL);
> > |      if (drbg != NULL && num > 0)
> > |          EVP_RAND_reseed(drbg, 0, NULL, 0, buf, num);
> > | +
> > | +    DEBUG ((DEBUG_INFO, "%a: hello\n", __func__));
> > |  }
> > |
> > |  void RAND_add(const void *buf, int num, double randomness)
> >
> > then you should get usable debug messages -- at least it builds for me.
> >
> > Inserting DEBUGs like this (over multiple rounds of testing / narrowing)
> > should lead you to the exact location that is responsible for the
> > initialization failure.
> >
> > You mention you have encountered the problem with a UEFI application.
> > That is relevant for choosing your DebugLib instance. If you already
> > have a function DebugLib instance for your platform (logging to the
> > serial port, for example), then just use that.
> >
> > Otherwise, consider building your UEFI application with a module scope
> > override in the DSC file, one that resolves DebugLib to
> >
> >   MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
> >
> > or
> >
> >   MdePkg/Library/UefiDebugLibStdErr/UefiDebugLibStdErr.inf
> >
> > These will send DEBUG messages to the UEFI console or standard error
> > devices, respectively.
> >
> > hth
> > Laszlo
> >
> > > Laszlo Ersek mailto:ler...@redhat.com>
> > >> 於 2024年2月
> > > 8日 週四 上午5:03寫道：
> > >
> > >     On 2/6/24 08:00, eddie wang wrote:
> > >     > Hi all,
> > >     > We had an UEFI application that used the EDK2(2023/12/05),
> > and  we
> > >     would
> > >     > like to take advantage of the services in BaseCryptLib .However,
> > >     the API
> > >     > in CryptPkg "*RandomSeed()*"(X64, in CryptRandTsc.c) always
> > returned
> > >     > false because of  the pseudorandom number generator set up
> > failed.
> > >     I am
> > >     > not sure this issue is from the *openssl configuration in
> > >     OpensslLib(we
> > >     > use the default configuration)* or is from the *openssl 3.0.9*.
> > >     >
> > >     > Is there 

Re: [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM

[Yao, Jiewen]

Thanks Tom. Below is exactly what I am looking for:
"the decision to use the SVSM API will be based on the VMPL level at which OVMF 
is running."

OVMF needs to detect SEV-SNP, then make next level decision on VMPL.
Makes sense to me.

Thank you
Yao, Jiewen

> -Original Message-
> From: Tom Lendacky 
> Sent: Sunday, January 28, 2024 1:49 AM
> To: Yao, Jiewen ; devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Aktas, Erdem
> ; Gerd Hoffmann ; Laszlo Ersek
> ; Liming Gao ; Kinney, Michael
> D ; Xu, Min M ; Liu,
> Zhiguang ; Kumar, Rahul R ;
> Ni, Ray ; Michael Roth 
> Subject: Re: [PATCH 00/16] Provide SEV-SNP support for running under an SVSM
> 
> On 1/26/24 22:04, Yao, Jiewen wrote:
> > Thanks Tom.
> > Please give me some time to digest this patch set before I can give some
> feedback.
> >
> > One quick question to you:
> > With this patch, we need to support multiple SEV modes:
> > 1. SEV guest firmware
> > 2. SEV-ES guest firmware
> > 3. SEV-SNP guest firmware
> > 4. SEV-SNP SVSM guest firmware
> 
> This last mode is still an SNP guest, it just requires invoking an API to
> perform operations that require VMPL0 permissions. I'm not sure what you
> mean by having firmware at the end of each mode. The same firmware is used
> for all SEV guest modes as well as non-SEV guests.
> 
> > And all these mode requires runtime detection. Am I right?
> 
> Yes
> 
> > If so, where is the flag to set those mode?
> 
> There are function calls available to detect the SEV mode. See the
> implementation of MemEncryptSevIsEnabled(), MemEncryptSevEsIsEnabled() and
> MemEncryptSevSnpIsEnabled().
> 
> OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
> OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
> OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c
> 
> (OvmfPkg/Sec/AmdSev.c also has some early detection support)
> 
> Note:
>- An SEV-SNP guest is also considered an SEV-ES and SEV guest.
>- An SEV-ES guest is also considered an SEV guest.
> 
> Within the CcExitLib library, the decision to use the SVSM API will be
> based on the VMPL level at which OVMF is running.
> 
> Thanks,
> Tom
> 
> >
> > Please correct me if my understanding is wrong.
> >
> > Thank you
> > Yao, Jiewen
> >
> >> -Original Message-
> >> From: Tom Lendacky 
> >> Sent: Saturday, January 27, 2024 6:13 AM
> >> To: devel@edk2.groups.io
> >> Cc: Ard Biesheuvel ; Aktas, Erdem
> >> ; Gerd Hoffmann ; Yao,
> Jiewen
> >> ; Laszlo Ersek ; Liming Gao
> >> ; Kinney, Michael D
> ;
> >> Xu, Min M ; Liu, Zhiguang ;
> >> Kumar, Rahul R ; Ni, Ray ;
> Michael
> >> Roth 
> >> Subject: [PATCH 00/16] Provide SEV-SNP support for running under an SVSM
> >>
> >>
> >> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
> >>
> >> This series adds SEV-SNP support for running OVMF under an Secure VM
> >> Service Module (SVSM) at a less privileged VM Privilege Level (VMPL).
> >> By running at a less priviledged VMPL, the SVSM can be used to provide
> >> services, e.g. a virtual TPM, for the guest OS within the SEV-SNP
> >> confidential VM (CVM) rather than trust such services from the hypervisor.
> >>
> >> Currently, OVMF expects to run at the highest VMPL, VMPL0, and there are
> >> certain SNP related operations that require that VMPL level. Specifically,
> >> the PVALIDATE instruction and the RMPADJUST instruction when setting the
> >> the VMSA attribute of a page (used when starting APs).
> >>
> >> If OVMF is to run at a less privileged VMPL, e.g. VMPL2, then it must
> >> use an SVSM (which is running at VMPL0) to perform the operations that
> >> it is no longer able to perform.
> >>
> >> How OVMF interacts with and uses the SVSM is documented in the SVSM
> >> specification [1] and the GHCB specification [2].
> >>
> >> This series introduces support to run OVMF under an SVSM. It consists
> >> of:
> >>- Reorganize the page state change support to not directly use the
> >>  GHCB buffer since an SVSM will use the calling area buffer, instead
> >>- Detecting the presence of an SVSM
> >>- When not running at VMPL0, invoking the SVSM for page validation and
> >>  VMSA page creation/deletion
> >>- Retrieving the list of vCPU APIC IDs and starting up all APs without
> >>  performing a broadcast SIPI
> >>- Detecting and allowing OVMF to run in a VMPL 

Re: [edk2-devel] [PATCH 00/16] Provide SEV-SNP support for running under an SVSM

[Yao, Jiewen]

Thanks Tom.
Please give me some time to digest this patch set before I can give some 
feedback.

One quick question to you:
With this patch, we need to support multiple SEV modes:
1. SEV guest firmware
2. SEV-ES guest firmware
3. SEV-SNP guest firmware
4. SEV-SNP SVSM guest firmware
And all these mode requires runtime detection. Am I right?
If so, where is the flag to set those mode?

Please correct me if my understanding is wrong.

Thank you
Yao, Jiewen

> -Original Message-
> From: Tom Lendacky 
> Sent: Saturday, January 27, 2024 6:13 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Aktas, Erdem
> ; Gerd Hoffmann ; Yao, Jiewen
> ; Laszlo Ersek ; Liming Gao
> ; Kinney, Michael D ;
> Xu, Min M ; Liu, Zhiguang ;
> Kumar, Rahul R ; Ni, Ray ; Michael
> Roth 
> Subject: [PATCH 00/16] Provide SEV-SNP support for running under an SVSM
> 
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
> 
> This series adds SEV-SNP support for running OVMF under an Secure VM
> Service Module (SVSM) at a less privileged VM Privilege Level (VMPL).
> By running at a less priviledged VMPL, the SVSM can be used to provide
> services, e.g. a virtual TPM, for the guest OS within the SEV-SNP
> confidential VM (CVM) rather than trust such services from the hypervisor.
> 
> Currently, OVMF expects to run at the highest VMPL, VMPL0, and there are
> certain SNP related operations that require that VMPL level. Specifically,
> the PVALIDATE instruction and the RMPADJUST instruction when setting the
> the VMSA attribute of a page (used when starting APs).
> 
> If OVMF is to run at a less privileged VMPL, e.g. VMPL2, then it must
> use an SVSM (which is running at VMPL0) to perform the operations that
> it is no longer able to perform.
> 
> How OVMF interacts with and uses the SVSM is documented in the SVSM
> specification [1] and the GHCB specification [2].
> 
> This series introduces support to run OVMF under an SVSM. It consists
> of:
>   - Reorganize the page state change support to not directly use the
> GHCB buffer since an SVSM will use the calling area buffer, instead
>   - Detecting the presence of an SVSM
>   - When not running at VMPL0, invoking the SVSM for page validation and
> VMSA page creation/deletion
>   - Retrieving the list of vCPU APIC IDs and starting up all APs without
> performing a broadcast SIPI
>   - Detecting and allowing OVMF to run in a VMPL other than 0 when an
> SVSM is present
> 
> The series is based off of commit:
> 
>   7d7decfa3dc8 ("UefiPayloadPkg/Crypto: Support external Crypto drivers.")
> 
> [1] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-
> docs/specifications/58019.pdf
> [2] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-
> docs/specifications/56421.pdf
> 
> ---
> 
> Tom Lendacky (16):
>   OvmfPkg/BaseMemEncryptSevLib: Re-organize page state change support
>   MdePkg/Register/Amd: Define the SVSM related information
>   MdePkg/BaseLib: Add a new VMGEXIT instruction invocation for SVSM
>   UefiCpuPkg/CcExitLib: Extend the CcExitLib library to support an SVSM
>   Ovmfpkg/CcExitLib: Extend CcExitLib to handle SVSM related services
>   OvmfPkg: Create a calling area used to communicate with the SVSM
>   OvmfPkg/CcExitLib: Add support for the SVSM_CORE_PVALIDATE call
>   OvmfPkg/CcExitLib: Add support for the SVSM create/delete vCPU calls
>   UefiCpuPkg/MpInitLib: Use CcExitSnpVmsaRmpAdjust() to set/clear VMSA
>   MdePkg: GHCB APIC ID retrieval support definitions
>   UefiCpuPkg: Create APIC ID list PCD
>   OvmfPkg/PlatformPei: Retrieve APIC IDs from the hypervisor
>   UefiCpuPkg/MpInitLib: Always use AP Create if PcdSevSnpApicIds is set
>   UefiCpuPkg/MpInitLib: AP creation support under an SVSM
>   Ovmfpkg/CcExitLib: Provide SVSM discovery support
>   OvmfPkg/BaseMemEncryptLib: Check for presence of an SVSM when not at
> VMPL0
> 
>  OvmfPkg/OvmfPkg.dec   |   4 +
>  UefiCpuPkg/UefiCpuPkg.dec |   7 
> +-
>  OvmfPkg/AmdSev/AmdSevX64.fdf  |   9 
> +-
>  OvmfPkg/OvmfPkgX64.fdf|   3 +
>  MdePkg/Library/BaseLib/BaseLib.inf|   2 +
>  OvmfPkg/Library/CcExitLib/CcExitLib.inf   |   5 
> +-
>  OvmfPkg/Library/CcExitLib/SecCcExitLib.inf|   5 
> +-
>  OvmfPkg/PlatformPei/PlatformPei.inf   |   3 +
>  OvmfPkg/ResetVector/ResetVector.inf   |   2 +
>  UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf |   1 +
> 

Re: [edk2-devel] [PATCH 00/11] OvmfPkg: tweak shell builds

[Yao, Jiewen]

Always good to reduce duplication!
Thanks for doing that.

Acked-by: Jiewen Yao 

> -Original Message-
> From: Gerd Hoffmann 
> Sent: Thursday, January 25, 2024 12:38 AM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen ; Ard Biesheuvel
> ; Michael Roth ; Gerd
> Hoffmann ; Laszlo Ersek ; Aktas,
> Erdem ; Xu, Min M ; Tom
> Lendacky ; Oliver Steffen 
> Subject: [PATCH 00/11] OvmfPkg: tweak shell builds
> 
> - Create include files to reduce duplication.
> - Fix varpolicy command.
> - Little CI tweak.
> 
> Gerd Hoffmann (11):
>   OvmfPkg: add ShellComponents.dsc.inc
>   OvmfPkg: add ShellLibs.dsc.inc
>   OvmfPkg: add ShellDxe.fdf.inc
>   OvmfPkg: Shell*.inc: allow building without network support
>   OvmfPkg: ShellDxe.fdf.inc: add VariablePolicyDynamicCommand to FV
>   OvmfPkg: switch OvmfPkgIa32 to new shell include files
>   OvmfPkg: switch OvmfPkgIa32X64 to new shell include files
>   OvmfPkg: switch AmdSevX64 to new shell include files
>   OvmfPkg: switch IntelTdxX64 to new shell include files
>   OvmfPkg: switch MicrovmX64 to new shell include files
>   OvmfPkg/CI: copy shell to virtual drive
> 
>  OvmfPkg/Include/Dsc/ShellComponents.dsc.inc | 53 
>  OvmfPkg/Include/Dsc/ShellLibs.dsc.inc   | 11 +
>  OvmfPkg/AmdSev/AmdSevX64.dsc| 32 +---
>  OvmfPkg/IntelTdx/IntelTdxX64.dsc| 33 ++---
>  OvmfPkg/Microvm/MicrovmX64.dsc  | 55 +
>  OvmfPkg/OvmfPkgIa32.dsc | 49 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc  | 54 +++-
>  OvmfPkg/OvmfPkgX64.dsc  | 54 +++-
>  OvmfPkg/AmdSev/AmdSevX64.fdf|  8 +--
>  OvmfPkg/IntelTdx/IntelTdxX64.fdf|  9 +---
>  OvmfPkg/Microvm/MicrovmX64.fdf  |  9 +---
>  OvmfPkg/OvmfPkgIa32.fdf | 11 +
>  OvmfPkg/OvmfPkgIa32X64.fdf  | 11 +
>  OvmfPkg/OvmfPkgX64.fdf  | 11 +
>  OvmfPkg/Include/Fdf/ShellDxe.fdf.inc| 17 +++
>  OvmfPkg/PlatformCI/PlatformBuildLib.py  | 12 -
>  16 files changed, 135 insertions(+), 294 deletions(-)
>  create mode 100644 OvmfPkg/Include/Dsc/ShellComponents.dsc.inc
>  create mode 100644 OvmfPkg/Include/Dsc/ShellLibs.dsc.inc
>  create mode 100644 OvmfPkg/Include/Fdf/ShellDxe.fdf.inc
> 
> --
> 2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114362): https://edk2.groups.io/g/devel/message/114362
Mute This Topic: https://groups.io/mt/103935343/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/3] DxeTpm and DxeTpm2MeasureBootLib symbol rename

[Yao, Jiewen]

Thank you Doug for the prompt response.

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Douglas Flick [MSFT] 
> Sent: Thursday, January 18, 2024 6:47 AM
> To: devel@edk2.groups.io
> Cc: Douglas Flick [MSFT] ; Yao, Jiewen
> ; Kumar, Rahul R 
> Subject: [PATCH 0/3] DxeTpm and DxeTpm2MeasureBootLib symbol rename
> 
> OVMF is failing because it includes both DxeTpm2MeasureBootLib and
> DxeTpm2MeasureBootLib which makes the symbols collide. This patch
> renames the function names to be unique to avoid symbol collision.
> 
> Cc: Jiewen Yao 
> Cc: Rahul Kumar 
> 
> Signed-off-by: Doug Flick [MSFT] 
> 
> Douglas Flick [MSFT] (3):
>   SecurityPkg: DxeTpm2MeasureBootLib: SECURITY PATCH 4117/4118 symbol
> rename
>   SecurityPkg: DxeTpmMeasureBootLib: SECURITY PATCH 4117/4118 symbol
> rename
>   SecurityPkg: : Updating SecurityFixes.yaml after symbol rename
> 
>  .../DxeTpm2MeasureBootLibSanitization.h   |  8 +++---
>  .../DxeTpmMeasureBootLibSanitization.h|  8 +++---
>  .../DxeTpm2MeasureBootLib.c   |  8 +++---
>  .../DxeTpm2MeasureBootLibSanitization.c   |  8 +++---
>  .../DxeTpm2MeasureBootLibSanitizationTest.c   | 26 -
>  .../DxeTpmMeasureBootLib.c|  8 +++---
>  .../DxeTpmMeasureBootLibSanitization.c| 10 +++
>  .../DxeTpmMeasureBootLibSanitizationTest.c| 26 -
>  SecurityPkg/SecurityFixes.yaml| 28 +++
>  9 files changed, 68 insertions(+), 62 deletions(-)
> 
> --
> 2.43.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113980): https://edk2.groups.io/g/devel/message/113980
Mute This Topic: https://groups.io/mt/103797461/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/6] SECURITY PATCHES TCBZ4117 & TCBZ4118

[Yao, Jiewen]

Hi Marc
I notice you are reviewer for TPM module in OvmfPkg.

Would you please help to test the TPM2.0 feature with patch from Gerd?

Thank you
Yao, Jiewen

> -Original Message-
> From: Gerd Hoffmann 
> Sent: Wednesday, January 17, 2024 10:06 PM
> To: devel@edk2.groups.io; Yao, Jiewen 
> Cc: Li, Yi1 ; dougfl...@microsoft.com; Douglas Flick [MSFT]
> 
> Subject: Re: Re: [edk2-devel] [PATCH 0/6] SECURITY PATCHES TCBZ4117 &
> TCBZ4118
> 
> On Wed, Jan 17, 2024 at 08:23:19AM +, Yao, Jiewen wrote:
> > That is weird.
> > It seems we need to merge Gerd's patch soon -
> https://github.com/tianocore/edk2/pull/5265 to unblock CI.
> >
> > Hi Gerd
> > Would you please confirm what test you have done for removing TPM1.2?
> > Does TPM2.0 in OvmfPkg still work?
> 
> For RHEL we build OVMF with TPM1_ENABLE=FALSE for quite a while without
> seeing any problems, removing the TPM1_ENABLE option altogether should
> give in identical results.  I have to admit that I didn't actually test
> that though.
> 
> take care,
>   Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113952): https://edk2.groups.io/g/devel/message/113952
Mute This Topic: https://groups.io/mt/103675434/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/6] SECURITY PATCHES TCBZ4117 & TCBZ4118

[Yao, Jiewen]

That is weird.
It seems we need to merge Gerd's patch soon - 
https://github.com/tianocore/edk2/pull/5265 to unblock CI.

Hi Gerd
Would you please confirm what test you have done for removing TPM1.2?
Does TPM2.0 in OvmfPkg still work?

Hi Doug
I cannot tell why CI passed before but failed now.
But it does seems a big issue now. Would you please propose a patch to resolve 
it? Just rename the symbol.

Thank you
Yao, Jiewen

> -Original Message-
> From: Li, Yi1 
> Sent: Wednesday, January 17, 2024 4:15 PM
> To: Yao, Jiewen ; devel@edk2.groups.io; Gerd Hoffmann
> 
> Cc: dougfl...@microsoft.com; Douglas Flick [MSFT] 
> Subject: RE: [edk2-devel] [PATCH 0/6] SECURITY PATCHES TCBZ4117 & TCBZ4118
> 
> Hi Jiewen,
> 
> Sounds strange, but new PRs in today all broken due to this issue, e.g.:
> https://github.com/tianocore/edk2/pull/5210
> https://github.com/tianocore/edk2/pull/5268
> 
> 
> I checked build log, it matched the description from Gerd:
> https://dev.azure.com/tianocore/11ea4a10-ac9f-4e5f-8b13-
> 7def1f19d478/_apis/build/builds/114097/logs/350
> 2024-01-17T04:09:52.5996237Z INFO - /usr/bin/ld:
> DxeTpm2MeasureBootLibSanitization.obj (symbol from plugin): in function
> `SanitizeEfiPartitionTableHeader':
> 2024-01-17T04:09:52.6010570Z INFO - (.text+0x0): multiple definition of
> `SanitizeEfiPartitionTableHeader'; DxeTpmMeasureBootLibSanitization.obj
> (symbol from plugin):(.text+0x0): first defined here
> 2024-01-17T04:09:52.6020435Z INFO - /usr/bin/ld:
> DxeTpm2MeasureBootLibSanitization.obj (symbol from plugin): in function
> `SanitizeEfiPartitionTableHeader':
> 2024-01-17T04:09:52.6030987Z INFO - (.text+0x0): multiple definition of
> `SanitizePrimaryHeaderAllocationSize'; DxeTpmMeasureBootLibSanitization.obj
> (symbol from plugin):(.text+0x0): first defined here
> 2024-01-17T04:09:52.6040167Z INFO - /usr/bin/ld:
> DxeTpm2MeasureBootLibSanitization.obj (symbol from plugin): in function
> `SanitizeEfiPartitionTableHeader':
> 2024-01-17T04:09:52.6050625Z INFO - (.text+0x0): multiple definition of
> `SanitizePrimaryHeaderGptEventSize'; DxeTpmMeasureBootLibSanitization.obj
> (symbol from plugin):(.text+0x0): first defined here
> 2024-01-17T04:09:52.6061966Z INFO - /usr/bin/ld:
> DxeTpm2MeasureBootLibSanitization.obj (symbol from plugin): in function
> `SanitizeEfiPartitionTableHeader':
> 2024-01-17T04:09:52.6072661Z INFO - (.text+0x0): multiple definition of
> `SanitizePeImageEventSize'; DxeTpmMeasureBootLibSanitization.obj (symbol
> from plugin):(.text+0x0): first defined here
> 2024-01-17T04:10:12.9532147Z INFO - build.py...
> 2024-01-17T04:10:12.9593220Z INFO -  : error 7000: Failed to execute command
> 2024-01-17T04:10:23.2054653Z INFO - build.py...
> 2024-01-17T04:10:23.2055014Z INFO -  : error F002: Failed to build module
> 2024-01-17T04:10:23.2055379Z INFO -
>   /__w/1/s/MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.i
> nf [X64, GCC5, DEBUG]
> 
> -Original Message-
> From: Yao, Jiewen 
> Sent: Wednesday, January 17, 2024 4:09 PM
> To: Li, Yi1 ; devel@edk2.groups.io; Gerd Hoffmann
> 
> Cc: dougfl...@microsoft.com; Douglas Flick [MSFT] 
> Subject: RE: [edk2-devel] [PATCH 0/6] SECURITY PATCHES TCBZ4117 & TCBZ4118
> 
> Please check https://github.com/tianocore/edk2/pull/5264. It is merged after
> pass CI.
> 
> May I know where you see PR CI builds are broken?
> 
> Thank you
> Yao, Jiewen
> 
> > -Original Message-
> > From: Li, Yi1 
> > Sent: Wednesday, January 17, 2024 3:21 PM
> > To: devel@edk2.groups.io; Yao, Jiewen ; Gerd
> > Hoffmann 
> > Cc: dougfl...@microsoft.com; Douglas Flick [MSFT]
> > 
> > Subject: RE: [edk2-devel] [PATCH 0/6] SECURITY PATCHES TCBZ4117 &
> > TCBZ4118
> >
> > Hi Jiewen,
> >
> > All EDK2 PR CI builds of OvmfPkg are broken due to this issue.
> > Maybe we didn't have enough time to wait feedback and should fix the
> > CI issue first.
> >
> > Regards,
> > Yi
> >
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Yao,
> > Jiewen
> > Sent: Tuesday, January 16, 2024 10:38 PM
> > To: Gerd Hoffmann ; devel@edk2.groups.io
> > Cc: dougfl...@microsoft.com; Douglas Flick [MSFT]
> > 
> > Subject: Re: [edk2-devel] [PATCH 0/6] SECURITY PATCHES TCBZ4117 &
> > TCBZ4118
> >
> > Sure. Let's start from OVMF.
> >
> > We have leaf enough time for feedback, but I see no comment from other
> people.
> >
> >
> > > -Original Message-
> > > From: Gerd Hoffmann 
> > > Sent: Tuesday, January 16, 2024 10:35 PM
> > > To: devel@edk2.groups.io; Yao, Jiewen 
> > > Cc: dougfl...@micro

Re: [edk2-devel] [PATCH 0/6] SECURITY PATCHES TCBZ4117 & TCBZ4118

[Yao, Jiewen]

Please check https://github.com/tianocore/edk2/pull/5264. It is merged after 
pass CI.

May I know where you see PR CI builds are broken?

Thank you
Yao, Jiewen

> -Original Message-
> From: Li, Yi1 
> Sent: Wednesday, January 17, 2024 3:21 PM
> To: devel@edk2.groups.io; Yao, Jiewen ; Gerd Hoffmann
> 
> Cc: dougfl...@microsoft.com; Douglas Flick [MSFT] 
> Subject: RE: [edk2-devel] [PATCH 0/6] SECURITY PATCHES TCBZ4117 & TCBZ4118
> 
> Hi Jiewen,
> 
> All EDK2 PR CI builds of OvmfPkg are broken due to this issue.
> Maybe we didn't have enough time to wait feedback and should fix the CI issue
> first.
> 
> Regards,
> Yi
> 
> -Original Message-----
> From: devel@edk2.groups.io  On Behalf Of Yao, Jiewen
> Sent: Tuesday, January 16, 2024 10:38 PM
> To: Gerd Hoffmann ; devel@edk2.groups.io
> Cc: dougfl...@microsoft.com; Douglas Flick [MSFT] 
> Subject: Re: [edk2-devel] [PATCH 0/6] SECURITY PATCHES TCBZ4117 & TCBZ4118
> 
> Sure. Let's start from OVMF.
> 
> We have leaf enough time for feedback, but I see no comment from other people.
> 
> 
> > -Original Message-
> > From: Gerd Hoffmann 
> > Sent: Tuesday, January 16, 2024 10:35 PM
> > To: devel@edk2.groups.io; Yao, Jiewen 
> > Cc: dougfl...@microsoft.com; Douglas Flick [MSFT]
> > 
> > Subject: Re: Re: [edk2-devel] [PATCH 0/6] SECURITY PATCHES TCBZ4117 &
> > TCBZ4118
> >
> > On Tue, Jan 16, 2024 at 01:30:43PM +, Yao, Jiewen wrote:
> > > Gerd
> > > I have merged this patch set today.
> > >
> > > I am fine to remove TPM1.2 in OVMF because of the known security
> limitation.
> >
> > I was thinking about the complete edk2 code base not only OVMF.
> >
> > But I can surely start with OVMF.  Maybe it is the only platform
> > affected because on physical hardware you usually know whenever TPM
> > 1.2 or TPM 2.0 is present so there is no need to include both.
> >
> > take care,
> >   Gerd
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113935): https://edk2.groups.io/g/devel/message/113935
Mute This Topic: https://groups.io/mt/103675434/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/2] OvmfPkg: drop support for TPM 1.2

[Yao, Jiewen]

Gerd
I am OK with the patch.

Quick question: Have you validated that the TPM2 is still working?





> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Gerd
> Hoffmann
> Sent: Tuesday, January 16, 2024 11:42 PM
> To: devel@edk2.groups.io
> Cc: Oliver Steffen ; Gerd Hoffmann 
> Subject: [edk2-devel] [PATCH 0/2] OvmfPkg: drop support for TPM 1.2
> 
> 
> 
> Gerd Hoffmann (2):
>   OvmfPkg: remove TPM1_ENABLE build option
>   OvmfPkg/Tcg2Config: remove unused TPM 1.2 support
> 
>  .../Include/Dsc/OvmfTpmComponentsDxe.dsc.inc  |  6 --
>  .../Include/Dsc/OvmfTpmComponentsPei.dsc.inc  |  5 --
>  OvmfPkg/Include/Dsc/OvmfTpmDefines.dsc.inc|  3 -
>  OvmfPkg/Include/Dsc/OvmfTpmLibs.dsc.inc   |  9 --
>  .../Include/Dsc/OvmfTpmSecurityStub.dsc.inc   |  6 --
>  OvmfPkg/Tcg/Tcg2Config/Tcg12ConfigPei.inf | 56 -
>  OvmfPkg/Tcg/Tcg2Config/Tpm12Support.c | 83 ---
>  OvmfPkg/Include/Fdf/OvmfTpmDxe.fdf.inc|  3 -
>  OvmfPkg/Include/Fdf/OvmfTpmPei.fdf.inc|  5 --
>  OvmfPkg/PlatformCI/ReadMe.md  |  2 +-
>  10 files changed, 1 insertion(+), 177 deletions(-)
>  delete mode 100644 OvmfPkg/Tcg/Tcg2Config/Tcg12ConfigPei.inf
>  delete mode 100644 OvmfPkg/Tcg/Tcg2Config/Tpm12Support.c
> 
> --
> 2.43.0
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113924): https://edk2.groups.io/g/devel/message/113924
Mute This Topic: https://groups.io/mt/103764204/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/6] SECURITY PATCHES TCBZ4117 & TCBZ4118

[Yao, Jiewen]

Sure. Let's start from OVMF.

We have leaf enough time for feedback, but I see no comment from other people.


> -Original Message-
> From: Gerd Hoffmann 
> Sent: Tuesday, January 16, 2024 10:35 PM
> To: devel@edk2.groups.io; Yao, Jiewen 
> Cc: dougfl...@microsoft.com; Douglas Flick [MSFT] 
> Subject: Re: Re: [edk2-devel] [PATCH 0/6] SECURITY PATCHES TCBZ4117 &
> TCBZ4118
> 
> On Tue, Jan 16, 2024 at 01:30:43PM +, Yao, Jiewen wrote:
> > Gerd
> > I have merged this patch set today.
> >
> > I am fine to remove TPM1.2 in OVMF because of the known security limitation.
> 
> I was thinking about the complete edk2 code base not only OVMF.
> 
> But I can surely start with OVMF.  Maybe it is the only platform
> affected because on physical hardware you usually know whenever
> TPM 1.2 or TPM 2.0 is present so there is no need to include both.
> 
> take care,
>   Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113904): https://edk2.groups.io/g/devel/message/113904
Mute This Topic: https://groups.io/mt/103675434/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/6] SECURITY PATCHES TCBZ4117 & TCBZ4118

[Yao, Jiewen]

Gerd
I have merged this patch set today.

I am fine to remove TPM1.2 in OVMF because of the known security limitation.

Thank you
Yao, Jiewen


> -Original Message-
> From: Gerd Hoffmann 
> Sent: Tuesday, January 16, 2024 8:01 PM
> To: devel@edk2.groups.io; dougfl...@microsoft.com
> Cc: Douglas Flick [MSFT] ; Yao, Jiewen
> 
> Subject: Re: [edk2-devel] [PATCH 0/6] SECURITY PATCHES TCBZ4117 & TCBZ4118
> 
> On Thu, Jan 11, 2024 at 10:16:00AM -0800, Doug Flick via groups.io wrote:
> > This patch series include the combined / merged security patches
> > (as seperate commits) for TCBZ4117 (CVE-2022-36763) and TCBZ4118
> > (CVE-2022-36764) for DxeTpm2MeasureBootLib and DxeTpmMeasureBootLib.
> > These patches have already been reviewed by SecurityPkg Maintainer
> > (Jiewen) on GHSA.
> 
> This patch series breaks ovmf build (duplicate symbols) in case both
> TPM2 and TPM1 support are enabled (-D TPM2_ENABLE=TRUE
> -DTPM1_ENABLE=TRUE).  Compiling with TPM2 only (-D TPM2_ENABLE=TRUE
> -DTPM1_ENABLE=FALSE) works fine.
> 
> I see two options to deal with the problem:
> 
>  (1) Rename the Sanitize* functions in the TPM2 version of the library
>  to carry a '2' somewhere in the function name, simliar to all other
>  TPM2 functions, to avoid the name clash.
>  (2) Remove TPM1 support from the edk2 code base.  The relevance of
>  TPM 1.2 support should be close to zero given that the TPM 2.0
>  specification was released almost a decade ago ...
> 
> take care,
>   Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113898): https://edk2.groups.io/g/devel/message/113898
Mute This Topic: https://groups.io/mt/103675434/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/6] SECURITY PATCHES TCBZ4117 & TCBZ4118

[Yao, Jiewen]

Merged https://github.com/tianocore/edk2/pull/5264

> -Original Message-
> From: Douglas Flick [MSFT] 
> Sent: Friday, January 12, 2024 2:16 AM
> To: devel@edk2.groups.io
> Cc: Douglas Flick [MSFT] ; Yao, Jiewen
> 
> Subject: [PATCH 0/6] SECURITY PATCHES TCBZ4117 & TCBZ4118
> 
> This patch series include the combined / merged security patches
> (as seperate commits) for TCBZ4117 (CVE-2022-36763) and TCBZ4118
> (CVE-2022-36764) for DxeTpm2MeasureBootLib and DxeTpmMeasureBootLib.
> These patches have already been reviewed by SecurityPkg Maintainer
> (Jiewen) on GHSA.
> 
> This patch series (specifically TCBZ4117) supersedes TCBZ2168.
> 
> Cc: Jiewen Yao 
> 
> Douglas Flick [MSFT] (6):
>   SecurityPkg: DxeTpm2MeasureBootLib: SECURITY PATCH 4117 - CVE
> 2022-36763
>   SecurityPkg: DxeTpmMeasureBootLib: SECURITY PATCH 4117 - CVE
> 2022-36763
>   SecurityPkg: : Adding CVE 2022-36763 to SecurityFixes.yaml
>   SecurityPkg: DxeTpm2MeasureBootLib: SECURITY PATCH 4118 - CVE
> 2022-36764
>   SecurityPkg: DxeTpmMeasureBootLib: SECURITY PATCH 4118 - CVE
> 2022-36764
>   SecurityPkg: : Adding CVE 2022-36764 to SecurityFixes.yaml
> 
>  SecurityPkg/Test/SecurityPkgHostTest.dsc  |   2 +
>  .../DxeTpm2MeasureBootLib.inf |   4 +-
>  ...Tpm2MeasureBootLibSanitizationTestHost.inf |  28 ++
>  .../DxeTpmMeasureBootLib.inf  |   4 +-
>  ...eTpmMeasureBootLibSanitizationTestHost.inf |  28 ++
>  .../DxeTpm2MeasureBootLibSanitization.h   | 139 +++
>  .../DxeTpmMeasureBootLibSanitization.h| 137 +++
>  .../DxeTpm2MeasureBootLib.c   |  87 ++--
>  .../DxeTpm2MeasureBootLibSanitization.c   | 319 +++
>  .../DxeTpm2MeasureBootLibSanitizationTest.c   | 345 
>  .../DxeTpmMeasureBootLib.c|  53 ++-
>  .../DxeTpmMeasureBootLibSanitization.c| 285 +
>  .../DxeTpmMeasureBootLibSanitizationTest.c| 387 ++
>  SecurityPkg/SecurityFixes.yaml|  36 ++
>  SecurityPkg/SecurityPkg.ci.yaml   |   2 +
>  15 files changed, 1801 insertions(+), 55 deletions(-)
>  create mode 100644
> SecurityPkg/Library/DxeTpm2MeasureBootLib/InternalUnitTest/DxeTpm2Measur
> eBootLibSanitizationTestHost.inf
>  create mode 100644
> SecurityPkg/Library/DxeTpmMeasureBootLib/InternalUnitTest/DxeTpmMeasureB
> ootLibSanitizationTestHost.inf
>  create mode 100644
> SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLibSanitiza
> tion.h
>  create mode 100644
> SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLibSanitizatio
> n.h
>  create mode 100644
> SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLibSanitiza
> tion.c
>  create mode 100644
> SecurityPkg/Library/DxeTpm2MeasureBootLib/InternalUnitTest/DxeTpm2Measur
> eBootLibSanitizationTest.c
>  create mode 100644
> SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLibSanitizatio
> n.c
>  create mode 100644
> SecurityPkg/Library/DxeTpmMeasureBootLib/InternalUnitTest/DxeTpmMeasureB
> ootLibSanitizationTest.c
>  create mode 100644 SecurityPkg/SecurityFixes.yaml
> 
> --
> 2.43.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113878): https://edk2.groups.io/g/devel/message/113878
Mute This Topic: https://groups.io/mt/103675434/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] When TPM is enabled, Ubuntu doesn't boot

[Yao, Jiewen]

You already boot into ubuntu loader. After it gets TCG state, the system reset 
immediately.

===
FSOpen: Open '\EFI\ubuntu\BOOTX64.CSV' Success
Tcg2GetCapability ...
Size - 0x24
1.1 - 0x24, 1.0 - 0x1C
Tcg2GetCapability - Success
Reset System
===

I think you may need help from Ubuntu people.

Thank you
Yao, Jiewen

From: devel@edk2.groups.io  On Behalf Of Hamit Can Karaca
Sent: Friday, January 12, 2024 1:39 PM
To: Hamit Can Karaca ; devel@edk2.groups.io
Subject: Re: [edk2-devel] When TPM is enabled, Ubuntu doesn't boot

I still need help on this topic. I have added the DEBUG logs of the process. I 
would be grateful if anyone can help me.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113666): https://edk2.groups.io/g/devel/message/113666
Mute This Topic: https://groups.io/mt/103430908/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/6] SECURITY PATCHES TCBZ4117 & TCBZ4118

[Yao, Jiewen]

Hi Doug
Thanks for the fix.

Please remember to CC all SecurityPkg maintainer and reviewer.

I will merge after several days to see if there is any additional feedback from 
the community.

Thank you
Yao, Jiewen

> -Original Message-
> From: Douglas Flick [MSFT] 
> Sent: Friday, January 12, 2024 2:16 AM
> To: devel@edk2.groups.io
> Cc: Douglas Flick [MSFT] ; Yao, Jiewen
> 
> Subject: [PATCH 0/6] SECURITY PATCHES TCBZ4117 & TCBZ4118
> 
> This patch series include the combined / merged security patches
> (as seperate commits) for TCBZ4117 (CVE-2022-36763) and TCBZ4118
> (CVE-2022-36764) for DxeTpm2MeasureBootLib and DxeTpmMeasureBootLib.
> These patches have already been reviewed by SecurityPkg Maintainer
> (Jiewen) on GHSA.
> 
> This patch series (specifically TCBZ4117) supersedes TCBZ2168.
> 
> Cc: Jiewen Yao 
> 
> Douglas Flick [MSFT] (6):
>   SecurityPkg: DxeTpm2MeasureBootLib: SECURITY PATCH 4117 - CVE
> 2022-36763
>   SecurityPkg: DxeTpmMeasureBootLib: SECURITY PATCH 4117 - CVE
> 2022-36763
>   SecurityPkg: : Adding CVE 2022-36763 to SecurityFixes.yaml
>   SecurityPkg: DxeTpm2MeasureBootLib: SECURITY PATCH 4118 - CVE
> 2022-36764
>   SecurityPkg: DxeTpmMeasureBootLib: SECURITY PATCH 4118 - CVE
> 2022-36764
>   SecurityPkg: : Adding CVE 2022-36764 to SecurityFixes.yaml
> 
>  SecurityPkg/Test/SecurityPkgHostTest.dsc  |   2 +
>  .../DxeTpm2MeasureBootLib.inf |   4 +-
>  ...Tpm2MeasureBootLibSanitizationTestHost.inf |  28 ++
>  .../DxeTpmMeasureBootLib.inf  |   4 +-
>  ...eTpmMeasureBootLibSanitizationTestHost.inf |  28 ++
>  .../DxeTpm2MeasureBootLibSanitization.h   | 139 +++
>  .../DxeTpmMeasureBootLibSanitization.h| 137 +++
>  .../DxeTpm2MeasureBootLib.c   |  87 ++--
>  .../DxeTpm2MeasureBootLibSanitization.c   | 319 +++
>  .../DxeTpm2MeasureBootLibSanitizationTest.c   | 345 
>  .../DxeTpmMeasureBootLib.c|  53 ++-
>  .../DxeTpmMeasureBootLibSanitization.c| 285 +
>  .../DxeTpmMeasureBootLibSanitizationTest.c| 387 ++
>  SecurityPkg/SecurityFixes.yaml|  36 ++
>  SecurityPkg/SecurityPkg.ci.yaml   |   2 +
>  15 files changed, 1801 insertions(+), 55 deletions(-)
>  create mode 100644
> SecurityPkg/Library/DxeTpm2MeasureBootLib/InternalUnitTest/DxeTpm2Measur
> eBootLibSanitizationTestHost.inf
>  create mode 100644
> SecurityPkg/Library/DxeTpmMeasureBootLib/InternalUnitTest/DxeTpmMeasureB
> ootLibSanitizationTestHost.inf
>  create mode 100644
> SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLibSanitiza
> tion.h
>  create mode 100644
> SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLibSanitizatio
> n.h
>  create mode 100644
> SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLibSanitiza
> tion.c
>  create mode 100644
> SecurityPkg/Library/DxeTpm2MeasureBootLib/InternalUnitTest/DxeTpm2Measur
> eBootLibSanitizationTest.c
>  create mode 100644
> SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLibSanitizatio
> n.c
>  create mode 100644
> SecurityPkg/Library/DxeTpmMeasureBootLib/InternalUnitTest/DxeTpmMeasureB
> ootLibSanitizationTest.c
>  create mode 100644 SecurityPkg/SecurityFixes.yaml
> 
> --
> 2.43.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113637): https://edk2.groups.io/g/devel/message/113637
Mute This Topic: https://groups.io/mt/103675434/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency upon ArmPkg

[Yao, Jiewen]

Cool, thanks for considering that!

> -Original Message-
> From: Ard Biesheuvel 
> Sent: Wednesday, November 22, 2023 12:03 AM
> To: devel@edk2.groups.io; quic_llind...@quicinc.com
> Cc: Yao, Jiewen ; Pierre Gondois
> ; Li, Yi1 ; Lu, Xiaoyu1
> ; Jiang, Guomin ; Ard
> Biesheuvel ; Sami Mujawar
> ; Gerd Hoffmann 
> Subject: Re: [edk2-devel] [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow
> dependency upon ArmPkg
> 
> On Tue, 21 Nov 2023 at 10:55, Leif Lindholm  wrote:
> >
> > On Tue, Nov 21, 2023 at 14:46:05 +, Yao, Jiewen wrote:
> > > This Bugzilla is filed in 2022-10-26. Now it is 2023-11-21.
> >
> > Oh, I'm sure I voiced the same opinion for many years before someone
> > (rightly) told me to go gile that bugzilla.
> >
> > > I agree with you that it is a big task. May I know what is the plan?
> > > E.g. who is working on that? When do you expect it will be done?
> >
> > On my list of "big items" to deal with, this comes after github PR
> > migration and line-ending conversion.
> >
> > > According to the dependency rule, what we need is only *interface*
> > > definition, but not *implementation*.
> > > That means the really requirement here is to move *interface* from
> > > ArmPkg to MdePkg, you can still keep the library implementation in
> > > ArmPkg. (It is just a subset of this Bugzilla)
> >
> > That ... is an option I had not previously considered.
> > Long-term we would still like to smash ArmLib into BaseLib, but if
> > MdePkg maintainers would be OK with moving ArmLib.h into MdePkg...
> >
> > > Also, I don’t think CPUID check really matters here - since it is only
> implementation.
> > > As long as, you have interface in MdePkg, then your INF can declare that
> interface.
> > > You can still put real implementation in ArmPkg - no requirement to move.
> > > That benefit is that you don’t need to add ArmPkg dependency in yaml.
> >
> > I can spin up a patch for that to get merged shortly after stable tag
> > to give plenty of time to catch any issues that may arise from moving
> > such a fundamental file. (These would likely be bugs, but
> > nevertheless...)
> >
> 
> This sounds like a reasonable solution to me for the short term.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111563): https://edk2.groups.io/g/devel/message/111563
Mute This Topic: https://groups.io/mt/102725178/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency upon ArmPkg

[Yao, Jiewen]

This Bugzilla is filed in 2022-10-26. Now it is 2023-11-21.
I agree with you that it is a big task. May I know what is the plan?
E.g. who is working on that? When do you expect it will be done?



According to the dependency rule, what we need is only *interface* definition, 
but not *implementation*.
That means the really requirement here is to move *interface* from ArmPkg to 
MdePkg, you can still keep the library implementation in ArmPkg. (It is just a 
subset of this Bugzilla)
Also, I don’t think CPUID check really matters here - since it is only 
implementation.

As long as, you have interface in MdePkg, then your INF can declare that 
interface.
You can still put real implementation in ArmPkg - no requirement to move.
That benefit is that you don’t need to add ArmPkg dependency in yaml.

Thank you
Yao, Jiewen

> -Original Message-
> From: Leif Lindholm 
> Sent: Tuesday, November 21, 2023 10:26 PM
> To: Yao, Jiewen 
> Cc: Pierre Gondois ; devel@edk2.groups.io; Li, Yi1
> ; Lu, Xiaoyu1 ; Jiang, Guomin
> ; Ard Biesheuvel ; Sami
> Mujawar ; Gerd Hoffmann 
> Subject: Re: [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency
> upon ArmPkg
> 
> Hi Jiewen,
> 
> On Tue, Nov 21, 2023 at 13:41:21 +, Yao, Jiewen wrote:
> > Thanks to let me know the background.
> >
> > Please be aware that there is fundamental difference between
> > dependency in INF and dependency in DSC.
> >
> > What we have previously in the ArmPkg in *DSC*. We don’t need add
> > ArmPkg in yaml.
> > However, what you try to introduce is ArmPkg in *INF*, e.g. your
> > patch v5 5/6. Then we have to add ArmPkg in yaml.
> >
> > Personally, I don’t think it is a good idea to add ArmPkg to yaml,
> > because it means that you have to pull ArmPkg when you build
> > CryptoPkg,.
> >
> > As long as what you add is industry standard, it is OK to add to
> > MdePkg, like what you did in v2. I would like to suggest this
> > approach.
> 
> Ultimately, all of ArmPkg needs to migrate to MdePkg.
> See https://bugzilla.tianocore.org/show_bug.cgi?id=4121
> But this is a BIG task.
> 
> The reason I asked Pierre to add this functionality in ArmPkg rather
> than MdePkg is because that is where the existing related discovery
> code lives. (Think of it as CPUID.)
> 
> For historical reasons, predating mine and Ard's involvement with
> edk2, this functionality (as well as other critical Arm functionality)
> lives in a library called ArmLib, under ArmPkg.
> For Ia32/X64, all such support lives in BaseLib, under MdePkg.
> 
> This is why I referred to ArmPkg as an exclave of MdePkg in my
> original reply to Pierre. And until someone untangles this, it's not
> realistic to treat ArmPkg as anything else.
> 
> And I don't think it's fair to expect Pierre to untangle this as part
> of this series. But I also don't think "Arm architectures need to
> duplicate their basic support code across multiple packages" is a
> solution.
> 
> Regards,
> 
> Leif
> 
> > But I would like to have ARM expert to check if those are really ARM
> > standard, and also have MdePkg owner check if it is acceptable.
> >
> > Thank you
> > Yao, Jiewen
> >
> >
> >
> >
> > > -Original Message-
> > > From: Pierre Gondois 
> > > Sent: Tuesday, November 21, 2023 8:59 PM
> > > To: Yao, Jiewen ; devel@edk2.groups.io; Leif
> Lindholm
> > > 
> > > Cc: Li, Yi1 ; Lu, Xiaoyu1 ; Jiang,
> Guomin
> > > ; Ard Biesheuvel ;
> Sami
> > > Mujawar ; Gerd Hoffmann 
> > > Subject: Re: [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency
> > > upon ArmPkg
> > >
> > > Hello Jiewen,
> > >
> > > On 11/21/23 12:27, Yao, Jiewen wrote:
> > > > Why CryptoPkg needs to depend on ArmPkg?
> > > >
> > > > Can we move content to MdePkg?
> > >
> > > The OpensslLib needs to discover the native instruction supported by the
> > > underlying platform before using them. This could also be done through the
> > > MdePkg as you suggested. The v2 is implemented that way:
> > > https://edk2.groups.io/g/devel/message/110953
> > >
> > > Also, as noted by Leif, it seems there is already a dependency over 
> > > ArmPkg:
> > > # git grep ArmPkg CryptoPkg/
> > > CryptoPkg/CryptoPkg.dsc:  ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
> > > CryptoPkg/CryptoPkg.dsc:
> > > NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> > > CryptoPkg/CryptoPkg.dsc:
> > > ArmSoftFloatLib|ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
> > >

Re: [edk2-devel] [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency upon ArmPkg

[Yao, Jiewen]

Thanks to let me know the background.

Please be aware that there is fundamental difference between dependency in INF 
and dependency in DSC.

What we have previously in the ArmPkg in *DSC*. We don’t need add ArmPkg in 
yaml.
However, what you try to introduce is ArmPkg in *INF*, e.g. your patch v5 5/6. 
Then we have to add ArmPkg in yaml.

Personally, I don’t think it is a good idea to add ArmPkg to yaml, because it 
means that you have to pull ArmPkg when you build CryptoPkg,.


As long as what you add is industry standard, it is OK to add to MdePkg, like 
what you did in v2. I would like to suggest this approach.

But I would like to have ARM expert to check if those are really ARM standard, 
and also have MdePkg owner check if it is acceptable.

Thank you
Yao, Jiewen




> -Original Message-
> From: Pierre Gondois 
> Sent: Tuesday, November 21, 2023 8:59 PM
> To: Yao, Jiewen ; devel@edk2.groups.io; Leif Lindholm
> 
> Cc: Li, Yi1 ; Lu, Xiaoyu1 ; Jiang, 
> Guomin
> ; Ard Biesheuvel ; Sami
> Mujawar ; Gerd Hoffmann 
> Subject: Re: [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency
> upon ArmPkg
> 
> Hello Jiewen,
> 
> On 11/21/23 12:27, Yao, Jiewen wrote:
> > Why CryptoPkg needs to depend on ArmPkg?
> >
> > Can we move content to MdePkg?
> 
> The OpensslLib needs to discover the native instruction supported by the
> underlying platform before using them. This could also be done through the
> MdePkg as you suggested. The v2 is implemented that way:
> https://edk2.groups.io/g/devel/message/110953
> 
> Also, as noted by Leif, it seems there is already a dependency over ArmPkg:
> # git grep ArmPkg CryptoPkg/
> CryptoPkg/CryptoPkg.dsc:  ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
> CryptoPkg/CryptoPkg.dsc:
> NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> CryptoPkg/CryptoPkg.dsc:
> ArmSoftFloatLib|ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
> CryptoPkg/CryptoPkgMbedTls.dsc:
> NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> CryptoPkg/CryptoPkgMbedTls.dsc:
> ArmSoftFloatLib|ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
> CryptoPkg/CryptoPkgMbedTls.dsc:
> PeiServicesTablePointerLib|ArmPkg/Library/PeiServicesTablePointerLib/PeiServic
> esTablePointerLib.inf
> 
> Both solutions suit me (discovering capabilities through ArmPkg or MdePkg),
> I just need to know which one is preferred,
> 
> Regards,
> Pierre
> 
> >
> >> -Original Message-
> >> From: Pierre Gondois 
> >> Sent: Tuesday, November 21, 2023 4:47 PM
> >> To: devel@edk2.groups.io
> >> Cc: Yao, Jiewen ; Li, Yi1 ; Lu,
> Xiaoyu1
> >> ; Jiang, Guomin ; Leif
> Lindholm
> >> ; Ard Biesheuvel ;
> >> Sami Mujawar ; Gerd Hoffmann
> >> 
> >> Subject: [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency upon
> >> ArmPkg
> >>
> >> Allow dependency upon ArmPkg to pass the dependency Check.
> >>
> >> Signed-off-by: Pierre Gondois 
> >> ---
> >>   CryptoPkg/CryptoPkg.ci.yaml | 1 +
> >>   1 file changed, 1 insertion(+)
> >>
> >> diff --git a/CryptoPkg/CryptoPkg.ci.yaml b/CryptoPkg/CryptoPkg.ci.yaml
> >> index f961d85927c0..3bbb220d3224 100644
> >> --- a/CryptoPkg/CryptoPkg.ci.yaml
> >> +++ b/CryptoPkg/CryptoPkg.ci.yaml
> >> @@ -69,6 +69,7 @@
> >>   },
> >>
> >>   "DependencyCheck": {
> >>
> >>   "AcceptableDependencies": [
> >>
> >> +"ArmPkg/ArmPkg.dec",
> >>
> >>   "MdePkg/MdePkg.dec",
> >>
> >>   "MdeModulePkg/MdeModulePkg.dec",
> >>
> >>   "CryptoPkg/CryptoPkg.dec",
> >>
> >> --
> >> 2.25.1
> >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111545): https://edk2.groups.io/g/devel/message/111545
Mute This Topic: https://groups.io/mt/102725178/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency upon ArmPkg

[Yao, Jiewen]

Why CryptoPkg needs to depend on ArmPkg?

Can we move content to MdePkg?

> -Original Message-
> From: Pierre Gondois 
> Sent: Tuesday, November 21, 2023 4:47 PM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen ; Li, Yi1 ; Lu, 
> Xiaoyu1
> ; Jiang, Guomin ; Leif Lindholm
> ; Ard Biesheuvel ;
> Sami Mujawar ; Gerd Hoffmann
> 
> Subject: [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency upon
> ArmPkg
> 
> Allow dependency upon ArmPkg to pass the dependency Check.
> 
> Signed-off-by: Pierre Gondois 
> ---
>  CryptoPkg/CryptoPkg.ci.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/CryptoPkg/CryptoPkg.ci.yaml b/CryptoPkg/CryptoPkg.ci.yaml
> index f961d85927c0..3bbb220d3224 100644
> --- a/CryptoPkg/CryptoPkg.ci.yaml
> +++ b/CryptoPkg/CryptoPkg.ci.yaml
> @@ -69,6 +69,7 @@
>  },
> 
>  "DependencyCheck": {
> 
>  "AcceptableDependencies": [
> 
> +"ArmPkg/ArmPkg.dec",
> 
>  "MdePkg/MdePkg.dec",
> 
>  "MdeModulePkg/MdeModulePkg.dec",
> 
>  "CryptoPkg/CryptoPkg.dec",
> 
> --
> 2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111542): https://edk2.groups.io/g/devel/message/111542
Mute This Topic: https://groups.io/mt/102725178/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/3] Maintainers.txt: add Laszlo Ersek as an ArmVirt, Ovmf, UefiCpu Pkg "M"

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Kinney, Michael D 
> Sent: Friday, November 17, 2023 6:52 AM
> To: Laszlo Ersek ; devel@edk2.groups.io
> Cc: Andrew Fish ; Ard Biesheuvel
> ; Gerd Hoffmann ; Yao,
> Jiewen ; Leif Lindholm ;
> Kumar, Rahul R ; Ni, Ray ; Sami
> Mujawar ; Kinney, Michael D
> 
> Subject: RE: [PATCH 0/3] Maintainers.txt: add Laszlo Ersek as an ArmVirt, 
> Ovmf,
> UefiCpu Pkg "M"
> 
> Series Reviewed-by: Michael D Kinney 
> 
> > -Original Message-
> > From: Laszlo Ersek 
> > Sent: Thursday, November 16, 2023 1:51 PM
> > To: devel@edk2.groups.io
> > Cc: Andrew Fish ; Ard Biesheuvel
> > ; Gerd Hoffmann ; Yao,
> > Jiewen ; Leif Lindholm
> > ; Kinney, Michael D
> > ; Kumar, Rahul R
> > ; Ni, Ray ; Sami Mujawar
> > 
> > Subject: [PATCH 0/3] Maintainers.txt: add Laszlo Ersek as an ArmVirt,
> > Ovmf, UefiCpu Pkg "M"
> >
> > I'm offering to restore a subset of my earlier ArmVirtPkg and OvmfPkg
> > maintainer responsibilities.
> >
> > I'm both offering and requesting an escalation of my earlier
> > UefiCpuPkg
> > role.
> >
> > The commit messages contain lists of files and directories that I
> > intend
> > to assist with.
> >
> > Under ArmVirtPkg, my focus is the ArmVirtQemu platform.
> >
> > Under OvmfPkg and UefiCpuPkg, my focus is the traditional three OVMF
> > platforms (IA32, IA32X64, X64) and their dependencies; in particular I
> > refrain from Confidential Computing technologies. Under OvmfPkg, I may
> > also not be the primary reviewer of those nontrivial device drivers
> > and
> > libraries that I neither wrote nor reviewed.
> >
> > Finally, I'm interested in reviewing patches for most of the edk2
> > core,
> > and patches for the RISC-V architecture; but it's too early to
> > formalize
> > those interests even as some "R" lines.
> >
> > Cc: Andrew Fish 
> > Cc: Ard Biesheuvel 
> > Cc: Gerd Hoffmann 
> > Cc: Jiewen Yao 
> > Cc: Leif Lindholm 
> > Cc: Michael D Kinney 
> > Cc: Rahul Kumar 
> > Cc: Ray Ni 
> > Cc: Sami Mujawar 
> >
> > Thanks,
> > Laszlo
> >
> > Laszlo Ersek (3):
> >   Maintainers.txt: add Laszlo Ersek as an ArmVirtPkg maintainer
> >   Maintainers.txt: add Laszlo Ersek as an OvmfPkg maintainer
> >   Maintainers.txt: add Laszlo Ersek as a UefiCpuPkg maintainer
> >
> >  Maintainers.txt | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> >
> > base-commit: 3db76e6476e493d3cda45b81bba99a645180cf35


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111335): https://edk2.groups.io/g/devel/message/111335
Mute This Topic: https://groups.io/mt/102636309/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 3/3] OvmfPkg: Format with Uncrustify 73.0.8

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: mikub...@linux.microsoft.com 
> Sent: Wednesday, November 15, 2023 4:22 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Corvin Köhne
> ; Gerd Hoffmann ; Yao, Jiewen
> ; Rebecca Cran 
> Subject: [PATCH v1 3/3] OvmfPkg: Format with Uncrustify 73.0.8
> 
> From: Michael Kubacki 
> 
> Cc: Ard Biesheuvel 
> Cc: Corvin Köhne 
> Cc: Gerd Hoffmann 
> Cc: Jiewen Yao 
> Cc: Rebecca Cran 
> Signed-off-by: Michael Kubacki 
> ---
>  OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c |  4 
> ++--
>  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c |
> 24 ++--
>  OvmfPkg/PlatformPei/MemTypeInfo.c  |  2 
> +-
>  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c   |  6 
> ++---
>  4 files changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c
> b/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c
> index 4fc715dc3681..c07e38966e36 100644
> --- a/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c
> +++ b/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c
> @@ -658,8 +658,8 @@ InitializeFvAndVariableStoreHeaders (
> 
>// UINT32  Size;
>(
> -   FixedPcdGet32 (PcdFlashNvStorageVariableSize) -
> -   OFFSET_OF (FVB_FV_HDR_AND_VARS_TEMPLATE, VarHdr)
> +FixedPcdGet32 (PcdFlashNvStorageVariableSize) -
> +OFFSET_OF (FVB_FV_HDR_AND_VARS_TEMPLATE, VarHdr)
>),
> 
>// UINT8   Format;
> diff --git
> a/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c
> b/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c
> index 3092a174bc51..0b388819 100644
> ---
> a/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c
> +++
> b/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c
> @@ -49,12 +49,12 @@ STATIC
> EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL
>  STATIC CONST EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR  mMmio64Configuration
> = {
>ACPI_ADDRESS_SPACE_DESCRIPTOR,   // Desc
>(UINT16)(// Len
> -   sizeof 
> (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) -
> -   OFFSET_OF (
> - 
> EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR,
> - ResType
> - )
> -   ),
> +sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) -
> +OFFSET_OF (
> +  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR,
> +  ResType
> +  )
> +),
>ACPI_ADDRESS_SPACE_TYPE_MEM, // ResType
>0,   // GenFlag
>0,   // SpecificFlag
> @@ -83,12 +83,12 @@ STATIC CONST EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR
> mMmio64Configuration = {
>  STATIC CONST EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR
> mOptionRomConfiguration =   {
>ACPI_ADDRESS_SPACE_DESCRIPTOR,   // Desc
>(UINT16)(// Len
> -   sizeof 
> (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) -
> -   OFFSET_OF (
> - 
> EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR,
> - ResType
> - )
> -   ),
> +sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) -
> +OFFSET_OF (
> +  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR,
> +  ResType
> +  )
> +),
>ACPI_ADDRESS_SPACE_TYPE_MEM, // ResType
>0,   // GenFlag
>0,   // Disable option roms 
> SpecificFlag
> diff --git a/OvmfPkg/PlatformPei/MemTypeInfo.c
> b/OvmfPkg/PlatformPei/MemTypeInfo.c
> index ea049b21cfc0..dfb1bc37a93d 100644
> --- a/OvmfPkg/PlatformPei/MemTypeInfo.c
> +++ b/OvmfPkg/PlatformPei/MemTypeInfo.c
> @@ -196,7 +196,7 @@ OnReadOnlyVariable2Available (
>  //
>  STATIC CONST EFI_PEI_NOTIFY_DESCRIPTOR  mReadOnlyVariable2Notify = {
>(EFI_PEI_PPI_DESCRIPTOR_NOTIFY_DISPATCH |
> -   EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),  // Flags
> +EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST), // Flags
>, // Guid
>OnReadOnlyVariable2Available  // Notify
>

Re: [edk2-devel] [PATCH 00/37] OvmfPkg: remove the CSM (after edk2-stable202311)

[Yao, Jiewen]

Glad to see we can get rid of the legacy burden.

All: Reviewed-by: Jiewen Yao 


> -Original Message-
> From: Laszlo Ersek 
> Sent: Saturday, November 11, 2023 7:58 AM
> To: devel@edk2.groups.io
> Cc: Anatol Belski ; Warkentin, Andrei
> ; Anthony Perard ;
> Ard Biesheuvel ; Corvin Köhne
> ; Aktas, Erdem ; Gerd
> Hoffmann ; Jianyong Wu ; Yao,
> Jiewen ; Michael Roth ; Xu,
> Min M ; Rebecca Cran ; Sunil V L
> ; Tom Lendacky 
> Subject: [PATCH 00/37] OvmfPkg: remove the CSM (after edk2-stable202311)
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
> CI: https://github.com/tianocore/edk2/pull/5031 (@ 961d5add9f03)
> 
> Remove the Compatibility Support Module (CSM) from OVMF (after
> edk2-stable202311).
> 
> Modify the following platforms:
> 
>   OvmfPkg/AmdSev/AmdSevX64.dsc
>   OvmfPkg/Bhyve/BhyveX64.dsc
>   OvmfPkg/CloudHv/CloudHvX64.dsc
>   OvmfPkg/IntelTdx/IntelTdxX64.dsc
>   OvmfPkg/Microvm/MicrovmX64.dsc
>   OvmfPkg/OvmfPkgIa32.dsc
>   OvmfPkg/OvmfPkgIa32X64.dsc
>   OvmfPkg/OvmfPkgX64.dsc
>   OvmfPkg/OvmfXen.dsc
> 
> Each of those platforms builds at every stage of the series.
> 
> Follow a gradual approach. Peel off CSM components in (reverse)
> dependency order:
> 
> - exclude a high-level CSM component (library or driver) from the OVMF
>   platforms, without breaking dependencies of low-level components;
> 
> - delete the high-level component from OvmfPkg;
> 
> - add, to a removal queue, any source code artifacts (protocols, GUIDs,
>   headers, PCDs) that the high-level component's deletion
>   *unreferences*;
> 
> - delete all entries of the removal queue (protocols, GUIDs, headers,
>   PCDs) from the edk2 source tree that are now completely unreferenced
>   (... and extend the removal queue recursively, if needed);
> 
> - advance to the next component that now qualifies as "high-level"
>   (because nothing consumes the services it provides any longer), and
>   exclude that one.
> 
> Regression-test the traditional platforms as needed; see the notes in
> the following patches:
> 
> - OvmfPkg: remove PcdCsmEnable
> - OvmfPkg/IncompatiblePciDeviceSupportDxe: ignore CSM presence
> - OvmfPkg: exclude 8254TimerDxe
> 
> Cc: Anatol Belski 
> Cc: Andrei Warkentin 
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Corvin Köhne 
> Cc: Erdem Aktas 
> Cc: Gerd Hoffmann 
> Cc: Jianyong Wu 
> Cc: Jiewen Yao 
> Cc: Michael Roth 
> Cc: Min Xu 
> Cc: Rebecca Cran 
> Cc: Sunil V L 
> Cc: Tom Lendacky 
> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (37):
>   OvmfPkg: cripple CSM_ENABLE macro
>   OvmfPkg: remove PcdCsmEnable
>   OvmfPkg: unplug LegacyBootManagerLib from BdsDxe and UiApp
>   OvmfPkg: remove LegacyBootManagerLib
>   OvmfPkg: unplug LegacyBootMaintUiLib from UiApp
>   OvmfPkg: remove LegacyBootMaintUiLib
>   OvmfPkg: remove gEfiLegacyDevOrderVariableGuid
>   OvmfPkg: exclude the CSM-based VideoDxe driver
>   OvmfPkg: remove Csm/BiosThunk/VideoDxe
>   OvmfPkg: remove gEfiVgaMiniPortProtocolGuid
>   OvmfPkg: remove Bios Video PCDs
>   OvmfPkg: exclude LegacyBiosDxe
>   OvmfPkg/IncompatiblePciDeviceSupportDxe: ignore CSM presence
>   Revert "OvmfPkg: don't assign PCI BARs above 4GiB when CSM enabled"
>   OvmfPkg: remove LegacyBiosDxe
>   OvmfPkg: exclude NullMemoryTestDxe driver
>   OvmfPkg: remove gEfiIsaIoProtocolGuid
>   OvmfPkg: remove gEfiIsaAcpiProtocolGuid
>   OvmfPkg: remove gEfiLegacyBiosGuid
>   OvmfPkg: remove LegacyBiosDxe PCDs
>   OvmfPkg: unplug CsmSupportLib from BdsDxe
>   OvmfPkg: remove CsmSupportLib
>   OvmfPkg: remove gEfiFirmwareVolumeProtocolGuid
>   OvmfPkg: remove gEfiLegacyBiosPlatformProtocolGuid
>   OvmfPkg: remove gEfiLegacyBiosProtocolGuid
>   OvmfPkg: remove gEfiLegacyInterruptProtocolGuid
>   OvmfPkg: remove 
>   OvmfPkg: exclude Csm16.inf / Csm16.bin
>   OvmfPkg: remove Rule.Common.USER_DEFINED.CSM from all FDF files
>   OvmfPkg: remove Csm16
>   OvmfPkg: exclude 8254TimerDxe
>   OvmfPkg: remove 8254TimerDxe
>   OvmfPkg: exclude 8259InterruptControllerDxe
>   OvmfPkg: remove 8259InterruptControllerDxe
>   OvmfPkg: remove gEfiLegacy8259ProtocolGuid
>   OvmfPkg: remove Pcd8259LegacyModeEdgeLevel and
> Pcd8259LegacyModeMask
>   OvmfPkg: remove CSM_ENABLE build macro
> 
>  OvmfPkg/8254TimerDxe/8254Timer.inf   |   
> 43 -
>  OvmfPkg/8254TimerDxe/Timer.c |  
> 406 ---
>  OvmfPkg/8254TimerDxe/Timer.h |  
> 186 --
>  OvmfPkg/8254TimerDxe/Timer.uni   |   
> 16 -
>  OvmfPkg/8254TimerDxe/TimerExtra.uni

Re: [edk2-devel] [edk2-stable202311] [PATCH V4 0/3] OvmfPkg: Update TdVmCall to handle the retry for MapGPA

[Yao, Jiewen]

Thank you.
Merged. https://github.com/tianocore/edk2/pull/5026

> -Original Message-
> From: gaoliming 
> Sent: Thursday, November 9, 2023 9:54 PM
> To: devel@edk2.groups.io; Yao, Jiewen ; Sun, CepingX
> ; Kinney, Michael D ;
> 'Leif Lindholm' ; 'Andrew Fish' 
> Cc: Aktas, Erdem ; 'James Bottomley'
> ; Xu, Min M ; 'Tom Lendacky'
> ; 'Michael Roth' ; 'Gerd
> Hoffmann' 
> Subject: 回复: [edk2-stable202311] [PATCH V4 0/3] OvmfPkg: Update TdVmCall
> to handle the retry for MapGPA
> 
> Jiewen:
>   I have gave my reviewed-by for the change in MdePkg. I agree its impact is
> small. I think this patch set can be merged for this stable tag.
> 
> Thanks
> Liming
> > -邮件原件-
> > 发件人: devel@edk2.groups.io  代表 Yao, Jiewen
> > 发送时间: 2023年11月8日 21:29
> > 收件人: devel@edk2.groups.io; Yao, Jiewen ; Sun,
> > CepingX ; Kinney, Michael D
> > ; Gao, Liming 
> > 抄送: Aktas, Erdem ; James Bottomley
> > ; Xu, Min M ; Tom Lendacky
> > ; Michael Roth ;
> > Gerd Hoffmann 
> > 主题: Re: [edk2-devel] [PATCH V4 0/3] OvmfPkg: Update TdVmCall to handle
> > the retry for MapGPA
> >
> > Hi Liming and Mike
> > Would you please review the MdePkg update?
> >
> > This patch was sent before soft freeze.
> > I request that it be in 202311 release because this patch is required by
> the
> > latest KVM/QEMU.
> > This patch only impacts Intel TDX, and has no impact to other CC (AMD SEV)
> > or non-CC module.
> >
> > Thank you
> > Yao, Jiewen
> >
> >
> > > -Original Message-
> > > From: devel@edk2.groups.io  On Behalf Of Yao,
> > Jiewen
> > > Sent: Wednesday, November 8, 2023 9:21 PM
> > > To: Sun, CepingX ; devel@edk2.groups.io
> > > Cc: Gao, Liming ; Kinney, Michael D
> > > ; Aktas, Erdem ;
> > James
> > > Bottomley ; Xu, Min M ; Tom
> > > Lendacky ; Michael Roth
> > > ; Gerd Hoffmann 
> > > Subject: Re: [edk2-devel] [PATCH V4 0/3] OvmfPkg: Update TdVmCall to
> > handle
> > > the retry for MapGPA
> > >
> > > All: Reviewed-by: Jiewen Yao 
> > >
> > >
> > > > -Original Message-
> > > > From: Sun, CepingX 
> > > > Sent: Wednesday, November 8, 2023 7:38 PM
> > > > To: devel@edk2.groups.io
> > > > Cc: Sun, CepingX ; Gao, Liming
> > > > ; Kinney, Michael D
> > > ;
> > > > Aktas, Erdem ; James Bottomley
> > > > ; Xu, Min M ; Tom Lendacky
> > > > ; Michael Roth ;
> > Yao,
> > > > Jiewen ; Gerd Hoffmann 
> > > > Subject: [PATCH V4 0/3] OvmfPkg: Update TdVmCall to handle the retry
> > for
> > > > MapGPA
> > > >
> > > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4572
> > > >
> > > > According to section 3.2 of the [GHCI] spec, if the result is
> > > > "TDG.VP.VMCALL_RETRY" for TDG.VP.VMCALL.MapGPA, TD must retry the
> > > > mapping for the pages in the region starting at the GPA specified in
> r11.
> > > >
> > > > Currently, TDVF does not properly handle the retry results of MapGPA.
> > > > For this, TDVF should update the TdVmCall to return the value in R11
> > > > and must retry the mapping for the pages by the value.
> > > >
> > > > How to verify the retry for MapGPA in TDVF:
> > > > Note: Since the range size of MapGPA in QEMU is limited to 64MB and
> > > > TDVF always maps 1.5GB( 2GB~3.5GB) MMIO to shared-memory for TD
> > guest,
> > > > the retry action is triggered always.
> > > > Pre-Config:
> > > > QEMU:
> > > > https://github.com/intel/qemu-tdx/tree/tdx-qemu-upstream | tag:
> > tdx-qemu-
> > > > upstream-2023.10.20-v8.1.0
> > > > KERNEL:
> > > > https://github.com/intel/tdx/tree/kvm-upstream-2023.10.16-v6.6-rc2
> > > >
> > > > Step:
> > > > Boot with TD guest and check the log with TdVmcall(MAPGPA), as below:
> > > > TdxDxe:SetMemorySharedOrPrivate: Cr3Base=0x0 Physical=0x8000
> > > > Length=0x6000 Mode=Shared
> > > > SetOrClearSharedBit: TdVmcall(MAPGPA) Retry PhysicalAddress is
> > > > 88000, MapGpaRetryaddr is 88400
> > > >
> > > > Reference:
> > > > [GHCI]: TDX Guest-Host-Communication Interface v1.0
> > > > https://cdrdv2.intel.com/v1/dl/getContent/726790
> > > >
> > > > v2 changes:
> > > >   - Update the code based on the co

Re: [edk2-devel] [PATCH V4 0/3] OvmfPkg: Update TdVmCall to handle the retry for MapGPA

[Yao, Jiewen]

Hi Liming and Mike
Would you please review the MdePkg update?

This patch was sent before soft freeze.
I request that it be in 202311 release because this patch is required by the 
latest KVM/QEMU.
This patch only impacts Intel TDX, and has no impact to other CC (AMD SEV) or 
non-CC module.

Thank you
Yao, Jiewen


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Yao, Jiewen
> Sent: Wednesday, November 8, 2023 9:21 PM
> To: Sun, CepingX ; devel@edk2.groups.io
> Cc: Gao, Liming ; Kinney, Michael D
> ; Aktas, Erdem ; James
> Bottomley ; Xu, Min M ; Tom
> Lendacky ; Michael Roth
> ; Gerd Hoffmann 
> Subject: Re: [edk2-devel] [PATCH V4 0/3] OvmfPkg: Update TdVmCall to handle
> the retry for MapGPA
> 
> All: Reviewed-by: Jiewen Yao 
> 
> 
> > -Original Message-
> > From: Sun, CepingX 
> > Sent: Wednesday, November 8, 2023 7:38 PM
> > To: devel@edk2.groups.io
> > Cc: Sun, CepingX ; Gao, Liming
> > ; Kinney, Michael D
> ;
> > Aktas, Erdem ; James Bottomley
> > ; Xu, Min M ; Tom Lendacky
> > ; Michael Roth ; Yao,
> > Jiewen ; Gerd Hoffmann 
> > Subject: [PATCH V4 0/3] OvmfPkg: Update TdVmCall to handle the retry for
> > MapGPA
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4572
> >
> > According to section 3.2 of the [GHCI] spec, if the result is
> > "TDG.VP.VMCALL_RETRY" for TDG.VP.VMCALL.MapGPA, TD must retry the
> > mapping for the pages in the region starting at the GPA specified in r11.
> >
> > Currently, TDVF does not properly handle the retry results of MapGPA.
> > For this, TDVF should update the TdVmCall to return the value in R11
> > and must retry the mapping for the pages by the value.
> >
> > How to verify the retry for MapGPA in TDVF:
> > Note: Since the range size of MapGPA in QEMU is limited to 64MB and
> > TDVF always maps 1.5GB( 2GB~3.5GB) MMIO to shared-memory for TD guest,
> > the retry action is triggered always.
> > Pre-Config:
> > QEMU:
> > https://github.com/intel/qemu-tdx/tree/tdx-qemu-upstream | tag: tdx-qemu-
> > upstream-2023.10.20-v8.1.0
> > KERNEL:
> > https://github.com/intel/tdx/tree/kvm-upstream-2023.10.16-v6.6-rc2
> >
> > Step:
> > Boot with TD guest and check the log with TdVmcall(MAPGPA), as below:
> > TdxDxe:SetMemorySharedOrPrivate: Cr3Base=0x0 Physical=0x8000
> > Length=0x6000 Mode=Shared
> > SetOrClearSharedBit: TdVmcall(MAPGPA) Retry PhysicalAddress is
> > 88000, MapGpaRetryaddr is 88400
> >
> > Reference:
> > [GHCI]: TDX Guest-Host-Communication Interface v1.0
> > https://cdrdv2.intel.com/v1/dl/getContent/726790
> >
> > v2 changes:
> >   - Update the code based on the comments of v1 reviewer
> >   - Update TdVmcall to instead of the extra API file
> >
> > v3 changes:
> >   - Move the definition of TDVMCALL_STATUS_RETRY to Tdx.h
> >
> > v4 changes:
> >   - Split the patch to MdePkg update and OvmfPkg update.
> >
> > code: https://github.com/sunceping/edk2/tree/handleRetryMapGPA.v4
> >
> > Cc: Liming Gao 
> > Cc: Michael D Kinney 
> > Cc: Erdem Aktas 
> > Cc: James Bottomley 
> > Cc: Min Xu 
> > Cc: Tom Lendacky 
> > Cc: Michael Roth 
> > Cc: Jiewen Yao 
> > Acked-by: Gerd Hoffmann 
> > Signed-off-by: Ceping Sun 
> >
> > Ceping Sun (3):
> >   MdePkg/BaseLib: Update TdVmcall to always output the value in R11
> >   MdePkg/Tdx.h: Add TDVMCALL_STATUS_RETRY
> >   OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA
> >
> >  MdePkg/Include/IndustryStandard/Tdx.h |  2 +
> >  MdePkg/Library/BaseLib/X64/TdVmcall.nasm  |  4 +-
> >  .../BaseMemEncryptTdxLib/MemoryEncryption.c   | 41 ++-
> >  3 files changed, 43 insertions(+), 4 deletions(-)
> >
> > --
> > 2.34.1
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110913): https://edk2.groups.io/g/devel/message/110913
Mute This Topic: https://groups.io/mt/102461779/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V4 0/3] OvmfPkg: Update TdVmCall to handle the retry for MapGPA

[Yao, Jiewen]

All: Reviewed-by: Jiewen Yao 


> -Original Message-
> From: Sun, CepingX 
> Sent: Wednesday, November 8, 2023 7:38 PM
> To: devel@edk2.groups.io
> Cc: Sun, CepingX ; Gao, Liming
> ; Kinney, Michael D ;
> Aktas, Erdem ; James Bottomley
> ; Xu, Min M ; Tom Lendacky
> ; Michael Roth ; Yao,
> Jiewen ; Gerd Hoffmann 
> Subject: [PATCH V4 0/3] OvmfPkg: Update TdVmCall to handle the retry for
> MapGPA
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4572
> 
> According to section 3.2 of the [GHCI] spec, if the result is
> "TDG.VP.VMCALL_RETRY" for TDG.VP.VMCALL.MapGPA, TD must retry the
> mapping for the pages in the region starting at the GPA specified in r11.
> 
> Currently, TDVF does not properly handle the retry results of MapGPA.
> For this, TDVF should update the TdVmCall to return the value in R11
> and must retry the mapping for the pages by the value.
> 
> How to verify the retry for MapGPA in TDVF:
> Note: Since the range size of MapGPA in QEMU is limited to 64MB and
> TDVF always maps 1.5GB( 2GB~3.5GB) MMIO to shared-memory for TD guest,
> the retry action is triggered always.
> Pre-Config:
> QEMU:
> https://github.com/intel/qemu-tdx/tree/tdx-qemu-upstream | tag: tdx-qemu-
> upstream-2023.10.20-v8.1.0
> KERNEL:
> https://github.com/intel/tdx/tree/kvm-upstream-2023.10.16-v6.6-rc2
> 
> Step:
> Boot with TD guest and check the log with TdVmcall(MAPGPA), as below:
> TdxDxe:SetMemorySharedOrPrivate: Cr3Base=0x0 Physical=0x8000
> Length=0x6000 Mode=Shared
> SetOrClearSharedBit: TdVmcall(MAPGPA) Retry PhysicalAddress is
> 88000, MapGpaRetryaddr is 88400
> 
> Reference:
> [GHCI]: TDX Guest-Host-Communication Interface v1.0
> https://cdrdv2.intel.com/v1/dl/getContent/726790
> 
> v2 changes:
>   - Update the code based on the comments of v1 reviewer
>   - Update TdVmcall to instead of the extra API file
> 
> v3 changes:
>   - Move the definition of TDVMCALL_STATUS_RETRY to Tdx.h
> 
> v4 changes:
>   - Split the patch to MdePkg update and OvmfPkg update.
> 
> code: https://github.com/sunceping/edk2/tree/handleRetryMapGPA.v4
> 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Cc: Michael Roth 
> Cc: Jiewen Yao 
> Acked-by: Gerd Hoffmann 
> Signed-off-by: Ceping Sun 
> 
> Ceping Sun (3):
>   MdePkg/BaseLib: Update TdVmcall to always output the value in R11
>   MdePkg/Tdx.h: Add TDVMCALL_STATUS_RETRY
>   OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA
> 
>  MdePkg/Include/IndustryStandard/Tdx.h |  2 +
>  MdePkg/Library/BaseLib/X64/TdVmcall.nasm  |  4 +-
>  .../BaseMemEncryptTdxLib/MemoryEncryption.c   | 41 ++-
>  3 files changed, 43 insertions(+), 4 deletions(-)
> 
> --
> 2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110912): https://edk2.groups.io/g/devel/message/110912
Mute This Topic: https://groups.io/mt/102461779/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V3 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA

[Yao, Jiewen]

Hey Ceping
Please don't change two packages in one patch, because it is hard to let the 
corresponding maintainer to review and give R-B, if he/she only reviews part of 
them.

The patch should be split to MdePkg update and OvmfPkg update.

Thank you
Yao, Jiewen


> -Original Message-
> From: Sun, CepingX 
> Sent: Wednesday, November 8, 2023 4:32 PM
> To: devel@edk2.groups.io
> Cc: Sun, CepingX ; Aktas, Erdem
> ; James Bottomley ; Yao,
> Jiewen ; Xu, Min M ; Tom
> Lendacky ; Michael Roth
> ; Gerd Hoffmann 
> Subject: [PATCH V3 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of
> MapGPA
> 
> From: Ceping Sun 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4572
> 
> According to section 3.2 of the [GHCI] document, if the return status
> of MapGPA is "TDG.VP.VMCALL_RETRY", TD must retry this operation for the
> pages in the region starting at the GPA specified in R11.
> 
> In this patch, when a retry state is detected, TDVF needs to retry the
> mapping with the specified address from the output results of TdVmCall.
> 
> Reference:
> [GHCI]: TDX Guest-Host-Communication Interface v1.0
> https://cdrdv2.intel.com/v1/dl/getContent/726790
> 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Cc: Michael Roth 
> Cc: Gerd Hoffmann 
> Signed-off-by: Ceping Sun 
> ---
>  MdePkg/Include/IndustryStandard/Tdx.h |  2 +
>  .../BaseMemEncryptTdxLib/MemoryEncryption.c   | 41 ++-
>  2 files changed, 42 insertions(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Include/IndustryStandard/Tdx.h
> b/MdePkg/Include/IndustryStandard/Tdx.h
> index 81df1361842b..2662761883e5 100644
> --- a/MdePkg/Include/IndustryStandard/Tdx.h
> +++ b/MdePkg/Include/IndustryStandard/Tdx.h
> @@ -103,6 +103,8 @@
>  #define TDVMCALL_REPORT_FATAL_ERR0x10003
>  #define TDVMCALL_SETUP_EVENT_NOTIFY  0x10004
> 
> +#define TDVMCALL_STATUS_RETRY  0x1
> +
>  #pragma pack(1)
>  typedef struct {
>UINT64Data[6];
> diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
> b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
> index a01dc98852b8..a71b1efbca7a 100644
> --- a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
> +++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
> @@ -38,6 +38,8 @@ typedef enum {
> 
>  STATIC PAGE_TABLE_POOL  *mPageTablePool = NULL;
> 
> +#define MAX_RETRIES_PER_PAGE  3
> +
>  /**
>Returns boolean to indicate whether to indicate which, if any, memory
> encryption is enabled
> 
> @@ -527,6 +529,13 @@ SetOrClearSharedBit (
>EFI_STATUSStatus;
>EDKII_MEMORY_ACCEPT_PROTOCOL  *MemoryAcceptProtocol;
> 
> +  UINT64  MapGpaRetryAddr;
> +  UINT32  RetryCount;
> +  UINT64  EndAddress;
> +
> +  MapGpaRetryAddr = 0;
> +  RetryCount  = 0;
> +
>AddressEncMask = GetMemEncryptionAddressMask ();
> 
>//
> @@ -540,7 +549,37 @@ SetOrClearSharedBit (
>  PhysicalAddress   &= ~AddressEncMask;
>}
> 
> -  TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0,
> NULL);
> +  EndAddress = PhysicalAddress + Length;
> +  while (RetryCount < MAX_RETRIES_PER_PAGE) {
> +TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0,
> );
> +if (TdStatus != TDVMCALL_STATUS_RETRY) {
> +  break;
> +}
> +
> +DEBUG ((DEBUG_VERBOSE, "%a: TdVmcall(MAPGPA) Retry PhysicalAddress
> is %llx, MapGpaRetryAddr is %llx\n", __func__, PhysicalAddress,
> MapGpaRetryAddr));
> +
> +if ((MapGpaRetryAddr < PhysicalAddress) || (MapGpaRetryAddr >=
> EndAddress)) {
> +  DEBUG ((
> +DEBUG_ERROR,
> +"%a: TdVmcall(MAPGPA) failed with MapGpaRetryAddr(%llx) less than
> PhysicalAddress(%llx) or more than or equal to EndAddress(%llx) \n",
> +__func__,
> +MapGpaRetryAddr,
> +PhysicalAddress,
> +EndAddress
> +));
> +  break;
> +}
> +
> +if (MapGpaRetryAddr == PhysicalAddress) {
> +  RetryCount++;
> +  continue;
> +}
> +
> +PhysicalAddress = MapGpaRetryAddr;
> +Length  = EndAddress - PhysicalAddress;
> +RetryCount  = 0;
> +  }
> +
>if (TdStatus != 0) {
>  DEBUG ((DEBUG_ERROR, "%a: TdVmcall(MAPGPA) failed with %llx\n",
> __func__, TdStatus));
>  ASSERT (FALSE);
> --
> 2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110907): https://edk2.groups.io/g/devel/message/110907
Mute This Topic: https://groups.io/mt/102460273/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA

[Yao, Jiewen]

I think the macro definition (#define TDVMCALL_STATUS_RETRY  0x1) should be in 
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/IndustryStandard/Tdx.h,
 together with other TDX definition.

Thank you
Yao, Jiewen

> -Original Message-
> From: Sun, CepingX 
> Sent: Thursday, November 2, 2023 5:10 PM
> To: devel@edk2.groups.io
> Cc: Sun, CepingX ; Aktas, Erdem
> ; James Bottomley ; Yao,
> Jiewen ; Xu, Min M ; Tom
> Lendacky ; Michael Roth
> ; Gerd Hoffmann 
> Subject: [PATCH V2 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of
> MapGPA
> 
> From: Ceping Sun 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4572
> 
> According to section 3.2 of the [GHCI] document, if the return status
> of MapGPA is "TDG.VP.VMCALL_RETRY", TD must retry this operation for the
> pages in the region starting at the GPA specified in R11.
> 
> In this patch, when a retry state is detected, TDVF needs to retry the
> mapping with the specified address from the output results of TdVmCall.
> 
> Reference:
> [GHCI]: TDX Guest-Host-Communication Interface v1.0
> https://cdrdv2.intel.com/v1/dl/getContent/726790
> 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Cc: Michael Roth 
> Cc: Gerd Hoffmann 
> Signed-off-by: Ceping Sun 
> ---
>  .../BaseMemEncryptTdxLib/MemoryEncryption.c   | 43 ++-
>  1 file changed, 42 insertions(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
> b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
> index a01dc98852b8..b9de699a6489 100644
> --- a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
> +++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
> @@ -38,6 +38,10 @@ typedef enum {
> 
>  STATIC PAGE_TABLE_POOL  *mPageTablePool = NULL;
> 
> +#define TDVMCALL_STATUS_RETRY  0x1
> +
> +#define MAX_RETRIES_PER_PAGE  3
> +
>  /**
>Returns boolean to indicate whether to indicate which, if any, memory
> encryption is enabled
> 
> @@ -527,6 +531,13 @@ SetOrClearSharedBit (
>EFI_STATUSStatus;
>EDKII_MEMORY_ACCEPT_PROTOCOL  *MemoryAcceptProtocol;
> 
> +  UINT64  MapGpaRetryAddr;
> +  UINT32  RetryCount;
> +  UINT64  EndAddress;
> +
> +  MapGpaRetryAddr = 0;
> +  RetryCount  = 0;
> +
>AddressEncMask = GetMemEncryptionAddressMask ();
> 
>//
> @@ -540,7 +551,37 @@ SetOrClearSharedBit (
>  PhysicalAddress   &= ~AddressEncMask;
>}
> 
> -  TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0,
> NULL);
> +  EndAddress = PhysicalAddress + Length;
> +  while (RetryCount < MAX_RETRIES_PER_PAGE) {
> +TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0,
> );
> +if (TdStatus != TDVMCALL_STATUS_RETRY) {
> +  break;
> +}
> +
> +DEBUG ((DEBUG_VERBOSE, "%a: TdVmcall(MAPGPA) Retry PhysicalAddress
> is %llx, MapGpaRetryAddr is %llx\n", __func__, PhysicalAddress,
> MapGpaRetryAddr));
> +
> +if ((MapGpaRetryAddr < PhysicalAddress) || (MapGpaRetryAddr >=
> EndAddress)) {
> +  DEBUG ((
> +DEBUG_ERROR,
> +"%a: TdVmcall(MAPGPA) failed with MapGpaRetryAddr(%llx) less than
> PhysicalAddress(%llx) or more than or equal to EndAddress(%llx) \n",
> +__func__,
> +MapGpaRetryAddr,
> +PhysicalAddress,
> +EndAddress
> +));
> +  break;
> +}
> +
> +if (MapGpaRetryAddr == PhysicalAddress) {
> +  RetryCount++;
> +  continue;
> +}
> +
> +PhysicalAddress = MapGpaRetryAddr;
> +Length  = EndAddress - PhysicalAddress;
> +RetryCount  = 0;
> +  }
> +
>if (TdStatus != 0) {
>  DEBUG ((DEBUG_ERROR, "%a: TdVmcall(MAPGPA) failed with %llx\n",
> __func__, TdStatus));
>  ASSERT (FALSE);
> --
> 2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110895): https://edk2.groups.io/g/devel/message/110895
Mute This Topic: https://groups.io/mt/102337977/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 1/2] MdePkg/BaseLib: Update TdVmcall to always output the value in R11

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Sun, CepingX 
> Sent: Thursday, November 2, 2023 5:10 PM
> To: devel@edk2.groups.io
> Cc: Sun, CepingX ; Gao, Liming
> ; Kinney, Michael D ;
> Aktas, Erdem ; James Bottomley
> ; Yao, Jiewen ; Xu, Min M
> ; Tom Lendacky ; Michael
> Roth ; Gerd Hoffmann 
> Subject: [PATCH V2 1/2] MdePkg/BaseLib: Update TdVmcall to always output the
> value in R11
> 
> From: Ceping Sun 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4572
> 
> According to section 3.2 of the [GHCI] spec, if the return status
> of MapGPA is "TDG.VP.VMCALL_RETRY", TD must retry this operation
> for the pages in the region starting at the GPA specified in R11.
> 
> Currently, TDVF has not handled the retry results and always clears
> the R11 on unsuccessful return status. For this, the TdVmcall needs
> to output the value of R11 on unsuccessful return status to handle
> the retry results of MapGPA.
> 
> Reference:
> [GHCI]: TDX Guest-Host-Communication Interface v1.0
> https://cdrdv2.intel.com/v1/dl/getContent/726790
> 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Cc: Michael Roth 
> Cc: Gerd Hoffmann 
> Signed-off-by: Ceping Sun 
> ---
>  MdePkg/Library/BaseLib/X64/TdVmcall.nasm | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/MdePkg/Library/BaseLib/X64/TdVmcall.nasm
> b/MdePkg/Library/BaseLib/X64/TdVmcall.nasm
> index 5ecc10b17193..8dd9bfcbfa14 100644
> --- a/MdePkg/Library/BaseLib/X64/TdVmcall.nasm
> +++ b/MdePkg/Library/BaseLib/X64/TdVmcall.nasm
> @@ -133,9 +133,7 @@ ASM_PFX(TdVmCall):
> test r9, r9
> jz .no_return_data
> 
> -   ; On success, propagate TDVMCALL output value to output param
> -   test rax, rax
> -   jnz .no_return_data
> +   ; Propagate TDVMCALL output value to output param
> mov [r9], r11
>  .no_return_data:
> tdcall_regs_postamble
> --
> 2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110894): https://edk2.groups.io/g/devel/message/110894
Mute This Topic: https://groups.io/mt/102337975/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Remove unused OvmfPkg Confidential Computing path

[Yao, Jiewen]

Acked-by: Jiewen Yao 

> -Original Message-
> From: Kinney, Michael D 
> Sent: Wednesday, November 8, 2023 11:50 AM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Leif Lindholm ;
> Aktas, Erdem ; Yao, Jiewen ;
> Xu, Min M ; Tom Lendacky
> ; Michael Roth 
> Subject: [Patch 1/1] Maintainers.txt: Remove unused OvmfPkg Confidential
> Computing path
> 
> The following commit removed PlatformBootManagerLibGub from
> OvmfPkg.  Update Maintainers.txt to remove reference to
> deleted directory.
> 
> https://github.com/tianocore/edk2/commit/6fb2760dc8939b16a906b8e6bb2247
> 64907168f3
> 
> Cc: Andrew Fish 
> Cc: Leif Lindholm 
> Cc: Erdem Aktas 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Cc: Michael Roth 
> Signed-off-by: Michael D Kinney 
> ---
>  Maintainers.txt | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index cfbde42f2e04..7c0b4cb58cfd 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -497,7 +497,6 @@ F:
> OvmfPkg/Include/Guid/ConfidentialComputingSecret.h
>  F: OvmfPkg/Include/Library/MemEncryptSevLib.h
>  F: OvmfPkg/IoMmuDxe/CcIoMmu.*
>  F: OvmfPkg/Library/BaseMemEncryptSevLib/
> -F: OvmfPkg/Library/PlatformBootManagerLibGrub/
>  F: OvmfPkg/Library/CcExitLib/
>  F: OvmfPkg/PlatformPei/AmdSev.c
>  F: OvmfPkg/ResetVector/
> --
> 2.40.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110891): https://edk2.groups.io/g/devel/message/110891
Mute This Topic: https://groups.io/mt/102458044/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 0/7] CryptoPkg: Enable Openssl native instruction support for AARCH64

[Yao, Jiewen]

Hi Leif/Ard/Sami
I would expect ARM/AARCH64 maintainers to review the ARM specific files, even 
they are in CryptoPkg. Please help on that.

Thank you
Yao, Jiewen


> -Original Message-
> From: Li, Yi1 
> Sent: Tuesday, November 7, 2023 10:39 AM
> To: Pierre Gondois ; devel@edk2.groups.io
> Cc: Yao, Jiewen ; Lu, Xiaoyu1 ;
> Jiang, Guomin ; Leif Lindholm
> ; Ard Biesheuvel ;
> Sami Mujawar ; Gerd Hoffmann
> 
> Subject: RE: [PATCH v1 0/7] CryptoPkg: Enable Openssl native instruction 
> support
> for AARCH64
> 
> Hi Pierre,
> 
> Could you share what tests you did and the test results?
> 
> Regards,
> Yi
> 
> -Original Message-
> From: Pierre Gondois 
> Sent: Thursday, November 2, 2023 9:54 PM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen ; Li, Yi1 ; Lu, 
> Xiaoyu1
> ; Jiang, Guomin ; Leif Lindholm
> ; Ard Biesheuvel ;
> Sami Mujawar ; Gerd Hoffmann
> 
> Subject: [PATCH v1 0/7] CryptoPkg: Enable Openssl native instruction support 
> for
> AARCH64
> 
> Various OpensslLib implementations are available in edk2. The
> OpensslLibAccel.inf and OpensslLibFullAccel.inf ones use architecture specific
> instructions, e.g. AESE, PMULL, SHA256H, ..., allowing to improve speed.
> 
> Enable support for Aarch64's native instructions:
> - Add ArmReadCntPctReg() and ArmReadIdAA64Isar0Reg() to
>   Aarch64's BaseLib.
> - Generate Aarch64's specific Openssl functions.
> - Add a OpensslStub/AArch64Cap.c file to allow Openssl
>   to probe Aarch64 native instruction support.
> 
> This patch-set only enable support for GCC for now (MSFT support not added).
> 
> Pierre Gondois (7):
>   MdePkg/BaseLib: AARCH64: Add ArmReadCntPctReg()
>   MdePkg/BaseLib: AARCH64: Add ArmReadIdAA64Isar0Reg()
>   MdePkg/BaseRngLib: Prefer ArmReadIdAA64Isar0Reg() over
> ArmReadIdIsar0()
>   CryptoPkg/OpensslLib: Add native instruction support for AARCH64
>   CryptoPkg/OpensslLib: Generate files for AARCH64 native support
>   CryptoPkg/OpensslLib: Add AArch64Cap for arch specific hooks
>   CryptoPkg: Enable Openssl Accel builds for AARCH64
> 
>  CryptoPkg/CryptoPkg.dsc   |   23 +-
>  .../AARCH64-GCC/crypto/aes/aesv8-armx.S   | 3180 
>  .../AARCH64-GCC/crypto/aes/vpaes-armv8.S  | 1196 +++
>  .../AARCH64-GCC/crypto/arm64cpuid.S   |  129 +
>  .../AARCH64-GCC/crypto/bn/armv8-mont.S| 2124 ++
>  .../crypto/ec/ecp_nistz256-armv8.S| 4242 +++
>  .../crypto/modes/aes-gcm-armv8_64.S   | 6389 +
>  .../AARCH64-GCC/crypto/modes/ghashv8-armx.S   |  552 ++
>  .../AARCH64-GCC/crypto/sha/keccak1600-armv8.S | 1009 +++
>  .../AARCH64-GCC/crypto/sha/sha1-armv8.S   | 1211 
>  .../AARCH64-GCC/crypto/sha/sha256-armv8.S | 2051 ++
>  .../AARCH64-GCC/crypto/sha/sha512-armv8.S | 1606 +
>  .../Library/OpensslLib/OpensslLibAccel.inf|  642 +-
>  .../OpensslLib/OpensslLibFullAccel.inf|  691 +-
>  .../OpensslLib/OpensslStub/AArch64Cap.c   |  107 +
>  CryptoPkg/Library/OpensslLib/UefiAsm.conf |6 +
>  CryptoPkg/Library/OpensslLib/configure.py |5 +-
>  CryptoPkg/Readme.md   |   14 +-
>  MdePkg/Include/Library/BaseLib.h  |   86 +
>  .../BaseLib/AArch64/ArmReadCntPctReg.S|   30 +
>  .../BaseLib/AArch64/ArmReadCntPctReg.asm  |   30 +
>  .../AArch64/ArmReadIdAA64Isar0Reg.S}  |   10 +-
>  .../AArch64/ArmReadIdAA64Isar0Reg.asm}|   10 +-
>  MdePkg/Library/BaseLib/BaseLib.inf|6 +-
>  MdePkg/Library/BaseRngLib/AArch64/ArmRng.h|   12 -
>  MdePkg/Library/BaseRngLib/AArch64/Rndr.c  |   14 +-
>  MdePkg/Library/BaseRngLib/BaseRngLib.inf  |2 -
>  27 files changed, 25320 insertions(+), 57 deletions(-)  create mode 100644
> CryptoPkg/Library/OpensslLib/OpensslGen/AARCH64-GCC/crypto/aes/aesv8-
> armx.S
>  create mode 100644 CryptoPkg/Library/OpensslLib/OpensslGen/AARCH64-
> GCC/crypto/aes/vpaes-armv8.S
>  create mode 100644 CryptoPkg/Library/OpensslLib/OpensslGen/AARCH64-
> GCC/crypto/arm64cpuid.S
>  create mode 100644 CryptoPkg/Library/OpensslLib/OpensslGen/AARCH64-
> GCC/crypto/bn/armv8-mont.S
>  create mode 100644 CryptoPkg/Library/OpensslLib/OpensslGen/AARCH64-
> GCC/crypto/ec/ecp_nistz256-armv8.S
>  create mode 100644 CryptoPkg/Library/OpensslLib/OpensslGen/AARCH64-
> GCC/crypto/modes/aes-gcm-armv8_64.S
>  create mode 100644 CryptoPkg/Library/OpensslLib/OpensslGen/AARCH64-
> GCC/crypto/modes/ghashv8-armx.S
>  create mode 100644 CryptoPkg/Library/OpensslLib/OpensslGen/AARCH64-
> GCC/crypto/sha/keccak1600-armv8.S
>  create mode 100644 CryptoPkg/Library/OpensslLib/OpensslGen/AARCH64-
> GCC/crypto/sha/sha1-armv8.S
>  create mode 100644 

Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members

[Yao, Jiewen]

> I'll re-raise my point about relaxing the contribution conditions too --
> given this state, I'd propose a "merge by default" approach, with a
> reasonable timeout.

[Jiewen] Yes. I agree this approach.
A reasonable timeout seems enough to allow people to think and feedback.



Also, I would like to propose another the contribution condition relax.

Currently, our agreed condition to merge is:
1) Reviewed-by from Maintainer.
2) Acked-by from Maintainer + Reviewed-by from Reviewer

I propose to change the second condition:
2) Acked-by from Maintainer + Reviewed-by from anyone who can be trusted by the 
maintainer.


That is based upon the current situation - anyone can be a reviewer just 
because they want to be CCed and has no expectation to review the code.
Restricting R-B from a reviewer does not make sense to me.

Thank you
Yao, Jiewen



> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
> Sent: Sunday, October 29, 2023 9:30 PM
> To: devel@edk2.groups.io; pedro.falc...@gmail.com; Kinney, Michael D
> 
> Cc: Andrew Fish ; Leif Lindholm ;
> Warkentin, Andrei ; West, Catharine
> ; Bi, Dandan ; Daniel
> Schaefer ; David Woodhouse ;
> De, Debkumar ; Dong, Eric ;
> Jiang, Guomin ; Wu, Hao A ;
> James Bottomley ; Wang, Jian J ;
> Justen, Jordan L ; Julien Grall ;
> Peter Grehan ; Zhang, Qi1 ; Ng,
> Ray Han Lim ; Stefan Berger
> ; Hou, Wenxing ; Lu, Xiaoyu1
> 
> Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active
> community members
> 
> On 10/29/23 03:16, Pedro Falcato wrote:
> > On Sat, Oct 28, 2023 at 8:23 PM Michael D Kinney
> >  wrote:
> >>
> >> Over the past few months, all the of the Maintainers and
> >> Reviewers listed in Maintainers.txt have been contacted to make
> >> sure Maintainers.txt accurately represents the TianoCore
> >> community members that are actively participating in their
> >> roles.  Based on specific feedback, bounced emails, and no
> >> responses, updates have been made.
> >>
> >> * RISCV64: Daniel Schaefer replaced with Andrei Warkentin
> >> * ArmVirtPkg Xen has no remaining reviewers and review
> >>   responsibility defaults to ArmVirtPkg Maintainers/Reviewers.
> >> * ACPI modules related to S3 has no remaining reviewers and
> >>   review responsibility defaults to MdeModulePkg Maintainers/
> >>   Reviewers.
> >> * OVMF CSM modules has no remaining reviewers and review
> >>   responsibility defaults to OvmfPkg Maintainers/Reviewers.
> >> * Bounce: Chan Laura 
> >> * Many smaller updates removing individuals that are no
> >>   longer involved or have replacement coverage.
> >
> > Mike,
> >
> > Thank you so much for doing this thankless task. Some comments:
> >
> >> diff --git a/Maintainers.txt b/Maintainers.txt
> >> index 3f40cdeb5554..2b03ccbe54aa 100644
> >> --- a/Maintainers.txt
> >> +++ b/Maintainers.txt
> >> @@ -93,7 +93,7 @@ M: Sami Mujawar 
> [samimujawar]
> >>  RISCV64
> >>  F: */RiscV64/
> >>  M: Sunil V L  [vlsunil]
> >> -R: Daniel Schaefer  [JohnAZoidberg]
> >> +R: Andrei Warkentin  [andreiw]
> >>
> >>  LOONGARCH64
> >>  F: */LoongArch64/
> >> @@ -157,16 +157,6 @@ R: Leif Lindholm 
> [leiflindholm]
> >>  R: Sami Mujawar  [samimujawar]
> >>  R: Gerd Hoffmann  [kraxel]
> >>
> >> -ArmVirtPkg: modules used on Xen
> >> -F: ArmVirtPkg/ArmVirtXen.*
> >> -F: ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/
> >> -F: ArmVirtPkg/Library/XenVirtMemInfoLib/
> >> -F: ArmVirtPkg/PrePi/
> >> -F: ArmVirtPkg/XenAcpiPlatformDxe/
> >> -F: ArmVirtPkg/XenPlatformHasAcpiDtDxe/
> >> -F: ArmVirtPkg/XenioFdtDxe/
> >> -R: Julien Grall  [jgrall]
> >
> > ArmVirtPkg Xen modules seize to have a dedicated maintainer. Can the
> > generic ArmVirtPkg maintainers handle *more code* (particularly,
> > functionality that's not trivial to test, unless you actively use
> > Xen)?
> 
> An alternative to removing this entire section is to replace Julien's
> line with the following status line:
> 
> S: Orphan
> 
> The definition in Maintainers.txt is:
> 
>  Orphan: No current maintainer [but maybe you could take the
>  role as you write your new code].
> 
> I think this might be clearer for all three of: contributors, consumers,
> and existent maintainers.
> 
> - Contributors: An ArmVirtPkg maintainer may techincally merge your
> code, but you won't get substantive feedback
> 
> - Consumers: you can build and run this

Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members

[Yao, Jiewen]

Thanks Mike. I am reading the WIKI page.


> and/or provides testing or regression testing for the Package (or some 
> modules thereof), in certain platforms and environments.

[Jiewen] Are we expecting Reviewer to provide testing or regression testing for 
the package?
Is that what the reviewer *commits* to do?
For example, Maintainer may ask the reviewer to do some testing, right?


> Reviewer is responsible for timely responses on emails addressed to them 
> (preferably less than calendar week).

[Jiewen]
Is that what the reviewer *commits* to do?
For example, Maintainer may ask the reviewer to provide feedback, right?


Those are more than just CCed.


Thank you
Yao, Jiewen


> -Original Message-
> From: Kinney, Michael D 
> Sent: Monday, October 30, 2023 1:23 AM
> To: Yao, Jiewen ; j...@linux.ibm.com; Laszlo Ersek
> ; devel@edk2.groups.io; pedro.falc...@gmail.com
> Cc: Andrew Fish ; Leif Lindholm ;
> Warkentin, Andrei ; West, Catharine
> ; Bi, Dandan ; Daniel
> Schaefer ; David Woodhouse ;
> De, Debkumar ; Dong, Eric ;
> Jiang, Guomin ; Wu, Hao A ;
> Wang, Jian J ; Justen, Jordan L
> ; Julien Grall ; Peter Grehan
> ; Zhang, Qi1 ; Ng, Ray Han Lim
> ; Stefan Berger ; Hou,
> Wenxing ; Lu, Xiaoyu1 ;
> Kinney, Michael D 
> Subject: RE: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active
> community members
> 
> This is the Wiki page where TianoCore documents the TianoCore community
> member roles.
> 
> https://github.com/tianocore/tianocore.github.io/wiki/TianoCore-Who-we-are
> 
> We can update/edit as needed to accurately reflect what all the Maintainers
> and Reviewers agree are their roles and responsibilities as assigned in
> Maintainers.txt.
> 
> Thanks,
> 
> Mike
> 
> 
> > -Original Message-
> > From: Yao, Jiewen 
> > Sent: Sunday, October 29, 2023 9:26 AM
> > To: j...@linux.ibm.com; Laszlo Ersek ;
> > devel@edk2.groups.io; pedro.falc...@gmail.com; Kinney, Michael D
> > 
> > Cc: Andrew Fish ; Leif Lindholm
> > ; Warkentin, Andrei
> > ; West, Catharine
> > ; Bi, Dandan ; Daniel
> > Schaefer ; David Woodhouse
> > ; De, Debkumar ; Dong,
> > Eric ; Jiang, Guomin ;
> > Wu, Hao A ; Wang, Jian J ;
> > Justen, Jordan L ; Julien Grall
> > ; Peter Grehan ; Zhang, Qi1
> > ; Ng, Ray Han Lim ;
> > Stefan Berger ; Hou, Wenxing
> > ; Lu, Xiaoyu1 
> > Subject: RE: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on
> > active community members
> >
> > OK. Maintainer should do code review. I have no doubt on that.
> >
> > My confusion is about "reviewer" role. What is criteria and what is
> > responsibility?
> >
> > Are you saying that "reviewer" just means that someone raised the hand
> > and said: "I want to be notified", and there is no expectation that
> > he/she would review the patch?
> >
> > I would like to understand more on how that works and what that means.
> > Would you please give a URL for the reviewer definition in Linux
> > Kernel?
> >
> > Thank you
> > Yao, Jiewen
> >
> >
> >
> > > -Original Message-
> > > From: James Bottomley 
> > > Sent: Monday, October 30, 2023 12:02 AM
> > > To: Yao, Jiewen ; Laszlo Ersek
> > ;
> > > devel@edk2.groups.io; pedro.falc...@gmail.com; Kinney, Michael D
> > > 
> > > Cc: Andrew Fish ; Leif Lindholm
> > ;
> > > Warkentin, Andrei ; West, Catharine
> > > ; Bi, Dandan ; Daniel
> > > Schaefer ; David Woodhouse
> > ;
> > > De, Debkumar ; Dong, Eric
> > ;
> > > Jiang, Guomin ; Wu, Hao A
> > ;
> > > Wang, Jian J ; Justen, Jordan L
> > > ; Julien Grall ; Peter
> > Grehan
> > > ; Zhang, Qi1 ; Ng, Ray Han
> > Lim
> > > ; Stefan Berger ;
> > Hou,
> > > Wenxing ; Lu, Xiaoyu1 
> > > Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based
> > on active
> > > community members
> > >
> > > On Sun, 2023-10-29 at 15:42 +, Yao, Jiewen wrote:
> > > > > I'd say that's pretty close. A reviewer role is a request for
> > > > > keeping
> > > > > the reviewer in the loop.
> > > >
> > > > [Jiewen] I am disappointed on that.
> > > > To me, that is NOT a real reviewer. See below description on what
> > is
> > > > "code review".
> > > > https://google.github.io/eng-practices/review/
> > > > https://about.gitlab.com/topics/version-control/what-is-code-
> > review/
> > >
> >

Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members

[Yao, Jiewen]

OK. Maintainer should do code review. I have no doubt on that.

My confusion is about "reviewer" role. What is criteria and what is 
responsibility?

Are you saying that "reviewer" just means that someone raised the hand and 
said: "I want to be notified", and there is no expectation that he/she would 
review the patch?

I would like to understand more on how that works and what that means.
Would you please give a URL for the reviewer definition in Linux Kernel?

Thank you
Yao, Jiewen



> -Original Message-
> From: James Bottomley 
> Sent: Monday, October 30, 2023 12:02 AM
> To: Yao, Jiewen ; Laszlo Ersek ;
> devel@edk2.groups.io; pedro.falc...@gmail.com; Kinney, Michael D
> 
> Cc: Andrew Fish ; Leif Lindholm ;
> Warkentin, Andrei ; West, Catharine
> ; Bi, Dandan ; Daniel
> Schaefer ; David Woodhouse ;
> De, Debkumar ; Dong, Eric ;
> Jiang, Guomin ; Wu, Hao A ;
> Wang, Jian J ; Justen, Jordan L
> ; Julien Grall ; Peter Grehan
> ; Zhang, Qi1 ; Ng, Ray Han Lim
> ; Stefan Berger ; Hou,
> Wenxing ; Lu, Xiaoyu1 
> Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active
> community members
> 
> On Sun, 2023-10-29 at 15:42 +, Yao, Jiewen wrote:
> > > I'd say that's pretty close. A reviewer role is a request for
> > > keeping
> > > the reviewer in the loop.
> >
> > [Jiewen] I am disappointed on that.
> > To me, that is NOT a real reviewer. See below description on what is
> > "code review".
> > https://google.github.io/eng-practices/review/
> > https://about.gitlab.com/topics/version-control/what-is-code-review/
> 
> Well, that's what someone's view of what a patch review should consist
> of, not what a reviewer's role in MAINTAINERS should be.
> 
> In general, you really don't want to force people to review patches,
> because you'd like a reviewer to be familiar with the area and
> comfortable with the patch.  So are you saying that anyone listed as a
> reviewer in a particular area should be capable of reviewing any patch?
> and further that they should be expected to review every patch?
> Because that's definitely not what the R role in the Linux Kernel would
> mean.
> 
> I know that's not what happened to me in Confidential Computing,
> because I had a very specific area around SEV and SEV-ES secret
> injection and really had no familiarity at all with say the memory
> acceptance patches.
> 
> > Our definition seems more like *a notification receiver*, instead of
> > a real code reviewer. I would say, it is a very misleading
> > definition.
> 
> Actually, I wouldn't, but then I'm more coming from a Linux Kernel
> background.  To us, the reviewer list is simply a list of people git
> blame might not find who might have the expertise to review the patch
> but on whom there would be no expectation that they would review the
> patch.
> 
> James



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110271): https://edk2.groups.io/g/devel/message/110271
Mute This Topic: https://groups.io/mt/102245264/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members

[Yao, Jiewen]

> I'd say that's pretty close. A reviewer role is a request for keeping
> the reviewer in the loop.

[Jiewen] I am disappointed on that.
To me, that is NOT a real reviewer. See below description on what is "code 
review".
https://google.github.io/eng-practices/review/
https://about.gitlab.com/topics/version-control/what-is-code-review/

Our definition seems more like *a notification receiver*, instead of a real 
code reviewer.
I would say, it is a very misleading definition.

Thank you
Yao, Jiewen


> -Original Message-
> From: Laszlo Ersek 
> Sent: Sunday, October 29, 2023 9:48 PM
> To: devel@edk2.groups.io; Yao, Jiewen ;
> pedro.falc...@gmail.com; Kinney, Michael D 
> Cc: Andrew Fish ; Leif Lindholm ;
> Warkentin, Andrei ; West, Catharine
> ; Bi, Dandan ; Daniel
> Schaefer ; David Woodhouse ;
> De, Debkumar ; Dong, Eric ;
> Jiang, Guomin ; Wu, Hao A ;
> James Bottomley ; Wang, Jian J ;
> Justen, Jordan L ; Julien Grall ;
> Peter Grehan ; Zhang, Qi1 ; Ng,
> Ray Han Lim ; Stefan Berger
> ; Hou, Wenxing ; Lu, Xiaoyu1
> 
> Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active
> community members
> 
> On 10/29/23 09:05, Yao, Jiewen wrote:
> > Those are great questions. I also would like to understand:
> >
> > 1) What is definition of "actively participating in their roles"?
> 
> Here are the definitions of Maintainer and Reviewer, from
> "Maintainers.txt":
> 
>   M: Package Maintainer: Cc address for patches and questions. Responsible
>  for reviewing and pushing package changes to source control.
>   R: Package Reviewer: Cc address for patches and questions. Reviewers help
>  maintainers review code, but don't have push access. A designated Package
>  Reviewer is reasonably familiar with the Package (or some modules
>  thereof), and/or provides testing or regression testing for the Package
>  (or some modules thereof), in certain platforms and environments.
> 
> > Is there any enforcement or just volunteer work?
> 
> I see the Maintainer role as a service to the community, with some
> benefits granted in return. The "service" part should be clear. The
> benefit is that you are kept in the loop, and sometimes (when you must)
> you *can* say "no". (According to some seasoned reviewers, the one real
> power of a maintainer -- not to be abused! -- is "saying no".) A
> maintainer that's present helps set the focus, keep regressions out,
> gives advice when needed, and so on.
> 
> Enforcement would be nice (haha), but it never works. You can't force
> people to help, especially if their dayjob instructions oppose their
> upstream community responsibilities. That's fine; in such cases my
> request is always: if you can't help, then at least don't get in the
> way, step down. Don't block people from doing their work by having them
> wait for your feedback.
> 
> So volunteer work is fine, but as soon as the position grows "fangs" (=
> a capacity to make others wait), then it becomes a promise, a
> responsibility.
> 
> >
> > 2) What is role and *responsibility* of Reviewer role? Is it
> > documented somewhere?
> > Per my observation, some assigned reviewers have never reviewed any
> > patch in history or provided valuable feedback. To me, reviewer role
> > seems more like a notification instead of really review something. Is
> > that our purpose?
> 
> I'd say that's pretty close. A reviewer role is a request for keeping
> the reviewer in the loop. Maintainers tend to appreciate that, because a
> long-term reviewer may provide good insights, test results, and so on.
> Trust is super important; a maintainer may push a patch based solely on
> a reviewer's positive feedback, due to the latter's experience.
> 
> > While Laszlo contributed a lots in Tianocore community, he is really a
> > good "reviewer", although he has no such title.
> 
> Thanks for the acknowledgement, I appreciate it!
> 
> I don't like to hoard titles. I'm sure titles are good for one's career,
> but I always see the *promise* (the responsibility) to the community,
> first and foremost, that a title encapsulates. It weighs heavily on me.
> I loathe disappointing people. For me, not to bear a title is better
> than to bear it and not to deliver on it / not to live up to it.
> 
> Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110269): https://edk2.groups.io/g/devel/message/110269
Mute This Topic: https://groups.io/mt/102245264/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members

[Yao, Jiewen]

Those are great questions. I also would like to understand:

1) What is definition of "actively participating in their roles"?
Is there any enforcement or just volunteer work?

2) What is role and *responsibility* of Reviewer role? Is it documented 
somewhere?
Per my observation, some assigned reviewers have never reviewed any patch in 
history or provided valuable feedback. To me, reviewer role seems more like a 
notification instead of really review something. Is that our purpose?
While Laszlo contributed a lots in Tianocore community, he is really a good 
"reviewer", although he has no such title.

Thank you
Yao, Jiewen


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Pedro Falcato
> Sent: Sunday, October 29, 2023 10:17 AM
> To: devel@edk2.groups.io; Kinney, Michael D 
> Cc: Andrew Fish ; Leif Lindholm ;
> Warkentin, Andrei ; West, Catharine
> ; Bi, Dandan ; Daniel
> Schaefer ; David Woodhouse ;
> De, Debkumar ; Dong, Eric ;
> Jiang, Guomin ; Wu, Hao A ;
> James Bottomley ; Wang, Jian J ;
> Justen, Jordan L ; Julien Grall ;
> Peter Grehan ; Zhang, Qi1 ; Ng,
> Ray Han Lim ; Stefan Berger
> ; Hou, Wenxing ; Lu, Xiaoyu1
> 
> Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active
> community members
> 
> On Sat, Oct 28, 2023 at 8:23 PM Michael D Kinney
>  wrote:
> >
> > Over the past few months, all the of the Maintainers and
> > Reviewers listed in Maintainers.txt have been contacted to make
> > sure Maintainers.txt accurately represents the TianoCore
> > community members that are actively participating in their
> > roles.  Based on specific feedback, bounced emails, and no
> > responses, updates have been made.
> >
> > * RISCV64: Daniel Schaefer replaced with Andrei Warkentin
> > * ArmVirtPkg Xen has no remaining reviewers and review
> >   responsibility defaults to ArmVirtPkg Maintainers/Reviewers.
> > * ACPI modules related to S3 has no remaining reviewers and
> >   review responsibility defaults to MdeModulePkg Maintainers/
> >   Reviewers.
> > * OVMF CSM modules has no remaining reviewers and review
> >   responsibility defaults to OvmfPkg Maintainers/Reviewers.
> > * Bounce: Chan Laura 
> > * Many smaller updates removing individuals that are no
> >   longer involved or have replacement coverage.
> 
> Mike,
> 
> Thank you so much for doing this thankless task. Some comments:
> 
> > diff --git a/Maintainers.txt b/Maintainers.txt
> > index 3f40cdeb5554..2b03ccbe54aa 100644
> > --- a/Maintainers.txt
> > +++ b/Maintainers.txt
> > @@ -93,7 +93,7 @@ M: Sami Mujawar 
> [samimujawar]
> >  RISCV64
> >  F: */RiscV64/
> >  M: Sunil V L  [vlsunil]
> > -R: Daniel Schaefer  [JohnAZoidberg]
> > +R: Andrei Warkentin  [andreiw]
> >
> >  LOONGARCH64
> >  F: */LoongArch64/
> > @@ -157,16 +157,6 @@ R: Leif Lindholm 
> [leiflindholm]
> >  R: Sami Mujawar  [samimujawar]
> >  R: Gerd Hoffmann  [kraxel]
> >
> > -ArmVirtPkg: modules used on Xen
> > -F: ArmVirtPkg/ArmVirtXen.*
> > -F: ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/
> > -F: ArmVirtPkg/Library/XenVirtMemInfoLib/
> > -F: ArmVirtPkg/PrePi/
> > -F: ArmVirtPkg/XenAcpiPlatformDxe/
> > -F: ArmVirtPkg/XenPlatformHasAcpiDtDxe/
> > -F: ArmVirtPkg/XenioFdtDxe/
> > -R: Julien Grall  [jgrall]
> 
> ArmVirtPkg Xen modules seize to have a dedicated maintainer. Can the
> generic ArmVirtPkg maintainers handle *more code* (particularly,
> functionality that's not trivial to test, unless you actively use
> Xen)?
> 
> >  BaseTools
> >  F: BaseTools/
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
> > @@ -187,8 +177,7 @@ F: CryptoPkg/
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/CryptoPkg
> >  M: Jiewen Yao  [jyao1]
> >  M: Yi Li  [liyi77]
> > -R: Xiaoyu Lu  [xiaoyuxlu]
> > -R: Guomin Jiang  [guominjia]
> > +R: Wenxing Hou  [Wenxing-hou]
> >
> >  DynamicTablesPkg
> >  F: DynamicTablesPkg/
> > @@ -202,7 +191,6 @@ W:
> https://github.com/tianocore/tianocore.github.io/wiki/EmbeddedPkg
> >  M: Leif Lindholm  [leiflindholm]
> >  M: Ard Biesheuvel  [ardbiesheuvel]
> >  M: Abner Chang  [changab]
> > -R: Daniel Schaefer  [JohnAZoidberg]
> >
> >  EmulatorPkg
> >  F: EmulatorPkg/
> > @@ -228,7 +216,6 @@ F: FmpDevicePkg/
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
> >  M: Liming Gao  [lgao4]
> >  M: Michael D Kinney  [mdkinney]
> > -R: Guomin Jiang  [guominjia]
> >  R: Wei6 Xu  [xuweiintel]
> >
> >  IntelFsp2P

Re: [edk2-devel] [PATCH 0/7] Support Tdx and sev in BaseIoLibIntrinsic and remove BaseIoLibIntrinsicSev

[Yao, Jiewen]

Here is my suggestion:

1) Please perform the test to ensure the functional part is correct.

Without that, how can people know you are doing things right?

2) If you do not run any test, before you send out patch, please call out that 
clearly.
That is important to reminder the maintainer: Don't merge, even if it pass 
review.

Otherwise, once the review passed, the maintainer may merge it.
I don't think that is the intention.



Thank you
Yao, Jiewen
 

> -Original Message-
> From: Tan, Dun 
> Sent: Friday, October 27, 2023 2:32 PM
> To: Yao, Jiewen ; devel@edk2.groups.io
> Subject: RE: [edk2-devel] [PATCH 0/7] Support Tdx and sev in 
> BaseIoLibIntrinsic
> and remove BaseIoLibIntrinsicSev
> 
> Hi Jiewen,
> 
> Currently I'm working on the Tdx test. Since the patch set doesn't change the
> code logic when Tdx or SEV is enabled, so I want to send out the patch as 
> soon as
> possible to see if there is any comments from community.
> 
> I will include AMD SEV reviewer in this patch series. Thanks for reminding.
> 
> Thanks,
> Dun
> 
> -Original Message-
> From: Yao, Jiewen 
> Sent: Friday, October 27, 2023 1:49 PM
> To: devel@edk2.groups.io; Tan, Dun 
> Subject: RE: [edk2-devel] [PATCH 0/7] Support Tdx and sev in 
> BaseIoLibIntrinsic
> and remove BaseIoLibIntrinsicSev
> 
> HI
> Since this impact TDX and SEV, would you please let me know what kind of test
> you have done?
> Have you validated TDX and SEV before you submit the patch? Please describe
> that clearly in your patch description.
> 
> Also please include AMD SEV reviewer in this patch series.
> 
> Thank you
> Yao, Jiewen
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of duntan
> > Sent: Friday, October 27, 2023 1:43 PM
> > To: devel@edk2.groups.io
> > Subject: [edk2-devel] [PATCH 0/7] Support Tdx and sev in
> > BaseIoLibIntrinsic and remove BaseIoLibIntrinsicSev
> >
> > The goal is to have single BaseIoLibIntrinsic instance that can also
> > used for sev and Tdx.
> > In this patch set, string I/O instructions are deleted in IoRead/WriteFifo 
> > API.
> > Then change the source file of BaseIoLibIntrinsic to also support Tdx
> > and sev feature. So BaseIoLibIntrinsicSev and related assembly code can be
> removed.
> >
> > Dun Tan (7):
> >   MdePkg: Create TdxLibNull.inf instance
> >   MdePkg: Add CcProbeLibNull and TdxLibNull implement
> >   MdePkg: simplify IoRead/WriteFifo in IoLibFifo.c
> >   MdePkg:support Tdx and sev in BaseIoLibIntrinsic
> >   OvmfPkg: Add CcProbeLib in PlatformInitLib.inf
> >   OvmfPkg: use BaseIoLibIntrinsic.inf in dsc files
> >   MdePkg:remove BaseIoLibIntrinsicSev related code
> >
> >  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf|  14 
> > ++---
> -
> >  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf |  61
> > --
> > ---
> >  MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm  | 131 
> > -
> ---
> > --
> > 
> > -
> >  MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm   | 293 
> > ---
> ---
> > --
> > 
> > --
> > 
> > ---
> >  MdePkg/Library/BaseIoLibIntrinsic/IoLibFifo.c   |  45
> > +
> >  MdePkg/Library/BaseIoLibIntrinsic/IoLibSev.h| 166 
> > --
> --
> > --
> > 
> > 
> >  MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifo.nasm   | 120 
> > --
> --
> > --
> > 
> > --
> >  MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm| 282 
> > 
> --
> > --
> > 
> > --
> > 
> > ---

Re: [edk2-devel] [PATCH 0/7] Support Tdx and sev in BaseIoLibIntrinsic and remove BaseIoLibIntrinsicSev

[Yao, Jiewen]

HI
Since this impact TDX and SEV, would you please let me know what kind of test 
you have done?
Have you validated TDX and SEV before you submit the patch? Please describe 
that clearly in your patch description.

Also please include AMD SEV reviewer in this patch series.

Thank you
Yao, Jiewen

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of duntan
> Sent: Friday, October 27, 2023 1:43 PM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [PATCH 0/7] Support Tdx and sev in BaseIoLibIntrinsic 
> and
> remove BaseIoLibIntrinsicSev
> 
> The goal is to have single BaseIoLibIntrinsic instance that can also used for 
> sev
> and Tdx.
> In this patch set, string I/O instructions are deleted in IoRead/WriteFifo 
> API.
> Then change the source file of BaseIoLibIntrinsic to also support Tdx and sev
> feature. So BaseIoLibIntrinsicSev and related assembly code can be removed.
> 
> Dun Tan (7):
>   MdePkg: Create TdxLibNull.inf instance
>   MdePkg: Add CcProbeLibNull and TdxLibNull implement
>   MdePkg: simplify IoRead/WriteFifo in IoLibFifo.c
>   MdePkg:support Tdx and sev in BaseIoLibIntrinsic
>   OvmfPkg: Add CcProbeLib in PlatformInitLib.inf
>   OvmfPkg: use BaseIoLibIntrinsic.inf in dsc files
>   MdePkg:remove BaseIoLibIntrinsicSev related code
> 
>  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf|  14 
> ++
>  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf |  61 
> --
> ---
>  MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm  | 131 
> 
> --
> -
>  MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm   | 293 
> --
> --
> --
> ---
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibFifo.c   |  45
> +
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibSev.h| 166 
> 
> --
> 
>  MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifo.nasm   | 120 
> 
> --
> --
>  MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm| 282 
> --
> --
> --
> 
>  MdePkg/Library/TdxLib/TdxLibNull.inf|  21
> +
>  MdePkg/MdeLibs.dsc.inc  |   4 +++-
>  MdePkg/MdePkg.dsc   |   2 +-
>  OvmfPkg/AmdSev/AmdSevX64.dsc|   2 +-
>  OvmfPkg/Bhyve/BhyveX64.dsc  |   2 +-
>  OvmfPkg/CloudHv/CloudHvX64.dsc  |   2 +-
>  OvmfPkg/IntelTdx/IntelTdxX64.dsc|   2 +-
>  OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf |   3 ++-
>  OvmfPkg/Microvm/MicrovmX64.dsc  |   2 +-
>  OvmfPkg/OvmfPkgIa32.dsc |   2 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc  |   2 +-
>  OvmfPkg/OvmfPkgX64.dsc  |   2 +-
>  OvmfPkg/OvmfXen.dsc |   2 +-
>  21 files changed, 83 insertions(+), 1077 deletions(-)
>  delete mode 100644
> MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
>  delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm
>  delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm
>  delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/IoLibSev.h
>  delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifo.nasm
>  delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifoSev.nasm
>  create mode 100644 MdePkg/Library/TdxLib/TdxLibNull.inf
> 
> --
> 2.31.1.windows.1
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110190): https://edk2.groups.io/g/devel/message/110190
Mute This Topic: https://groups.io/mt/102215661/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 04/14] OvmfPkg: Add ImagePropertiesRecordLib Instance

[Yao, Jiewen]

Acked-by: Jiewen Yao 

> -Original Message-
> From: Taylor Beebe 
> Sent: Saturday, August 5, 2023 3:47 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Yao, Jiewen
> ; Justen, Jordan L ; Gerd
> Hoffmann 
> Subject: [PATCH v4 04/14] OvmfPkg: Add ImagePropertiesRecordLib Instance
> 
> From: Taylor Beebe 
> 
> Add an instance of ImagePropertiesRecordLib which will be used by the
> DXE Core.
> 
> Signed-off-by: Taylor Beebe 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Gerd Hoffmann 
> ---
>  OvmfPkg/AmdSev/AmdSevX64.dsc| 1 +
>  OvmfPkg/Bhyve/BhyveX64.dsc  | 1 +
>  OvmfPkg/CloudHv/CloudHvX64.dsc  | 1 +
>  OvmfPkg/IntelTdx/IntelTdxX64.dsc| 1 +
>  OvmfPkg/Microvm/MicrovmX64.dsc  | 1 +
>  OvmfPkg/OvmfPkgIa32.dsc | 1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc  | 1 +
>  OvmfPkg/OvmfPkgX64.dsc  | 1 +
>  OvmfPkg/OvmfXen.dsc | 1 +
>  OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc | 1 +
>  10 files changed, 10 insertions(+)
> 
> diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc
> b/OvmfPkg/AmdSev/AmdSevX64.dsc
> index 2c6ed7c9745f..e8c954a97956 100644
> --- a/OvmfPkg/AmdSev/AmdSevX64.dsc
> +++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
> @@ -171,6 +171,7 @@ [LibraryClasses]
> 
> MemEncryptTdxLib|OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncrypt
> TdxLib.inf
>PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf
> 
> DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf
> +
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/I
> magePropertiesRecordLib.inf
> 
>  !if $(SOURCE_DEBUG_ENABLE) == TRUE
> 
> PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug
> /PeCoffExtraActionLibDebug.inf
> diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
> index 82c60ace1bbd..ee349e105787 100644
> --- a/OvmfPkg/Bhyve/BhyveX64.dsc
> +++ b/OvmfPkg/Bhyve/BhyveX64.dsc
> @@ -173,6 +173,7 @@ [LibraryClasses]
> 
> MemEncryptTdxLib|OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncrypt
> TdxLib.inf
>PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf
> 
> DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf
> +
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/I
> magePropertiesRecordLib.inf
> 
> 
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/Customize
> dDisplayLib.inf
> 
> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib
> .inf
> diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc
> b/OvmfPkg/CloudHv/CloudHvX64.dsc
> index e000deed9e4d..91816a10996f 100644
> --- a/OvmfPkg/CloudHv/CloudHvX64.dsc
> +++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
> @@ -182,6 +182,7 @@ [LibraryClasses]
> 
> MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptS
> evLib.inf
>PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf
> 
> DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf
> +
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/I
> magePropertiesRecordLib.inf
>  !if $(SMM_REQUIRE) == FALSE
>LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
>  !endif
> diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
> b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
> index 193657ff2d61..bee98e798717 100644
> --- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
> +++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
> @@ -171,6 +171,7 @@ [LibraryClasses]
> 
> MemEncryptTdxLib|OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncrypt
> TdxLib.inf
>PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf
> 
> DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf
> +
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/I
> magePropertiesRecordLib.inf
> 
>LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
> 
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/Customize
> dDisplayLib.inf
> diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc
> b/OvmfPkg/Microvm/MicrovmX64.dsc
> index 2f7585639374..38e0af6ae101 100644
> --- a/OvmfPkg/Microvm/MicrovmX64.dsc
> +++ b/OvmfPkg/Microvm/MicrovmX64.dsc
> @@ -185,6 +185,7 @@ [LibraryClasses]
> 
> MemEncryptTdxLib|OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncrypt
> TdxLib.inf
>PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf
> 
> DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf
> +
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/I
> magePropertiesRecordLib.inf
> 
>  !if $(SOURCE_DEBUG_ENABLE) == TR

Re: [edk2-devel] [PATCH v1 3/3] OvmfPkg: Add varpolicy shell command

[Yao, Jiewen]

Acked-by: Jiewen Yao 

> -Original Message-
> From: mikub...@linux.microsoft.com 
> Sent: Tuesday, September 19, 2023 10:33 PM
> To: devel@edk2.groups.io
> Cc: Anatol Belski ; Anthony Perard
> ; Gerd Hoffmann ; Jianyong
> Wu ; Yao, Jiewen ; Justen,
> Jordan L ; Julien Grall 
> Subject: [PATCH v1 3/3] OvmfPkg: Add varpolicy shell command
> 
> From: Michael Kubacki 
> 
> Adds the varpolicy EFI shell command to all DSC files that
> currently include other dynamic shell commands from ShellPkg.
> 
> This command allows variable policies to be dumped in the EFI
> shell for convenient auditing and debug.
> 
> Use the command in QEMU EFI shell as follows:
> 
> - `"varpolicy"` dumps platform variables
> - `"varpolicy -?"` shows help text
> - `"varpolicy -b"` pages output as expected
> - `"varpolicy -s"` shows accurate variable statistic information
> - `"varpolicy -p"` shows accurate UEFI variable policy information
> - `"varpolicy-v -b"` dumps all information including variable data hex dump
> 
> Cc: Anatol Belski 
> Cc: Anthony Perard 
> Cc: Gerd Hoffmann 
> Cc: Jianyong Wu 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Signed-off-by: Michael Kubacki 
> ---
>  OvmfPkg/CloudHv/CloudHvX64.dsc | 4 
>  OvmfPkg/Microvm/MicrovmX64.dsc | 4 
>  OvmfPkg/OvmfPkgIa32.dsc| 4 
>  OvmfPkg/OvmfPkgIa32X64.dsc | 4 
>  OvmfPkg/OvmfPkgX64.dsc | 4 
>  OvmfPkg/OvmfXen.dsc| 4 
>  6 files changed, 24 insertions(+)
> 
> diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc
> b/OvmfPkg/CloudHv/CloudHvX64.dsc
> index 35942e02df93..c23c7eaf6cc2 100644
> --- a/OvmfPkg/CloudHv/CloudHvX64.dsc
> +++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
> @@ -837,6 +837,10 @@ [Components]
>  
>gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
>}
> +
> ShellPkg/DynamicCommand/VariablePolicyDynamicCommand/VariablePolicyDyn
> amicCommand.inf {
> +
> +  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> +  }
> 
> OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.i
> nf {
>  
>gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc
> b/OvmfPkg/Microvm/MicrovmX64.dsc
> index 0f26f2a9a97d..ea1fa3e2963f 100644
> --- a/OvmfPkg/Microvm/MicrovmX64.dsc
> +++ b/OvmfPkg/Microvm/MicrovmX64.dsc
> @@ -849,6 +849,10 @@ [Components]
>  
>gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
>}
> +
> ShellPkg/DynamicCommand/VariablePolicyDynamicCommand/VariablePolicyDyn
> amicCommand.inf {
> +
> +  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> +  }
> 
> OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.i
> nf {
>  
>gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index fcd3a3fda5f2..ed3a19feebe6 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -915,6 +915,10 @@ [Components]
>  
>gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
>}
> +
> ShellPkg/DynamicCommand/VariablePolicyDynamicCommand/VariablePolicyDyn
> amicCommand.inf {
> +
> +  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> +  }
> 
> OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.i
> nf {
>  
>gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index d0ae0b996d66..16ca139b2973 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -933,6 +933,10 @@ [Components.X64]
>  
>gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
>}
> +
> ShellPkg/DynamicCommand/VariablePolicyDynamicCommand/VariablePolicyDyn
> amicCommand.inf {
> +
> +  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> +  }
> 
> OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.i
> nf {
>  
>gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index a6811eee557e..dc1a0942aa8b 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -1001,6 +1001,10 @@ [Components]
>  
>gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
>}
> +
> ShellPkg/DynamicCommand/VariablePolicyDynamicCommand/VariablePolicyDyn
> amicCommand.inf {
> +
> +  gEfiShellPkgTokenSpaceGuid.

Re: [edk2-devel] [PATCH v5 00/28] Implement Dynamic Memory Protection Settings

[Yao, Jiewen]

I have some questions for the feature.

Take OVMF as an example, can a platform enforce the memory protection setting 
*at build time*? Or will every configuration come from *runtime*, such as QEMU 
Config? What is the current default behavior?

In case of configuration from QEMU runtime, a malicious QEMU MAY purposely 
downgrade the protection in CC use case. In order to detect such scenario, the 
QEMU configuration MUST be measured. Is that done in this patch set?

Thank you
Yao, Jiewen


> -Original Message-
> From: Taylor Beebe 
> Sent: Monday, October 9, 2023 8:07 AM
> To: devel@edk2.groups.io
> Cc: Abner Chang ; Warkentin, Andrei
> ; Anatol Belski ;
> Andrew Fish ; Anthony Perard ;
> Ard Biesheuvel ; Corvin Köhne
> ; Bi, Dandan ; Dong, Eric
> ; Aktas, Erdem ; Gerd
> Hoffmann ; Dong, Guo ; Guo, Gua
> ; James Bottomley ; Lu, James
> ; Wang, Jian J ; Jianyong Wu
> ; Yao, Jiewen ; Justen, Jordan L
> ; Julien Grall ; Leif Lindholm
> ; Gao, Liming ; Michael
> Roth ; Xu, Min M ; Peter
> Grehan ; Kumar, Rahul R ; Ni,
> Ray ; Rebecca Cran ; Sami Mujawar
> ; Rhodes, Sean ; Sunil V L
> ; Tom Lendacky 
> Subject: [PATCH v5 00/28] Implement Dynamic Memory Protection Settings
> 
> Reference: https://github.com/tianocore/edk2/pull/4895
> 
> v5:
> - Add a GrubCompat profile to SetMemoryProtectionsLib for compatibliity
> with older grub versions. This profile is now the default for ArmVirtPkg
> and OvmfPkg.
> 
> -Add a FixedAtBuild PCD to ArmVirtPkg which is used to determine the memory
> protection profile used each boot. By default, the profile used is the
> GrubCompat profile.
> 
> v4:
> -Update the memory protection profiles to align the allocated pools to the
> tail guard by default (patch 20).
> 
> - Add a patch to create MemoryProtectionConfigLib which consolidates code
> for parsing the fw_cfg for the memory protection profile strings (patch 22).
> 
> -Move the update to add QemuFwCfgParseString() to its own patch (patch 21).
> 
> v3:
> - Fix incorrect ordering of the SetMemoryProtectionsLib profile definitions
> midway through the patch series by using C99 instantialization.
> 
> - Update OvmfPkg to use the Release profile by default.
> 
> - Update the method by which platform initialization in OvmfPkg associates
> the input FwCfg data with the platform memory protection settings. The new
> way will try to match the string in FwCfg with the profile name. If no match
> is found, the default profile is used.
> 
> - SetMemoryProtectionsLib profile struct definition uses CHAR8 for the
> description and name strings instead of CHAR16.
> 
> - A new patch has been added to copy the PEI PCD database from the HOB to a
> new buffer so HOB memory is not written to.
> 
> - Move the call to protect HOB memory after NX and Heap Guard 
> instantialization
> has occurred to avoid them overwritting the HOB protections.
> 
> v2:
> - The previous version required the platform manage the HOB creation
> during PEI phase. v2 adds a new library, SetMemoryProtectionsLib, which
> offers an interface for setting, locking, and checking the memory protections
> for the boot. The settings are still backed by a HOB entry.
> SetMemoryProtectionsLib
> is a PEI/SEC only library as protections must be locked in by DxeHandoff().
> 
> - The previous version had a separate MM and DXE library for getting the 
> platform
> memory protection settings and populating the global for access. v2 
> consolidates
> these two libraries into a single GetMemoryProtectionsLib which has DXE and
> MM
> instances. The global populated is a union of the MM and DXE settings. The 
> first
> 4 bytes of the union is the signature used to identify whether the global 
> contains
> the DXE or MM settings.
> 
> - Add a patch to page-align the DXE allocated HOB list and apply RO and NX
> to it during memory protection initialization.
> 
> - Add a patch which checks the debug print level before executing the memory
> map dump routine. This saves several seconds of boot time on debug builds with
> memory protections active.
> 
> - Remove unnecessary code consolidation from the patch series to make it 
> easier
> to review. The code consolidation will be in a future patch series.
> 
> - Add the ability to set the memory protection profile via the fw_cfg QEMU
> interface on OvmfPkg platforms. The cfg parsing library needs to be ported to
> ArmVirtPkg to enable the same functionality on ARM virtual platforms.
> ArmVirtPkg
> will use the Release protection profile by default.
> 
> -Restructure the patch series to ensure bisectability as the memory logic
> is transitioned to use the Get and Set libraries one package at a time.
> The memory protection PCD

Re: [edk2-devel] setting TLS ciphers is broken (openssl 3?)

[Yao, Jiewen]

Hi Gerd
Thanks for the reporting. 

We will look into that. Is below text full reproduce steps? Which server you 
are using? Which TLS version is configured?
Please provide as detail as possible, if you could.


One more thing: We are going to have 1 week National Holiday since Tomorrow.
If we cannot nail down shortly, that would be next next week.

Thank you
Yao, Jiewen



> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Gerd
> Hoffmann
> Sent: Wednesday, September 27, 2023 4:39 PM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] setting TLS ciphers is broken (openssl 3?)
> 
>   Hi,
> 
> I've noticed that setting chipers for TLS stopped working in ovmf, most
> likely due to the openssl 3.0 update.
> 
> Test case: try http boot from https server, set ciphers on the qemu
> command line using:
> -object tls-cipher-suites,id=tls-cipher0,priority=@SYSTEM
> -fw_cfg name=etc/edk2/https/ciphers,gen_id=tls-cipher0
> 
> OvmfPkg/Library/TlsAuthConfigLib will read it from fwcfg and set
> EDKII_HTTP_TLS_CIPHER_LIST_VARIABLE.
> 
> CryptoPkg/Library/TlsLib/TlsConfig.c will read the variable, map the IDs
> to strings and call SSL_set_cipher_list() with the result.
> 
> Later on the tls handshake fails.  From the log:
> 
> [ ... ]
> TlsDxe:TlsSetCipherList: CipherString={
>   ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-
> SHA384:ECDHE-ECDSA-AES128-GC
>   M-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:DHE-RSA-AES256-GCM-
> SHA384:DHE-RSA-A
>   ES256-SHA:DHE-RSA-AES128-SHA:DHE-RSA-DES-CBC3-SHA
>   }
> [ ... ]
> TlsDoHandshake SSL_HANDSHAKE_ERROR State=0x10 SSL_ERROR_SSL
> TlsDoHandshake ERROR 0x308010C=L6:R8010C
> TlsDoHandshake ERROR 0xA0C0103=L14:RC0103
> [ ... ]
> 
> take care,
>   Gerd
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109128): https://edk2.groups.io/g/devel/message/109128
Mute This Topic: https://groups.io/mt/101613778/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] RISCV: Fix InternalLongJump to return correct value

[Yao, Jiewen]

I am OK for the RISC-V change.

Would you please let me know why we need openssl submodule ?


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Andrei
> Warkentin
> Sent: Tuesday, September 19, 2023 12:43 PM
> To: devel@edk2.groups.io
> Cc: Warkentin, Andrei ; Li, Yong
> ; Sunil V L ; Tuan Phan
> ; Daniel Schaefer 
> Subject: [edk2-devel] [PATCH v1 1/1] RISCV: Fix InternalLongJump to return
> correct value
> 
> InternalLongJump was not returning the 2nd parameter passed
> to LongJmp (Value) as the return value from SetJmp.
> 
> Seen with code compiled with -Os, where an LongJmp (Buffer, -1)
> somehow translated to SetJmp returning 0...
> 
> Cc: Yong Li 
> Cc: Sunil V L 
> Cc: Tuan Phan 
> Cc: Daniel Schaefer 
> Signed-off-by: Andrei Warkentin 
> ---
>  CryptoPkg/Library/OpensslLib/openssl  | 2 +-
>  MdePkg/Library/BaseLib/RiscV64/RiscVSetJumpLongJump.S | 7 ++-
>  2 files changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/CryptoPkg/Library/OpensslLib/openssl
> b/CryptoPkg/Library/OpensslLib/openssl
> index de90e54bbe82..830bf8e1e474 16
> --- a/CryptoPkg/Library/OpensslLib/openssl
> +++ b/CryptoPkg/Library/OpensslLib/openssl
> @@ -1 +1 @@
> -Subproject commit de90e54bbe82e5be4fb9608b6f5c308bb837d355
> +Subproject commit 830bf8e1e4749ad65c51b6a1d0d769ae689404ba
> diff --git a/MdePkg/Library/BaseLib/RiscV64/RiscVSetJumpLongJump.S
> b/MdePkg/Library/BaseLib/RiscV64/RiscVSetJumpLongJump.S
> index 34486eabba4c..e97a7d0727b8 100644
> --- a/MdePkg/Library/BaseLib/RiscV64/RiscVSetJumpLongJump.S
> +++ b/MdePkg/Library/BaseLib/RiscV64/RiscVSetJumpLongJump.S
> @@ -3,6 +3,7 @@
>  // Set/Long jump for RISC-V
>  //
>  // Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights
> reserved.
> +// Copyright (c) 2023, Intel Corporation. All rights reserved.
>  //
>  // SPDX-License-Identifier: BSD-2-Clause-Patent
>  //
> @@ -47,9 +48,5 @@ InternalLongJump:
>  REG_L s10, 11*SZREG(a0)
>  REG_L s11, 12*SZREG(a0)
>  REG_L sp,  13*SZREG(a0)
> -
> -add   a0, s0, 0
> -add   a1, s1, 0
> -add   a2, s2, 0
> -add   a3, s3, 0
> +mva0, a1
>  ret
> --
> 2.34.1
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108818): https://edk2.groups.io/g/devel/message/108818
Mute This Topic: https://groups.io/mt/101450445/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] OvmfPkg: raise DXEFV size to 14.5 MB in the traditional platform FDFs

[Yao, Jiewen]

Thanks Laszlo for the detail explanation, appreciate that.

I hope people will take action when it is close to 16MiB, then.

Anyway, I am OK with this so far.

Acked-by: Jiewen Yao 



> -Original Message-
> From: Laszlo Ersek 
> Sent: Tuesday, September 12, 2023 11:36 PM
> To: Yao, Jiewen ; Ard Biesheuvel 
> Cc: devel@edk2.groups.io; Ard Biesheuvel ; Gerd
> Hoffmann ; Justen, Jordan L 
> Subject: Re: [PATCH] OvmfPkg: raise DXEFV size to 14.5 MB in the traditional
> platform FDFs
> 
> On 9/12/23 17:02, Yao, Jiewen wrote:
> > Hello
> > I do not object the size increase.
> >
> > I am wondering if we need to take some action to control the size.
> 
> Yes, stop implementing new edk2 features, at least in the same one
> generic firmware binary. :)
> 
> > Or we just increase it, again and again? Of course, more feature ==
> > more size required.
> 
> Exactly.
> 
> DXEFV usage used to grow by 1MB every 20 months or so.
> 
> In particular I suspect (but have no proof) that the OpenSSL 3.0 update
> led to a size explosion. This latest increase both comes sooner and is
> larger than the previous ones.
> 
> It could likely be mitigated by including the crypto driver in OVMF (as
> opposed to linking openssl into every driver statically). But that just
> re-raises the age-old question: how do you find the minimal openssl
> service *set*, for the crypto driver, such that at OVMF runtime, all
> service requests can be satisfied?
> 
> (And, including the full crypto service set in the crypto DXE driver is
> much worse than the current state (= static linking) -- I think I once
> tested that, and the crypto DXE driver ended up so big that it
> outweighed the static linking savings on all the other DXE drivers
> combined. So trimming the feature set in the crypto DXE driver is
> essential, but I don't know how it can be made *guaranteed* safe.)
> 
> Of course we can also say, "if you need a NOOPT build for debugging a
> particular module, then do not include superfluous feaures (with the -D
> flag) in your debug build". I.e., declare that a NOOPT build requires
> trimming the -D feature flags.
> 
> It would diverge from the tradition, but I guess it should be possible
> too (I've not tested it though -- OpenSSL may be used so widely at this
> point in edk2 modules that removing some -D flags may not matter in
> practice, for saving space).
> 
> > May I know if there is up-limit from VMM perspective, such as KVM?
> > E.g. Can we support more than 16MiB ? More than 128MiB?
> 
> Well, QEMU currently has a limitation that the combined size of the
> pflash chips (binary+varstore) cannot exceed 8 MiB. But, that can be
> overridden on the command line, using the "max-fw-size" machine
> property.
> 
> The hard limit is currently 16 MiB (see pc_machine_set_max_fw_size() in
> QEMU's "hw/i386/pc.c").
> 
> I think HP uses a custom OVMF build that is larger than 8 MiB; see QEMU
> commit 0657c657eb37. (Note however that said limit refers to the
> *compressed* size, while here we're increasing the uncompressed size.
> More on this below:)
> 
> But, I think there may be an earlier limit of sorts:
> 
> We can keep increasing DXEFV for a while, because the LZMA compression
> in FVMAIN_COMPACT mitigates it. (See edk2 commit b24fca05751f for a
> schematic.) But once we outgrow the space allotted for FVMAIN_COMPACT
> (3360 KB), there could be an ugly surprise. I've not checked closely,
> but growing FVMAIN_COMPACT might lead to such PCD changes that would
> break compatibility between existent varstore files and new OVMF
> binaries (similarly to how growing the varstore is a compatibility
> breaking change). So at least Linux distros need to be aware of that.
> 
> Right now, with this patch, my IA32X64 NOOPT build prints:
> 
> SECFV [26%Full] 212992 (0x34000) total, 56976 (0xde90) used, 156016 (0x26170)
> free
> PEIFV [77%Full] 917504 (0xe) total, 710968 (0xad938) used, 206536
> (0x326c8) free
> DXEFV [96%Full] 15204352 (0xe8) total, 14610736 (0xdef130) used, 593616
> (0x90ed0) free
> FVMAIN_COMPACT [69%Full] 3440640 (0x348000) total, 2383312 (0x245dd0)
> used, 1057328 (0x102230) free
> 
> So we have still quite some room in FVMAIN_COMPACT. I think it would
> allow for an absolutely huge (uncompressed) DXEFV if we wanted to grow
> the compressed FVMAIN_COMPACT to the QEMU-permitted hard limit, that is,
> nearly 16 MiB.
> 
> Laszlo
> 
> >
> > Thank you
> > Yao, Jiewen
> >
> >> -Original Message-
> >> From: Ard Biesheuvel 
> >> Sent: Tuesday, September 12, 2023 10:59 PM
> >> To: Laszlo Ersek 
> >> Cc: devel@edk2

Re: [edk2-devel] [PATCH v3] Pyrite support - Secure erase is only available if encryption is supported.

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Liu, Linus 
> Sent: Tuesday, September 12, 2023 9:42 AM
> To: devel@edk2.groups.io
> Cc: Liu, Linus ; Zhang, Qi1 ; Kumar,
> Rahul R ; Yao, Jiewen ; Chen,
> Tina ; Chen, Xiao X 
> Subject: [PATCH v3] Pyrite support - Secure erase is only available if 
> encryption is
> supported.
> 
> From: Linus Liu 
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=3004
> 
> Cc: Qi Zhang
> Cc: Rahul Kumar 
> Cc: Jiewen Yao  
> Cc: Tina Chen   
> Cc: Xiao X Chen 
> Signed-off-by: Linus Liu 
> ---
>  SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c
> b/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c
> index e2e77cbc24..ba9fa66c60 100644
> --- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c
> +++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c
> @@ -87,7 +87,11 @@ OpalSupportGetAvailableActions (
>  // Secure erase is performed by generating a new encryption key
> 
>  // this is only available if encryption is supported
> 
>  //
> 
> -AvalDiskActions->SecureErase = 1;
> 
> +if (SupportedAttributes->MediaEncryption) {
> 
> +  AvalDiskActions->SecureErase = 1;
> 
> +} else {
> 
> +  AvalDiskActions->SecureErase = 0;
> 
> +}
> 
>} else {
> 
>  AvalDiskActions->PsidRevert  = 0;
> 
>  AvalDiskActions->SecureErase = 0;
> 
> --
> 2.39.2.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108555): https://edk2.groups.io/g/devel/message/108555
Mute This Topic: https://groups.io/mt/101307436/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] OvmfPkg: raise DXEFV size to 14.5 MB in the traditional platform FDFs

[Yao, Jiewen]

Hello
I do not object the size increase.

I am wondering if we need to take some action to control the size.
Or we just increase it, again and again? Of course, more feature == more size 
required.

May I know if there is up-limit from VMM perspective, such as KVM?
E.g. Can we support more than 16MiB ? More than 128MiB?

Thank you
Yao, Jiewen

> -Original Message-
> From: Ard Biesheuvel 
> Sent: Tuesday, September 12, 2023 10:59 PM
> To: Laszlo Ersek 
> Cc: devel@edk2.groups.io; Ard Biesheuvel ; Gerd
> Hoffmann ; Yao, Jiewen ; Justen,
> Jordan L 
> Subject: Re: [PATCH] OvmfPkg: raise DXEFV size to 14.5 MB in the traditional
> platform FDFs
> 
> On Tue, 12 Sept 2023 at 16:19, Laszlo Ersek  wrote:
> >
> > My usual IA32X64 and X64 builds fail for the NOOPT target, using GCC5:
> >
> > - IA32X64:
> >
> > > the required fv image size 0xdef130 exceeds the set fv image size
> > > 0xd0
> >
> > - X64:
> >
> > > the required fv image size 0xd8f7b8 exceeds the set fv image size
> > > 0xd0
> >
> > NOOPT is important for debugging (less confusing behavior with gdb, and
> > much less confusing disassembly).
> >
> > Raise the DXEFV size to 14.5 MB (14 MB would work, but cut it too close
> > for IA32X64).
> >
> > After this patch:
> >
> > - IA32:
> >
> > > DXEFV [83%Full] 15204352 (0xe8) total, 12718784 (0xc212c0) used,
> > > 2485568 (0x25ed40) free
> >
> > - IA32X64:
> >
> > > DXEFV [96%Full] 15204352 (0xe8) total, 14610736 (0xdef130) used,
> > > 593616 (0x90ed0) free
> >
> > - X64:
> >
> > > DXEFV [93%Full] 15204352 (0xe8) total, 14219192 (0xd8f7b8) used,
> > > 985160 (0xf0848) free
> >
> ...
> >
> > Cc: Ard Biesheuvel 
> > Cc: Gerd Hoffmann 
> > Cc: Jiewen Yao 
> > Cc: Jordan Justen 
> > Signed-off-by: Laszlo Ersek 
> 
> Acked-by: Ard Biesheuvel 
> 
> > ---
> >  OvmfPkg/OvmfPkgIa32.fdf| 6 +++---
> >  OvmfPkg/OvmfPkgIa32X64.fdf | 6 +++---
> >  OvmfPkg/OvmfPkgX64.fdf | 6 +++---
> >  3 files changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> > index 4c9be963a74d..383613e54b14 100644
> > --- a/OvmfPkg/OvmfPkgIa32.fdf
> > +++ b/OvmfPkg/OvmfPkgIa32.fdf
> > @@ -62,10 +62,10 @@ [FD.OVMF_CODE]
> >
> >  [FD.MEMFD]
> >  BaseAddress   = $(MEMFD_BASE_ADDRESS)
> > -Size  = 0xE0
> > +Size  = 0xF8
> >  ErasePolarity = 1
> >  BlockSize = 0x1
> > -NumBlocks = 0xE0
> > +NumBlocks = 0xF8
> >
> >  0x00|0x006000
> >
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgToken
> SpaceGuid.PcdOvmfSecPageTablesSize
> > @@ -86,7 +86,7 @@ [FD.MEMFD]
> >
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpa
> ceGuid.PcdOvmfPeiMemFvSize
> >  FV = PEIFV
> >
> > -0x10|0xD0
> > +0x10|0xE8
> >
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpa
> ceGuid.PcdOvmfDxeMemFvSize
> >  FV = DXEFV
> >
> > diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
> > index 7f599f15e341..3cec3d0c8790 100644
> > --- a/OvmfPkg/OvmfPkgIa32X64.fdf
> > +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
> > @@ -62,10 +62,10 @@ [FD.OVMF_CODE]
> >
> >  [FD.MEMFD]
> >  BaseAddress   = $(MEMFD_BASE_ADDRESS)
> > -Size  = 0xE0
> > +Size  = 0xF8
> >  ErasePolarity = 1
> >  BlockSize = 0x1
> > -NumBlocks = 0xE0
> > +NumBlocks = 0xF8
> >
> >  0x00|0x006000
> >
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgToken
> SpaceGuid.PcdOvmfSecPageTablesSize
> > @@ -86,7 +86,7 @@ [FD.MEMFD]
> >
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpa
> ceGuid.PcdOvmfPeiMemFvSize
> >  FV = PEIFV
> >
> > -0x10|0xD0
> > +0x10|0xE8
> >
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpa
> ceGuid.PcdOvmfDxeMemFvSize
> >  FV = DXEFV
> >
> > diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
> > index 41912fc1bece..9c35b6e848a2 100644
> > --- a/OvmfPkg/OvmfPkgX64.fdf
> > +++ b/OvmfPkg/OvmfPkgX64.fdf
> > @@ -62,10 +62,10 @@ [FD.OVMF_CODE]
> >
> >  [FD.MEMFD]
> >  BaseAddress   = $(MEMFD_BASE_ADDRESS)
> > -Size  = 0xE0
> > +Size  = 0xF8
> >  ErasePolarity = 1
> >  BlockSize = 0x1
>

Re: [edk2-devel] [PATCH v2] Pyrite support - Secure erase is only available if encryption is supported.

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Liu, Linus 
> Sent: Thursday, September 7, 2023 5:02 PM
> To: devel@edk2.groups.io
> Cc: Liu, Linus ; Zhang, Qi1 ; Kumar,
> Rahul R ; Yao, Jiewen ; Chen,
> Tina ; Chen, Xiao X 
> Subject: [PATCH v2] Pyrite support - Secure erase is only available if 
> encryption is
> supported.
> 
> From: Linus Liu 
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=3004
> 
> Cc: Qi Zhang
> Cc: Rahul Kumar 
> Cc: Jiewen Yao  
> Cc: Tina Chen   
> Cc: Xiao X Chen 
> ---
>  SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c
> b/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c
> index e2e77cbc24..ba9fa66c60 100644
> --- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c
> +++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c
> @@ -87,7 +87,11 @@ OpalSupportGetAvailableActions (
>  // Secure erase is performed by generating a new encryption key
> 
>  // this is only available if encryption is supported
> 
>  //
> 
> -AvalDiskActions->SecureErase = 1;
> 
> +if (SupportedAttributes->MediaEncryption) {
> 
> +  AvalDiskActions->SecureErase = 1;
> 
> +} else {
> 
> +  AvalDiskActions->SecureErase = 0;
> 
> +}
> 
>} else {
> 
>  AvalDiskActions->PsidRevert  = 0;
> 
>  AvalDiskActions->SecureErase = 0;
> 
> --
> 2.39.2.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108485): https://edk2.groups.io/g/devel/message/108485
Mute This Topic: https://groups.io/mt/101210886/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] OvmfPkg:Add variable store is full debug info

[Yao, Jiewen]

I don't think using ASSERT is a good idea here.

Why not return ERROR?



> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Zhenyu
> Zhang
> Sent: Thursday, September 7, 2023 7:11 PM
> To: devel@edk2.groups.io
> Cc: zheny...@redhat.com; ostef...@redhat.com; kra...@redhat.com;
> marcandre.lur...@redhat.com; stef...@linux.ibm.com;
> anthony.per...@citrix.com; jul...@xen.org
> Subject: [edk2-devel] [PATCH v2 1/1] OvmfPkg:Add variable store is full debug
> info
> 
> From: "Zhenyu Zhang" 
> 
> When the variable store is full, edk2 will directly assert.
> Add debug information to help users understand what caused
> the assertion.
> 
>  Actual results:
>  RecordVarErrorFlag (0xEF) 9A144FE2A47E:937FE521-95AE-4D1A-8929-
>  48BCD90AD31A - 0x0003 - 0x7E
>  CommonVariableSpace = 0x3FF9C - CommonVariableTotalSize =
>  0x3FF98
>  RecordVarErrorFlag (0xEF) 9A144FE2A47E:937FE521-95AE-4D1A-8929-
>  48BCD90AD31A - 0x0003 - 0x92
>  CommonVariableSpace = 0x3FF9C - CommonVariableTotalSize = 0x3FF98
> 
>  Synchronous Exception at 0x00023CA60374
>  ..
>  ASSERT_EFI_ERROR (Status = Out of Resources)
>  ASSERT /builddir/build/BUILD/edk2-ba91d0292e59/OvmfPkg/Library/
>  PlatformBootManagerLib/BdsPlatform.c(142): !(((INTN)(RETURN_
>  STATUS)(Status)) < 0)
> 
> Cc: Oliver Steffen 
> Cc: Gerd Hoffmann 
> Cc: Marc-André Lureau 
> Cc: Stefan Berger 
> Cc: Anthony Perard 
> Cc: Julien Grall 
> Signed-off-by: Zhenyu Zhang 
> ---
>  OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> index 8dc2bbf97371..c95c7931a3f5 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> @@ -139,6 +139,7 @@ PlatformRegisterFvBootOption (
> 
>if (OptionIndex == -1) {
>  Status = EfiBootManagerAddLoadOptionVariable (, MAX_UINTN);
> +DEBUG ((DEBUG_ERROR, "ERROR: Variable store is full.\n"));
>  ASSERT_EFI_ERROR (Status);
>}
> 
> --
> 2.39.3
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108375): https://edk2.groups.io/g/devel/message/108375
Mute This Topic: https://groups.io/mt/101211889/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] Pyrite support - Secure erase is only available if encryption is supported.

[Yao, Jiewen]

Thanks.

1) I think we need an else branch for " SupportedAttributes->MediaEncryption ", 
to assign " AvalDiskActions->SecureErase = 0;"


> -AvalDiskActions->SecureErase = 1;
> 
> +if (SupportedAttributes->MediaEncryption) {
> 
> +  AvalDiskActions->SecureErase = 1;
> 
> +}
> 
>} else {
> 
>  AvalDiskActions->PsidRevert  = 0;
> 
>  AvalDiskActions->SecureErase = 0;


2) May I know what test you have done?





> -Original Message-
> From: Liu, Linus 
> Sent: Monday, September 4, 2023 4:38 PM
> To: devel@edk2.groups.io
> Cc: Liu, Linus ; Zhang, Qi1 ; Kumar,
> Rahul R ; Yao, Jiewen 
> Subject: [PATCH v1] Pyrite support - Secure erase is only available if 
> encryption is
> supported.
> 
> From: Linus Liu 
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=3004
> 
> Cc: Qi Zhang
> Cc: Rahul Kumar 
> Cc: Jiewen Yao  
> ---
>  SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c
> b/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c
> index e2e77cbc24..88650a28dc 100644
> --- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c
> +++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c
> @@ -87,7 +87,9 @@ OpalSupportGetAvailableActions (
>  // Secure erase is performed by generating a new encryption key
> 
>  // this is only available if encryption is supported
> 
>  //
> 
> -AvalDiskActions->SecureErase = 1;
> 
> +if (SupportedAttributes->MediaEncryption) {
> 
> +  AvalDiskActions->SecureErase = 1;
> 
> +}
> 
>} else {
> 
>  AvalDiskActions->PsidRevert  = 0;
> 
>  AvalDiskActions->SecureErase = 0;
> 
> --
> 2.39.2.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108365): https://edk2.groups.io/g/devel/message/108365
Mute This Topic: https://groups.io/mt/101144585/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V9 0/2] Support RSA4096 and RSA3072

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

Merged https://github.com/tianocore/edk2/pull/4798

> -Original Message-
> From: Sheng, W 
> Sent: Thursday, September 7, 2023 9:57 AM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen ; Wang, Jian J ;
> Xu, Min M ; Chen, Zeyi ; Wang,
> Fiona ; Lu, Xiaoyu1 ; Jiang,
> Guomin ; Kinney, Michael D
> 
> Subject: [PATCH V9 0/2] Support RSA4096 and RSA3072
> 
> Patch V9:
> Refine coding format for file AuthService.c
> 
> Patch V8:
> Update the patch comments for CryptoPkg.
> Comment should be <76 characters in each line.
> Refine coding format.
> 
> Patch V7:
> Drop raw RSA3072 and RSA4096. Only use gEfiCertX509Guid for RSA3072 and
> RSA4096
> Do the positive tests and the negative tests below. And got all the expected
> results.
> 
> Patch V6:
> Remove the changes in MdePkg.
> The changes of patch v6 are in CryptoPkg and SecurityPkg.
> Set signature type to gEfiCertX509Guid when enroll RSA3072/RSA4096 KEK.
> This signature type is used to check the supported signature and show the 
> strings.
> 
> Patch V5:
> Using define KEY_TYPE_RSASSA to replace the magic number.
> 
> Patch V4:
> Determine the RSA algorithm by a supported algorithm list.
> 
> Patch V3:
> Select SHA algorithm automaticly for a unsigned efi image.
> 
> Patch V2:
> Determine the SHA algorithm by a supported algorithm list.
> Create SHA context for each algorithm.
> 
> Test Case:
> 1. Enroll a RSA4096 Cert, and execute an RSA4096 signed efi image under UEFI
> shell.
> 2. Enroll a RSA3072 Cert, and execute an RSA3072 signed efi image under UEFI
> shell.
> 3. Enroll a RSA2048 Cert, and execute an RSA2048 signed efi image under UEFI
> shell.
> 4. Enroll an unsigned efi image, execute the unsigned efi image under UEFI 
> shell
> 
> Test Result:
> Pass
> 
> Negative Test Case:
> 1) Enroll a RSA2048 Cert, execute an unsigned efi image.
> 2) Enroll a RSA2048 Cert, execute a RSA4096 signed efi image.
> 3) Enroll a RSA4096 Cert, execute a RSA3072 signed efi image.
> 4) Enroll a RSA4096 Cert to both DB and DBX, execute the RSA4096 signed efi
> image.
> 
> Test Result:
> Get "Access Denied" when try to execute the efi image.
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Min Xu 
> Cc: Zeyi Chen 
> Cc: Fiona Wang 
> Cc: Xiaoyu Lu 
> Cc: Guomin Jiang 
> Cc: Michael D Kinney 
> 
> Sheng Wei (2):
>   CryptoPkg/BaseCryptLib: add sha384 and sha512 to ImageTimestampVerify
>   SecurityPkg/SecureBoot: Support RSA4096 and RSA3072
> 
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c   |   3 +-
>  .../Library/AuthVariableLib/AuthService.c | 225 +++---
>  .../AuthVariableLib/AuthServiceInternal.h |   4 +-
>  .../Library/AuthVariableLib/AuthVariableLib.c |  42 ++--
>  .../DxeImageVerificationLib.c |  74 +++---
>  .../SecureBootConfigDxe.inf   |   8 +
>  .../SecureBootConfigImpl.c|  52 +++-
>  .../SecureBootConfigImpl.h|   7 +
>  .../SecureBootConfigStrings.uni   |   2 +
>  9 files changed, 331 insertions(+), 86 deletions(-)
> 
> --
> 2.26.2.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108360): https://edk2.groups.io/g/devel/message/108360
Mute This Topic: https://groups.io/mt/101207366/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 3/7] SecurityPkg.ci.yaml: Add debug macro exception

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: mikub...@linux.microsoft.com 
> Sent: Tuesday, August 15, 2023 4:49 AM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen ; Wang, Jian J 
> Subject: [PATCH v1 3/7] SecurityPkg.ci.yaml: Add debug macro exception
> 
> From: Michael Kubacki 
> 
> Adds a CI YAML entry to acknowledge a case where a single argument
> is matched to a format specifier with a ternary operator.
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Signed-off-by: Michael Kubacki 
> ---
>  SecurityPkg/SecurityPkg.ci.yaml | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/SecurityPkg/SecurityPkg.ci.yaml b/SecurityPkg/SecurityPkg.ci.yaml
> index 2138b0a5e21b..3f03762bd6f9 100644
> --- a/SecurityPkg/SecurityPkg.ci.yaml
> +++ b/SecurityPkg/SecurityPkg.ci.yaml
> @@ -106,5 +106,14 @@
> 
>  "Defines": {
>  "BLD_*_CONTINUOUS_INTEGRATION": "TRUE",
> +},
> +
> +"DebugMacroCheck": {
> +  "StringSubstitutions": {
> +  # SecurityPkg/IntelTdx/TdTcg2Dxe/TdTcg2Dxe.c
> +  # Reason: Acknowledging use of two format specifiers in string 
> with one
> argument
> +  # Replace ternary operator in debug string with single 
> specifier
> +  'Index == COLUME_SIZE/2 ? " | %02x" : " %02x"': "%d"
> +  }
>  }
>  }
> --
> 2.41.0.windows.3



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108351): https://edk2.groups.io/g/devel/message/108351
Mute This Topic: https://groups.io/mt/100745703/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 6/7] OvmfPkg/PlatformCI: Disable DebugMacroCheck

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: mikub...@linux.microsoft.com 
> Sent: Tuesday, August 15, 2023 4:49 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Yao, Jiewen
> ; Justen, Jordan L ; Gerd
> Hoffmann 
> Subject: [PATCH v1 6/7] OvmfPkg/PlatformCI: Disable DebugMacroCheck
> 
> From: Michael Kubacki 
> 
> Disables the DebugMacroCheck CI plugin to reduce CI checks performed
> in the package.
> 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Gerd Hoffmann 
> Signed-off-by: Michael Kubacki 
> ---
>  OvmfPkg/PlatformCI/PlatformBuildLib.py | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/OvmfPkg/PlatformCI/PlatformBuildLib.py
> b/OvmfPkg/PlatformCI/PlatformBuildLib.py
> index 1ada935d3cb4..f829738cdda4 100644
> --- a/OvmfPkg/PlatformCI/PlatformBuildLib.py
> +++ b/OvmfPkg/PlatformCI/PlatformBuildLib.py
> @@ -170,6 +170,7 @@ class PlatformBuilder( UefiBuilder,
> BuildSettingsManager):
>  self.env.SetValue("PRODUCT_NAME", "OVMF", "Platform Hardcoded")
>  self.env.SetValue("MAKE_STARTUP_NSH", "FALSE", "Default to false")
>  self.env.SetValue("QEMU_HEADLESS", "FALSE", "Default to false")
> +self.env.SetValue("DISABLE_DEBUG_MACRO_CHECK", "TRUE", "Disable by
> default")
>  return 0
> 
>  def PlatformPreBuild(self):
> --
> 2.41.0.windows.3



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108350): https://edk2.groups.io/g/devel/message/108350
Mute This Topic: https://groups.io/mt/100745709/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] MdePkg/Library/TdxLib: Remove unnecessary comparison

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael
> Kubacki
> Sent: Thursday, September 7, 2023 1:34 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ; Rebecca
> Cran 
> Subject: [edk2-devel] [PATCH v1 1/1] MdePkg/Library/TdxLib: Remove
> unnecessary comparison
> 
> From: Michael Kubacki 
> 
> Removes the comparison since unsigned values are always greater than
> or equal to 0.
> 
> See the following CodeQL query for more info:
> /cpp/cpp-unsigned-comparison-zero/
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Rebecca Cran 
> Signed-off-by: Michael Kubacki 
> ---
>  MdePkg/Library/TdxLib/Rtmr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Library/TdxLib/Rtmr.c b/MdePkg/Library/TdxLib/Rtmr.c
> index a0283966b353..cbf1dda7bcff 100644
> --- a/MdePkg/Library/TdxLib/Rtmr.c
> +++ b/MdePkg/Library/TdxLib/Rtmr.c
> @@ -51,7 +51,7 @@ TdExtendRtmr (
> 
>ASSERT (Data != NULL);
>ASSERT (DataLen == SHA384_DIGEST_SIZE);
> -  ASSERT (Index >= 0 && Index < RTMR_COUNT);
> +  ASSERT (Index < RTMR_COUNT);
> 
>if ((Data == NULL) || (DataLen != SHA384_DIGEST_SIZE) || (Index >=
> RTMR_COUNT)) {
>  return EFI_INVALID_PARAMETER;
> --
> 2.42.0.windows.2
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#108335): https://edk2.groups.io/g/devel/message/108335
> Mute This Topic: https://groups.io/mt/101198214/1772286
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [jiewen@intel.com]
> -=-=-=-=-=-=
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108346): https://edk2.groups.io/g/devel/message/108346
Mute This Topic: https://groups.io/mt/101198214/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v6 0/9] SecurityPkg/MdePkg: Update RngLib GUID identification

[Yao, Jiewen]

For SecurityPkg, acked-by: Jiewen Yao 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ard
> Biesheuvel
> Sent: Wednesday, September 6, 2023 5:13 PM
> To: devel@edk2.groups.io; sami.muja...@arm.com
> Cc: PierreGondois 
> Subject: Re: [edk2-devel] [PATCH v6 0/9] SecurityPkg/MdePkg: Update RngLib
> GUID identification
> 
> On Mon, 4 Sept 2023 at 15:01, Sami Mujawar  wrote:
> >
> > Hi All,
> >
> > This patch series implements code first USWG ECR 2386
> (https://mantis.uefi.org/mantis/view.php?id=2386) and also fixes other issues 
> to
> enable RNG support on Arm.
> > The RNG implementation for Arm is broken without this series on some
> platforms.
> >
> > If there are no further comments by end of this week, I plan to merge this 
> > series
> along with https://edk2.groups.io/g/devel/topic/99863881#106547
> >
> 
> For the series, and the intent to merge it as-is
> 
> Acked-by: Ard Biesheuvel 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108323): https://edk2.groups.io/g/devel/message/108323
Mute This Topic: https://groups.io/mt/100684678/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V7 0/2] Support RSA4096 and RSA3072

[Yao, Jiewen]

Thanks.

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Chen, Zeyi 
> Sent: Wednesday, September 6, 2023 9:56 AM
> To: Sheng, W ; devel@edk2.groups.io; Yao, Jiewen
> 
> Cc: Wang, Jian J ; Xu, Min M ;
> Wang, Fiona ; Lu, Xiaoyu1 ;
> Jiang, Guomin ; Kinney, Michael D
> ; Yu, Ling 
> Subject: RE: [edk2-devel] [PATCH V7 0/2] Support RSA4096 and RSA3072
> 
> Hi Wei,
> We finished some related secureboot tests with the IFWI you provided. Tests 
> are
> PASS.
> Test point:
> Enabled secure boot successfully without issue.
> Can support RSA3072 and RSA4096.
> Still support original keys/files.
> 
> Best Regards,
> Zeyi
> 
> -Original Message-
> From: Sheng, W 
> Sent: Wednesday, August 30, 2023 4:02 PM
> To: devel@edk2.groups.io; Yao, Jiewen 
> Cc: Wang, Jian J ; Xu, Min M ;
> Chen, Zeyi ; Wang, Fiona ; Lu,
> Xiaoyu1 ; Jiang, Guomin ;
> Kinney, Michael D ; Yu, Ling 
> Subject: RE: [edk2-devel] [PATCH V7 0/2] Support RSA4096 and RSA3072
> 
> Hi Jiewen,
> Do you have any comments on the patch V7?
> The 2 patches are for CryptoPkg and SecurityPky.
> Could you help to review/merge the patches?
> Thank you.
> BR
> Sheng Wei
> 
> > -Original Message-
> > From: Sheng, W
> > Sent: Tuesday, August 22, 2023 1:59 PM
> > To: devel@edk2.groups.io; Yao, Jiewen 
> > Cc: Wang, Jian J ; Xu, Min M
> > ; Chen, Zeyi ; Wang, Fiona
> > ; Lu,
> > Xiaoyu1 ; Jiang, Guomin
> > ; Kinney, Michael D
> > ; Sheng, W 
> > Subject: RE: [edk2-devel] [PATCH V7 0/2] Support RSA4096 and RSA3072
> >
> > Hi Jiewen,
> > I update the patch V6 to V7, drop raw RSA3K and RSA4K. The change is
> > in SecurityPkg.
> > And I did all the tests which are listed in the cover letter. I got
> > the expected results.
> > Could you help to review/merge this V7 patch for secure boot feature ?
> > Thank you.
> > BR
> > Sheng Wei
> >
> > > -Original Message-
> > > From: devel@edk2.groups.io  On Behalf Of Sheng
> > > Wei
> > > Sent: 2023年8月10日 10:24
> > > To: devel@edk2.groups.io
> > > Cc: Yao, Jiewen ; Wang, Jian J
> > > ; Xu, Min M ; Chen, Zeyi
> > > ; Wang, Fiona ; Lu,
> > > Xiaoyu1 ; Jiang, Guomin
> > > ; Kinney, Michael D
> > > 
> > > Subject: [edk2-devel] [PATCH V7 0/2] Support RSA4096 and RSA3072
> > >
> > > Patch V7:
> > > Drop raw RSA3072 and RSA4096. Only use gEfiCertX509Guid for RSA3072
> > > and
> > > RSA4096 Do the positive tests and the negative tests below. And got
> > > all the expected results.
> > >
> > > Patch V6:
> > > Remove the changes in MdePkg.
> > > The changes of patch v6 are in CryptoPkg and SecurityPkg.
> > > Set signature type to gEfiCertX509Guid when enroll RSA3072/RSA4096 KEK.
> > > This signature type is used to check the supported signature and
> > > show the strings.
> > >
> > > Patch V5:
> > > Using define KEY_TYPE_RSASSA to replace the magic number.
> > >
> > > Patch V4:
> > > Determine the RSA algorithm by a supported algorithm list.
> > >
> > > Patch V3:
> > > Select SHA algorithm automaticly for a unsigned efi image.
> > >
> > > Patch V2:
> > > Determine the SHA algorithm by a supported algorithm list.
> > > Create SHA context for each algorithm.
> > >
> > > Test Case:
> > > 1. Enroll a RSA4096 Cert, and execute an RSA4096 signed efi image
> > > under UEFI shell.
> > > 2. Enroll a RSA3072 Cert, and execute an RSA3072 signed efi image
> > > under UEFI shell.
> > > 3. Enroll a RSA2048 Cert, and execute an RSA2048 signed efi image
> > > under UEFI shell.
> > > 4. Enroll an unsigned efi image, execute the unsigned efi image
> > > under UEFI shell
> > >
> > > Test Result:
> > > Pass
> > >
> > > Negative Test Case:
> > > 1) Enroll a RSA2048 Cert, execute an unsigned efi image.
> > > 2) Enroll a RSA2048 Cert, execute a RSA4096 signed efi image.
> > > 3) Enroll a RSA4096 Cert, execute a RSA3072 signed efi image.
> > > 4) Enroll a RSA4096 Cert to both DB and DBX, execute the RSA4096
> > > signed efi image.
> > >
> > > Test Result:
> > > Get "Access Denied" when try to execute the efi image.
> > >
> > > Cc: Jiewen Yao 
> > > Cc: Jian J Wang 
> > > Cc: Min Xu 
> > > Cc: Zeyi Chen 
> > > Cc: Fiona Wang 
> > > Cc: Xiaoyu Lu

Re: [edk2-devel] [edk2/add_mbedtls PATCH 0/9] *** Add HMAC/HKDF/RSA/HASH features based on Mbedtls ***

[Yao, Jiewen]

Hi Mike
We are using submodule for mbedtls in this patch. Copying source code is not 
preferred.

I think we are discussing multiple ways to layout the *mbedtls crypto wrapper*. 
See following 4 options.

Thank you
Yao, Jiewen


> -Original Message-
> From: Kinney, Michael D 
> Sent: Thursday, August 31, 2023 11:45 PM
> To: Leif Lindholm ; Yao, Jiewen
> ; devel@edk2.groups.io; spbro...@outlook.com; Hou,
> Wenxing 
> Cc: af...@apple.com; Kinney, Michael D 
> Subject: RE: [edk2-devel] [edk2/add_mbedtls PATCH 0/9] *** Add
> HMAC/HKDF/RSA/HASH features based on Mbedtls ***
> 
> I have not looked at the Mbedtls patches in detail yet, but I
> am curious if it is possible to add the mbedtls based library
> instances of the edk2 crypto libraries to the existing
> CryptoPkg and pull the mbedtls sources into the CryptoPkg using
> a submodule just like openssl?  This way, platforms can choose
> either openssl or mbedtls library instances from CryptoPkg and
> all INFs would continue to only list CryptoPkg.dec.
> 
> I think use of submodules makes the most sense for content that
> edk2 consumes as read-only and edk2 makes decisions to jump from
> one validated release to the next validated release of the submodule
> content.
> 
> In general, we do not want to copy source from a different project
> into TianoCore repos because of the overhead to keep them in sync.
> An exception to this is something like cmocka where this was done
> for CI stability issues and the copy in TianoCore is an automated
> sync of the upstream repo.
> 
> Thanks,
> 
> Mike
> 
> 
> > -Original Message-
> > From: Leif Lindholm 
> > Sent: Thursday, August 31, 2023 4:15 AM
> > To: Yao, Jiewen ; devel@edk2.groups.io;
> > spbro...@outlook.com; Hou, Wenxing 
> > Cc: af...@apple.com; Kinney, Michael D 
> > Subject: Re: [edk2-devel] [edk2/add_mbedtls PATCH 0/9] *** Add
> > HMAC/HKDF/RSA/HASH features based on Mbedtls ***
> >
> > Like Sean, I'm very positive to the work - and I'm excited about the
> > opportunity to formalise the abstractions.
> >
> > But Sean is also asking to import the mbedTLS code outright instead of
> > using submodules, which adds an additional dimension to the matrix below.
> >
> > I'm not too concerned over the infrastructure change as such, but I
> > would prefer to not move the dial even further in the direction of
> > "upstream is a swarm of repositories". This adds complexity for new
> > developers. And submodules are way easier for upstream to track external
> > projects through. At the cost of complicating the maintenance process
> > for released products. Which isn't great.
> >
> > Am I kicking the can too far down the road if I suggest we do some
> > brainstorming around ways to achieve this with the least amount of
> > friction for everyone at the plugfest in October?
> >
> > Regards,
> >
> > Leif
> >
> > On 2023-08-31 03:34, Yao, Jiewen wrote:
> > > Hi Sean/Andrew/Leif/Mike
> > > Now, I think we actually have multiple options to handle this:
> > >
> > > 1) CryptoPkg in edk2 repo (add MbedTls to existing CryptoPkg)
> > >
> > > 2) CryptoPkg in edk2 repo + a new MbedTlsCryptoPkg in edk2 repo
> > >
> > > 3) CryptoPkg in edk2 repo + MbedTlsCryptoPkg in a new repo
> > >
> > > 4) Move CryptoPkg from edk2 repo to OpensslCryptoPkg in a new repo +
> > MbedTlsCryptoPkg in another new repo
> > >
> > >
> > >
> > > Current patch is for option 1).
> > > Sean's proposal is for option 4).
> > >
> > > I feel 4) is very aggressive. My worry is that it will involve many
> > infrastructure change such as CI, and all edk2 platforms.
> > >
> > > What about 2) or 3) ?
> > >
> > > Thank you
> > > Yao, Jiewen
> > >
> > >
> > >> -Original Message-
> > >> From: Yao, Jiewen
> > >> Sent: Thursday, August 31, 2023 8:10 AM
> > >> To: devel@edk2.groups.io; spbro...@outlook.com; Hou, Wenxing
> > >> 
> > >> Cc: af...@apple.com; quic_llind...@quicinc.com; Kinney, Michael D
> > >> 
> > >> Subject: RE: [edk2-devel] [edk2/add_mbedtls PATCH 0/9] *** Add
> > >> HMAC/HKDF/RSA/HASH features based on Mbedtls ***
> > >>
> > >> Hi Sean
> > >> Thanks for the feedback. Personally, I don't have strong opinion on this.
> > >>
> > >> Since this is a big change, I would like to have Steward member's 
> > >> opinion.
> > >>
&

Re: [edk2-devel] [edk2/add_mbedtls PATCH 0/9] *** Add HMAC/HKDF/RSA/HASH features based on Mbedtls ***

[Yao, Jiewen]

Hi Sean/Andrew/Leif/Mike
Now, I think we actually have multiple options to handle this:

1) CryptoPkg in edk2 repo (add MbedTls to existing CryptoPkg)

2) CryptoPkg in edk2 repo + a new MbedTlsCryptoPkg in edk2 repo

3) CryptoPkg in edk2 repo + MbedTlsCryptoPkg in a new repo

4) Move CryptoPkg from edk2 repo to OpensslCryptoPkg in a new repo + 
MbedTlsCryptoPkg in another new repo



Current patch is for option 1).
Sean's proposal is for option 4).

I feel 4) is very aggressive. My worry is that it will involve many 
infrastructure change such as CI, and all edk2 platforms.

What about 2) or 3) ?

Thank you
Yao, Jiewen


> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, August 31, 2023 8:10 AM
> To: devel@edk2.groups.io; spbro...@outlook.com; Hou, Wenxing
> 
> Cc: af...@apple.com; quic_llind...@quicinc.com; Kinney, Michael D
> 
> Subject: RE: [edk2-devel] [edk2/add_mbedtls PATCH 0/9] *** Add
> HMAC/HKDF/RSA/HASH features based on Mbedtls ***
> 
> Hi Sean
> Thanks for the feedback. Personally, I don't have strong opinion on this.
> 
> Since this is a big change, I would like to have Steward member's opinion.
> 
> Hi Andrew/Leif/Mike
> What do you think?
> 
> Thank you
> Yao, Jiewen
> 
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Sean
> > Sent: Thursday, August 31, 2023 2:57 AM
> > To: devel@edk2.groups.io; Hou, Wenxing 
> > Subject: Re: [edk2-devel] [edk2/add_mbedtls PATCH 0/9] *** Add
> > HMAC/HKDF/RSA/HASH features based on Mbedtls ***
> >
> > I appreciate and really like this work to enable mbedtls but I don't
> > like the idea of adding another submodule to edk2.
> >
> > For a long time there has been discussion about formalizing the
> > abstraction of the edk2 crypto api so that it would be practical to
> > implement edk2's crypto using various libraries.   I propose we remove
> > openssl from the edk2 CryptoPkg and into the OpenSslCryptoPkg in another
> > new tianocore repository dedicated to OpenSsl.  MbedTls could then be
> > checked into the MbedTlsCryptoPkg and added to another new repository.
> > This would also have the benefit of breaking the tight coupling of edk2
> > stable tags from the crypto used in the code base (crypto has more
> > widely tracked vulnerabilities).
> >
> > Happy to discuss more if others have different ideas.
> >
> > Thanks
> >
> > Sean
> >
> >
> >
> > On 8/30/2023 12:52 AM, Wenxing Hou wrote:
> > > *** Add BaseCryptLibMbedTls for CryptoPkg, which can be an alternative to
> > OpenSSL in some scenarios. There are four features in the patch:
> > HMAC/HKDF/RSA/HASH.***
> > >
> > > Wenxing Hou (9):
> > >CryptoPkg: Add mbedtls submodule for EDKII
> > >CryptoPkg: Add mbedtls_config and MbedTlsLib.inf
> > >CryptoPkg: Add HMAC functions based on Mbedtls
> > >CryptoPkg: Add HKDF functions based on Mbedtls
> > >CryptoPkg: Add RSA functions based on Mbedtls
> > >CryptoPkg: Add all .inf files for BaseCryptLibMbedTls
> > >CryptoPkg: Add Null functions for building pass
> > >CryptoPkg: Add MD5/SHA1/SHA2 functions based on Mbedtls
> > >CryptoPkg: Add Mbedtls submodule in CI
> > >
> > >   .gitmodules   |3 +
> > >   .pytool/CISettings.py |2 +
> > >   CryptoPkg/CryptoPkg.ci.yaml   |   66 +-
> > >   CryptoPkg/CryptoPkg.dec   |4 +
> > >   CryptoPkg/CryptoPkgMbedTls.dsc|  280 ++
> > >   .../BaseCryptLibMbedTls/BaseCryptLib.inf  |   81 +
> > >   .../BaseCryptLibMbedTls/Bn/CryptBnNull.c  |  520 +++
> > >   .../Cipher/CryptAeadAesGcmNull.c  |  100 +
> > >   .../BaseCryptLibMbedTls/Cipher/CryptAesNull.c |  159 +
> > >   .../BaseCryptLibMbedTls/Hash/CryptMd5.c   |  234 +
> > >   .../BaseCryptLibMbedTls/Hash/CryptMd5Null.c   |  163 +
> > >   .../Hash/CryptParallelHashNull.c  |   40 +
> > >   .../BaseCryptLibMbedTls/Hash/CryptSha1.c  |  234 +
> > >   .../BaseCryptLibMbedTls/Hash/CryptSha1Null.c  |  166 +
> > >   .../BaseCryptLibMbedTls/Hash/CryptSha256.c|  227 +
> > >   .../Hash/CryptSha256Null.c|  162 +
> > >   .../BaseCryptLibMbedTls/Hash/CryptSha512.c|  447 ++
> > >   .../Hash/CryptSha512Null.c|  275 ++
> > >   .../BaseCryptLibMbedTls/Hash/CryptSm3Null.c   |  164 +
> > >   .../BaseCryptLibMbedTls/Hmac/CryptHmac.c  |  620 +++
> > >   

Re: [edk2-devel] [edk2/add_mbedtls PATCH 0/9] *** Add HMAC/HKDF/RSA/HASH features based on Mbedtls ***

[Yao, Jiewen]

Hi Sean
Thanks for the feedback. Personally, I don't have strong opinion on this.

Since this is a big change, I would like to have Steward member's opinion.

Hi Andrew/Leif/Mike
What do you think?

Thank you
Yao, Jiewen


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Sean
> Sent: Thursday, August 31, 2023 2:57 AM
> To: devel@edk2.groups.io; Hou, Wenxing 
> Subject: Re: [edk2-devel] [edk2/add_mbedtls PATCH 0/9] *** Add
> HMAC/HKDF/RSA/HASH features based on Mbedtls ***
> 
> I appreciate and really like this work to enable mbedtls but I don't
> like the idea of adding another submodule to edk2.
> 
> For a long time there has been discussion about formalizing the
> abstraction of the edk2 crypto api so that it would be practical to
> implement edk2's crypto using various libraries.   I propose we remove
> openssl from the edk2 CryptoPkg and into the OpenSslCryptoPkg in another
> new tianocore repository dedicated to OpenSsl.  MbedTls could then be
> checked into the MbedTlsCryptoPkg and added to another new repository.
> This would also have the benefit of breaking the tight coupling of edk2
> stable tags from the crypto used in the code base (crypto has more
> widely tracked vulnerabilities).
> 
> Happy to discuss more if others have different ideas.
> 
> Thanks
> 
> Sean
> 
> 
> 
> On 8/30/2023 12:52 AM, Wenxing Hou wrote:
> > *** Add BaseCryptLibMbedTls for CryptoPkg, which can be an alternative to
> OpenSSL in some scenarios. There are four features in the patch:
> HMAC/HKDF/RSA/HASH.***
> >
> > Wenxing Hou (9):
> >CryptoPkg: Add mbedtls submodule for EDKII
> >CryptoPkg: Add mbedtls_config and MbedTlsLib.inf
> >CryptoPkg: Add HMAC functions based on Mbedtls
> >CryptoPkg: Add HKDF functions based on Mbedtls
> >CryptoPkg: Add RSA functions based on Mbedtls
> >CryptoPkg: Add all .inf files for BaseCryptLibMbedTls
> >CryptoPkg: Add Null functions for building pass
> >CryptoPkg: Add MD5/SHA1/SHA2 functions based on Mbedtls
> >CryptoPkg: Add Mbedtls submodule in CI
> >
> >   .gitmodules   |3 +
> >   .pytool/CISettings.py |2 +
> >   CryptoPkg/CryptoPkg.ci.yaml   |   66 +-
> >   CryptoPkg/CryptoPkg.dec   |4 +
> >   CryptoPkg/CryptoPkgMbedTls.dsc|  280 ++
> >   .../BaseCryptLibMbedTls/BaseCryptLib.inf  |   81 +
> >   .../BaseCryptLibMbedTls/Bn/CryptBnNull.c  |  520 +++
> >   .../Cipher/CryptAeadAesGcmNull.c  |  100 +
> >   .../BaseCryptLibMbedTls/Cipher/CryptAesNull.c |  159 +
> >   .../BaseCryptLibMbedTls/Hash/CryptMd5.c   |  234 +
> >   .../BaseCryptLibMbedTls/Hash/CryptMd5Null.c   |  163 +
> >   .../Hash/CryptParallelHashNull.c  |   40 +
> >   .../BaseCryptLibMbedTls/Hash/CryptSha1.c  |  234 +
> >   .../BaseCryptLibMbedTls/Hash/CryptSha1Null.c  |  166 +
> >   .../BaseCryptLibMbedTls/Hash/CryptSha256.c|  227 +
> >   .../Hash/CryptSha256Null.c|  162 +
> >   .../BaseCryptLibMbedTls/Hash/CryptSha512.c|  447 ++
> >   .../Hash/CryptSha512Null.c|  275 ++
> >   .../BaseCryptLibMbedTls/Hash/CryptSm3Null.c   |  164 +
> >   .../BaseCryptLibMbedTls/Hmac/CryptHmac.c  |  620 +++
> >   .../BaseCryptLibMbedTls/Hmac/CryptHmacNull.c  |  359 ++
> >   .../BaseCryptLibMbedTls/InternalCryptLib.h|   44 +
> >   .../BaseCryptLibMbedTls/Kdf/CryptHkdf.c   |  372 ++
> >   .../BaseCryptLibMbedTls/Kdf/CryptHkdfNull.c   |  192 +
> >   .../BaseCryptLibMbedTls/PeiCryptLib.inf   |  101 +
> >   .../BaseCryptLibMbedTls/PeiCryptLib.uni   |   25 +
> >   .../BaseCryptLibMbedTls/Pem/CryptPemNull.c|   69 +
> >   .../Pk/CryptAuthenticodeNull.c|   45 +
> >   .../BaseCryptLibMbedTls/Pk/CryptDhNull.c  |  150 +
> >   .../BaseCryptLibMbedTls/Pk/CryptEcNull.c  |  578 +++
> >   .../Pk/CryptPkcs1OaepNull.c   |   51 +
> >   .../Pk/CryptPkcs5Pbkdf2Null.c |   48 +
> >   .../Pk/CryptPkcs7Internal.h   |   83 +
> >   .../Pk/CryptPkcs7SignNull.c   |   53 +
> >   .../Pk/CryptPkcs7VerifyEkuNull.c  |  152 +
> >   .../Pk/CryptPkcs7VerifyEkuRuntime.c   |   56 +
> >   .../Pk/CryptPkcs7VerifyNull.c |  163 +
> >   .../Pk/CryptPkcs7VerifyRuntime.c  |   38 +
> >   .../BaseCryptLibMbedTls/Pk/CryptRsaBasic.c|  268 ++
> >   .../Pk/CryptRsaBasicNull.c|  121 +
> >   .../BaseCryptLibMbedTls/Pk/CryptRsaExt.c  |  337 

Re: [edk2-devel] [PATCH v1 1/1] SecurityPkg/Tpm2DeviceLibTcg2: Make mTcg2Protocol static

[Yao, Jiewen]

Merged https://github.com/tianocore/edk2/pull/4770

> -Original Message-
> From: Michael Kubacki 
> Sent: Wednesday, August 30, 2023 7:14 AM
> To: devel@edk2.groups.io; Yao, Jiewen ; Wang, Jian J
> 
> Subject: Re: [edk2-devel] [PATCH v1 1/1] SecurityPkg/Tpm2DeviceLibTcg2: Make
> mTcg2Protocol static
> 
> Hello,
> 
> Can you please help review this change when you get a chance?
> 
> Thanks,
> Michael
> 
> On 8/15/2023 11:50 AM, Michael Kubacki wrote:
> > From: Michael Kubacki 
> >
> > The global variable has a common name that can conflict with other
> > TCG modules. For example, Tcg2Dxe has a similarly named global that
> > is of type EFI_TCG2_PROTOCOL instead of EFI_TCG2_PROTOCOL*.
> >
> > Cc: Jiewen Yao 
> > Cc: Jian J Wang 
> > Signed-off-by: Michael Kubacki 
> > ---
> >   SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.c
> b/SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.c
> > index 3c8cf4fa117a..c792b1d67b06 100644
> > --- a/SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.c
> > +++ b/SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.c
> > @@ -14,7 +14,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> >   #include 
> >   #include 
> >
> > -EFI_TCG2_PROTOCOL  *mTcg2Protocol = NULL;
> > +STATIC  EFI_TCG2_PROTOCOL  *mTcg2Protocol = NULL;
> >
> >   /**
> > This service enables the sending of commands to the TPM2.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108113): https://edk2.groups.io/g/devel/message/108113
Mute This Topic: https://groups.io/mt/100760659/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] SecurityPkg/Tpm2DeviceLibTcg2: Make mTcg2Protocol static

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Michael Kubacki 
> Sent: Wednesday, August 30, 2023 7:14 AM
> To: devel@edk2.groups.io; Yao, Jiewen ; Wang, Jian J
> 
> Subject: Re: [edk2-devel] [PATCH v1 1/1] SecurityPkg/Tpm2DeviceLibTcg2: Make
> mTcg2Protocol static
> 
> Hello,
> 
> Can you please help review this change when you get a chance?
> 
> Thanks,
> Michael
> 
> On 8/15/2023 11:50 AM, Michael Kubacki wrote:
> > From: Michael Kubacki 
> >
> > The global variable has a common name that can conflict with other
> > TCG modules. For example, Tcg2Dxe has a similarly named global that
> > is of type EFI_TCG2_PROTOCOL instead of EFI_TCG2_PROTOCOL*.
> >
> > Cc: Jiewen Yao 
> > Cc: Jian J Wang 
> > Signed-off-by: Michael Kubacki 
> > ---
> >   SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.c
> b/SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.c
> > index 3c8cf4fa117a..c792b1d67b06 100644
> > --- a/SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.c
> > +++ b/SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.c
> > @@ -14,7 +14,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> >   #include 
> >   #include 
> >
> > -EFI_TCG2_PROTOCOL  *mTcg2Protocol = NULL;
> > +STATIC  EFI_TCG2_PROTOCOL  *mTcg2Protocol = NULL;
> >
> >   /**
> > This service enables the sending of commands to the TPM2.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108103): https://edk2.groups.io/g/devel/message/108103
Mute This Topic: https://groups.io/mt/100760659/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] OvmfPkg/AmdSev: fix BdsPlatform.c assertion failure during boot

[Yao, Jiewen]

Acked-by: Jiewen Yao 

> -Original Message-
> From: Gerd Hoffmann 
> Sent: Monday, August 21, 2023 11:29 PM
> To: Michael Roth 
> Cc: devel@edk2.groups.io; Ni, Ray ; Aktas, Erdem
> ; James Bottomley ; Yao,
> Jiewen ; Xu, Min M ; Tom
> Lendacky 
> Subject: Re: [PATCH 1/2] OvmfPkg/AmdSev: fix BdsPlatform.c assertion failure
> during boot
> 
> On Wed, Aug 16, 2023 at 03:11:45PM -0500, Michael Roth wrote:
> > Booting an SEV guest with AmdSev OVMF package currently triggers the
> > following assertion with QEMU:
> >
> >   InstallQemuFwCfgTables: installed 7 tables
> >   PcRtc: Write 0x20 to CMOS location 0x32
> >   [Variable]END_OF_DXE is signaled
> >   Initialize variable error flag (FF)
> >
> >   ASSERT_EFI_ERROR (Status = Not Found)
> >   ASSERT [BdsDxe]
> /home/VT_BUILD/ovmf/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.
> c(1711): !(((INTN)(RETURN_STATUS)(Status)) < 0)
> >
> > This seems to be due to commit 81dc0d8b4c, which switched to using
> > PlatformBootManagerLib instead of PlatformBootManagerLibGrub. That
> > pulls in a dependency on gEfiS3SaveStateProtocolGuid provider being
> > available (which is asserted for in
> > BdsPlatform.c:PlatformBootManagerBeforeConsole()/SaveS3BootScript()),
> > but the libraries that provide it aren't currently included in the
> > build. Add them similarly to what's done for OvmfPkg.
> >
> > Fixes: 81dc0d8b4c ("OvmfPkg/AmdSev: stop using
> PlatformBootManagerLibGrub")
> > Cc: Gerd Hoffmann 
> > Cc: Ray Ni 
> > Cc: Erdem Aktas 
> > Cc: James Bottomley 
> > Cc: Jiewen Yao 
> > Cc: Min Xu 
> > Cc: Tom Lendacky 
> > Signed-off-by: Michael Roth 
> 
> Acked-by: Gerd Hoffmann 
> 
> should be added to the stable tag.
> 
> take care,
>   Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107923): https://edk2.groups.io/g/devel/message/107923
Mute This Topic: https://groups.io/mt/100787519/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] Use C99 flexible arrays

[Yao, Jiewen]

Hi
This fix breaks the compatibility.

Have you tested all features that depends on this data structure?

Thank you
Yao, Jiewen

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Elyes Haouas
> Sent: Sunday, August 20, 2023 8:07 PM
> To: devel@edk2.groups.io
> Cc: Elyes Haouas 
> Subject: [edk2-devel] [PATCH] Use C99 flexible arrays
> 
> Use C99 flexible arrays instead of older style of one-element or
> zero-length arrays.
> It allows the compiler to generate errors when the flexible array does
> not occur at the end in the structure.
> 
> Signed-off-by: Elyes Haouas 
> ---
>  EmbeddedPkg/Include/fdt.h  |  4 ++--
>  .../Library/FrameBufferBltLib/FrameBufferBltLib.c  |  2 +-
>  MdePkg/Include/IndustryStandard/IpmiNetFnApp.h |  8 
>  MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h |  4 ++--
>  MdePkg/Include/IndustryStandard/IpmiNetFnStorage.h |  6 +++---
>  MdePkg/Include/IndustryStandard/IpmiNetFnTransport.h   |  8 
>  MdePkg/Include/IndustryStandard/PldmSmbiosTransfer.h   |  8 
>  MdePkg/Include/IndustryStandard/TcgStorageCore.h   |  6 +++---
>  MdePkg/Include/Protocol/NetworkInterfaceIdentifier.h   |  2 +-
>  MdePkg/Include/Protocol/NvdimmLabel.h  |  2 +-
>  UefiPayloadPkg/Include/Coreboot.h  | 10 +-
>  11 files changed, 30 insertions(+), 30 deletions(-)
> 
> diff --git a/EmbeddedPkg/Include/fdt.h b/EmbeddedPkg/Include/fdt.h
> index 120dbc8bc6..f64695da5c 100644
> --- a/EmbeddedPkg/Include/fdt.h
> +++ b/EmbeddedPkg/Include/fdt.h
> @@ -81,14 +81,14 @@ struct fdt_reserve_entry {
> 
> 
>  struct fdt_node_header {
> 
>fdt32_ttag;
> 
> -  char   name[0];
> 
> +  char   name[];
> 
>  };
> 
> 
> 
>  struct fdt_property {
> 
>fdt32_ttag;
> 
>fdt32_tlen;
> 
>fdt32_tnameoff;
> 
> -  char   data[0];
> 
> +  char   data[];
> 
>  };
> 
> 
> 
>  #endif /* !__ASSEMBLY */
> 
> diff --git a/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> b/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> index 432577bcfd..5fc5779e16 100644
> --- a/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> +++ b/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
> @@ -24,7 +24,7 @@ struct FRAME_BUFFER_CONFIGURE {
>EFI_PIXEL_BITMASKPixelMasks;
> 
>INT8 PixelShl[4];// R-G-B-Rsvd
> 
>INT8 PixelShr[4];// R-G-B-Rsvd
> 
> -  UINT8LineBuffer[0];
> 
> +  UINT8LineBuffer[];
> 
>  };
> 
> 
> 
>  CONST EFI_PIXEL_BITMASK  mRgbPixelMasks = {
> 
> diff --git a/MdePkg/Include/IndustryStandard/IpmiNetFnApp.h
> b/MdePkg/Include/IndustryStandard/IpmiNetFnApp.h
> index b6bc91f46c..b5174a5042 100644
> --- a/MdePkg/Include/IndustryStandard/IpmiNetFnApp.h
> +++ b/MdePkg/Include/IndustryStandard/IpmiNetFnApp.h
> @@ -433,7 +433,7 @@ typedef union {
>  typedef struct {
> 
>UINT8  CompletionCode;
> 
>IPMI_GET_MESSAGE_CHANNEL_NUMBERChannelNumber;
> 
> -  UINT8  MessageData[0];
> 
> +  UINT8  MessageData[];
> 
>  } IPMI_GET_MESSAGE_RESPONSE;
> 
> 
> 
>  //
> 
> @@ -457,12 +457,12 @@ typedef union {
>  typedef struct {
> 
>UINT8   CompletionCode;
> 
>IPMI_SEND_MESSAGE_CHANNEL_NUMBERChannelNumber;
> 
> -  UINT8   MessageData[0];
> 
> +  UINT8   MessageData[];
> 
>  } IPMI_SEND_MESSAGE_REQUEST;
> 
> 
> 
>  typedef struct {
> 
>UINT8CompletionCode;
> 
> -  UINT8ResponseData[0];
> 
> +  UINT8ResponseData[];
> 
>  } IPMI_SEND_MESSAGE_RESPONSE;
> 
> 
> 
>  //
> 
> @@ -906,7 +906,7 @@ typedef union {
>  typedef struct {
> 
>IPMI_SET_USER_PASSWORD_USER_ID  UserId;
> 
>IPMI_SET_USER_PASSWORD_OPERATIONOperation;
> 
> -  UINT8   PasswordData[0]; // 16 or 20 bytes, 
> depending on the
> 'PasswordSize' field
> 
> +  UINT8   PasswordData[]; // 16 or 20 bytes, 
> depending on the
> 'PasswordSize' field
> 
>  } IPMI_SET_USER_PASSWORD_REQUEST;
> 
> 
> 
>  //
> 
> diff --git a/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
> b/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
> index e3b8a62105..44024da69c 100644
> --- a/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
> ++