Re: [edk2-devel] SPDM Transports

[Yao, Jiewen]

Hi Tim/Alistair
Is there any detailed proposal, as such we can have a discussion?

I am not sure what is the plan for the driver model version MCTP. If it is 
something mature, we can definitely discuss it.

Thank you
Yao, Jiewen

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Alistair
> Francis
> Sent: Wednesday, October 2, 2024 11:39 AM
> To: devel@edk2.groups.io; LEWIS, TIM 
> Cc: Alan Weng ; Leon Chen 
> Subject: Re: [edk2-devel] SPDM Transports
> 
> Hey Tim,
> 
> From my understanding the SPDM support in EDK2 is still very new and
> not yet (at least last time I looked) actually connected to anything.
> 
> Supporting a range of SPDM transports is important. It's not just MCTP
> and DOE, but the storage (ATA, SCSI and NVMe) protocols as well that
> should be supported.
> 
> It would be great if any abstraction takes into account a range of
> transport methods, at least allowing them to be implemented later. I'm
> currently slowly working towards DOE support [1], but if you are able
> to design a general SPDM abstraction that would be great and I would
> be happy to help where I can, although I'm not an EDK2 expert.
> 
> 1: https://github.com/tianocore/edk2/pull/5715
> 
> Alistair
> 
> On Wed, Oct 2, 2024 at 3:31 AM Tim Lewis via groups.io
>  wrote:
> >
> > We are actively implementing generic SPDM support into our codebase, 
> > starting
> with the code in EDK2. However, we are now trying to separate the SPDM code
> from PCI DoE (to use MCTP, for example). Right now it seems the EDK2 version 
> is
> hardcoded for PCI DoE. We would like to add some abstraction and are
> considering adding a separate driver that can sit on top of the MCTP layer. 
> Do you
> think we should pursue the driver model or do you have another way to support
> multiple SPDM transports?
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Tim Lewis
> >
> > CTO, Insyde Software
> >
> >
> 
> 
> 
> 



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

Re: [edk2-devel] Can we do something about libspdm?

[Yao, Jiewen]

Thanks Leif. I saw the issue is closed.

Please evaluate again, to see if the problem is resolved.
If not, you may reopen the issue at libspdm project.

Please feel free to submit issue if you see anything could be improved.

Thank you
Yao, Jiewen

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Leif Lindholm
> Sent: Wednesday, July 31, 2024 10:10 PM
> To: devel@edk2.groups.io; Yao, Jiewen 
> Cc: Kinney, Michael D ; Andrew Fish
> 
> Subject: Re: [edk2-devel] Can we do something about libspdm?
> 
> OK, I've raised https://github.com/DMTF/libspdm/issues/2787.
> 
> On Wed, Jul 31, 2024 at 12:47:25 +, Yao, Jiewen wrote:
> > i recommend submitting issue directly to libspdm project github.
> >
> > thank you
> > jiewen yao
> > 
> > 发件人: Leif Lindholm 
> > 发送时间: Wednesday, July 31, 2024 6:34:32 PM
> > 收件人: devel@edk2.groups.io 
> > 抄送: Yao, Jiewen ; Kinney, Michael D
> ; Andrew Fish 
> > 主题: Can we do something about libspdm?
> >
> > Hi,
> >
> > The libspdm submodule is 1.1GB of (compressed) data to clone, but only
> > 18MB once checked out.
> >
> > This is by some margin the majority of the time it takes to clone edk2
> > and submodules. (It takes me 5m44s, and I don't think it's my Internet
> > connection slowing it down.)
> >
> > Having become curious as to how it managed to get that bad, I had a
> > dig. And found that nearly all of the data comes from a branch (that
> > is not a branch of the codebase at all) called github_pages.
> > If I run
> >   $ git branch -r -d github_pages
> >   $ git gc --prune=now
> > the size of my cloned directory shrinks from 1.1GB down to a more
> > reasonable 27MB.
> >
> > Does anyone have any connections at DTMF that we can try to get in
> > touch with to discuss how to improve their repository setup?
> >
> > /
> > Leif
> >
> >
> >
> >
> >
> 
> 
> 
> 



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

Re: [edk2-devel] Can we do something about libspdm?

[Yao, Jiewen]

i recommend submitting issue directly to libspdm project github.

thank you
jiewen yao

发件人: Leif Lindholm 
发送时间: Wednesday, July 31, 2024 6:34:32 PM
收件人: devel@edk2.groups.io 
抄送: Yao, Jiewen ; Kinney, Michael D 
; Andrew Fish 
主题: Can we do something about libspdm?

Hi,

The libspdm submodule is 1.1GB of (compressed) data to clone, but only
18MB once checked out.

This is by some margin the majority of the time it takes to clone edk2
and submodules. (It takes me 5m44s, and I don't think it's my Internet
connection slowing it down.)

Having become curious as to how it managed to get that bad, I had a
dig. And found that nearly all of the data comes from a branch (that
is not a branch of the codebase at all) called github_pages.
If I run
  $ git branch -r -d github_pages
  $ git gc --prune=now
the size of my cloned directory shrinks from 1.1GB down to a more
reasonable 27MB.

Does anyone have any connections at DTMF that we can try to get in
touch with to discuss how to improve their repository setup?

/
Leif


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

Re: [edk2-devel] CryptoPkg host test broken due to smoketest for RDRAND

[Yao, Jiewen]

> -Original Message-
> From: Ard Biesheuvel 
> Sent: Saturday, June 15, 2024 12:14 AM
> To: Yao, Jiewen 
> Cc: Li, Yi1 ; Gerd Hoffmann ;
> devel@edk2.groups.io; Hou, Wenxing ; Kinney, Michael
> D ; Pedro Falcato 
> Subject: Re: [edk2-devel] CryptoPkg host test broken due to smoketest for
> RDRAND
> 
> On Fri, 14 Jun 2024 at 18:09, Yao, Jiewen  wrote:
> >
> > Hey
> > This PR seems just a workaround.
> >
> > I don't feel it is right solution to hardcode BIT30.
> > What if the host platform does not have such capability? You will get 
> > failure
> later.
> >
> 
> Agreed. But that was already the case: RngLib assumed that RDRAND was
> implemented without checking CPUID at all, and so the code was already
> broken on systems without RDRAND.

[Jiewen] Sorry, I don’t understand your comment. " implemented without checking 
CPUID at all "

See below code. It does use CPUID to check the capability.

EFI_STATUS
EFIAPI
BaseRngLibConstructor (
  VOID
  )
{
  UINT32  RegEcx;

  //
  // Determine RDRAND support by examining bit 30 of the ECX register returned 
by
  // CPUID. A value of 1 indicates that processor support RDRAND instruction.
  //
  AsmCpuid (1, 0, 0, &RegEcx, 0);

  mRdRandSupported = ((RegEcx & RDRAND_MASK) == RDRAND_MASK);

  if (mRdRandSupported) {
mRdRandSupported = TestRdRand ();
  }

  return EFI_SUCCESS;
}


> 
> >
> > To fix this function, can we call real CPUID instruction to return real 
> > value?
> >
> 
> That would be better. But this change just restores the old behavior.
> And on top of that, Yi Li already merged it.

[Jiewen] I don’t think it is right to merge it without thorough review.

I think we need follow 24 hour rule.
Any patch requires at least 24 hours before merge, to give people chance to 
review and feedback.







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

Re: [edk2-devel] CryptoPkg host test broken due to smoketest for RDRAND

[Yao, Jiewen]

Hey
This PR seems just a workaround.

I don't feel it is right solution to hardcode BIT30.
What if the host platform does not have such capability? You will get failure 
later.

To fix this function, can we call real CPUID instruction to return real value?


UINT32
EFIAPI
UnitTestHostBaseLibAsmCpuid (
  IN  UINT32  Index,
  OUT UINT32  *Eax   OPTIONAL,
  OUT UINT32  *Ebx   OPTIONAL,
  OUT UINT32  *Ecx   OPTIONAL,
  OUT UINT32  *Edx   OPTIONAL
  )
{
  UINT32  RetEcx;

  RetEcx = 0;
  switch (Index) {
case 1:
  RetEcx |= BIT30; /* RdRand */
  break;
  }

  if (Eax != NULL) {
*Eax = 0;
  }
  if (Ebx != NULL) {
*Ebx = 0;
  }

  if (Ecx != NULL) {
*Ecx = RetEcx;
  }

  if (Edx != NULL) {
*Edx = 0;
  }
  return Index;
}

> -Original Message-
> From: Li, Yi1 
> Sent: Friday, June 14, 2024 9:32 PM
> To: Gerd Hoffmann ; devel@edk2.groups.io
> Cc: Hou, Wenxing ; Yao, Jiewen
> ; Kinney, Michael D ;
> Pedro Falcato ; Ard Biesheuvel
> 
> Subject: RE: [edk2-devel] CryptoPkg host test broken due to smoketest for
> RDRAND
> 
> Approved, appreciate your quick response.
> 
> Thanks,
> Yi
> 
> -Original Message-
> From: Gerd Hoffmann 
> Sent: Friday, June 14, 2024 6:41 PM
> To: devel@edk2.groups.io; Li, Yi1 
> Cc: Hou, Wenxing ; Yao, Jiewen
> ; Kinney, Michael D ;
> Pedro Falcato ; Ard Biesheuvel
> 
> Subject: Re: [edk2-devel] CryptoPkg host test broken due to smoketest for
> RDRAND
> 
> On Fri, Jun 14, 2024 at 07:07:41AM GMT, Li, Yi wrote:
> > All crypto host tests which consumed randlib broken due to:
> > https://github.com/tianocore/edk2/pull/5714
> > Not sure why this issue not reported  by CI when merge this PR.
> >
> > The reason is that the ```BaseRngLibConstructor``` of rnglib is not called 
> > in host
> test, so ```mRdRandSupported``` is not enabled.
> > Then the Crypto API calls ```GetRandomNumber*``` will fail.
> > GetRandomNumber64 (
> >   OUT UINT64  *Rand
> >   )
> > {
> >   ..
> >   if (!ArchIsRngSupported ()) {
> > return FALSE;
> >   }
> >
> > Is there a way to let unit test host to call the constructors correctly?
> 
> https://github.com/tianocore/edk2/pull/5775
> 
> take care,
>   Gerd



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

Re: [edk2-devel] CryptoPkg host test broken due to smoketest for RDRAND

[Yao, Jiewen]

Can we use a host test specific RngLib?



From: Li, Yi1 
Sent: Friday, June 14, 2024 3:08 PM
To: devel@edk2.groups.io
Cc: Hou, Wenxing ; Yao, Jiewen ; 
Kinney, Michael D ; Pedro Falcato 
; Ard Biesheuvel 
Subject: CryptoPkg host test broken due to smoketest for RDRAND

All crypto host tests which consumed randlib broken due to:
https://github.com/tianocore/edk2/pull/5714
Not sure why this issue not reported  by CI when merge this PR.

The reason is that the ```BaseRngLibConstructor``` of rnglib is not called in 
host test, so ```mRdRandSupported``` is not enabled.
Then the Crypto API calls ```GetRandomNumber*``` will fail.
GetRandomNumber64 (
  OUT UINT64  *Rand
  )
{
  ..
  if (!ArchIsRngSupported ()) {
return FALSE;
  }

Is there a way to let unit test host to call the constructors correctly?

Regards,
Yi



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119568): https://edk2.groups.io/g/devel/message/119568
Mute This Topic: https://groups.io/mt/10288/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: Update VMM Hob list check to support new resource attributes

[Yao, Jiewen]

merged

> -Original Message-
> From: Lin, Du 
> Sent: Thursday, May 30, 2024 8:07 PM
> To: Yao, Jiewen ; devel@edk2.groups.io; gaoliming
> 
> Cc: 'Ard Biesheuvel' ; 'Gerd Hoffmann'
> ; Lin, Du 
> Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> support new resource attributes
> 
> Hi Jiewen,
> 
> Thanks for your patience. I rebased this PR again since CI failed after "merge
> branch". And it is ready to go now.
> 
> Per my limited understanding, it should be OK to add the "push" label to 
> merge a
> PR to upstream even the PR shows "This branch is out-of-date with the base
> branch" as long as there are no merge conflicts.
>  - Example of adding "push" label to an out-of-date PR:
> https://github.com/tianocore/edk2/pull/5461
>  - Example of adding "push" label to an up-to-date PR:
> https://github.com/tianocore/edk2/pull/5460
> 
> BRs,
> Lin, Du
> 
> -Original Message-
> From: Yao, Jiewen 
> Sent: Thursday, May 30, 2024 6:31 PM
> To: Lin, Du ; devel@edk2.groups.io; gaoliming
> 
> Cc: 'Ard Biesheuvel' ; 'Gerd Hoffmann'
> 
> Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> support new resource attributes
> 
> It is out of date again.
> 
> When I click rebase, I notice git uses "merge branch". It seems not what we
> want.
> 
> I am not sure how to handle it.
> 
> Next time, please tell me ASAP once you submit a new PR.
> 
> 
> > -Original Message-
> > From: Lin, Du 
> > Sent: Thursday, May 30, 2024 6:26 PM
> > To: Yao, Jiewen ; devel@edk2.groups.io;
> > gaoliming 
> > Cc: 'Ard Biesheuvel' ; 'Gerd Hoffmann'
> > ; Lin, Du 
> > Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check
> > to support new resource attributes
> >
> > Thanks Jiewen. A new PR has been submitted for this:
> > https://github.com/tianocore/edk2/pull/5699.
> >
> > BRs,
> > Lin, Du
> >
> > -Original Message-
> > From: Yao, Jiewen 
> > Sent: Thursday, May 30, 2024 8:00 AM
> > To: devel@edk2.groups.io; Yao, Jiewen ;
> > gaoliming ; Lin, Du 
> > Cc: 'Ard Biesheuvel' ; 'Gerd Hoffmann'
> > 
> > Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check
> > to support new resource attributes
> >
> > Lin Du
> > Just FYI: The CI failed after I rebase.
> >
> > If possible, I recommend to submit a new PR to get it resolved.
> > Then I can approve again.
> >
> >
> > > -Original Message-
> > > From: devel@edk2.groups.io  On Behalf Of Yao,
> > > Jiewen
> > > Sent: Monday, May 27, 2024 3:13 PM
> > > To: gaoliming ; devel@edk2.groups.io; Lin,
> > > Du 
> > > Cc: 'Ard Biesheuvel' ; 'Gerd Hoffmann'
> > > 
> > > Subject: Re: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check
> > > to support new resource attributes
> > >
> > > Thanks. Not urgent. Let’s wait.
> > >
> > >
> > > > -Original Message-
> > > > From: gaoliming 
> > > > Sent: Monday, May 27, 2024 3:12 PM
> > > > To: devel@edk2.groups.io; Yao, Jiewen ; Lin,
> > > > Du 
> > > > Cc: 'Ard Biesheuvel' ; 'Gerd Hoffmann'
> > > > 
> > > > Subject: 回复: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list
> > > > check to support new resource attributes
> > > >
> > > > Jiewen:
> > > >   If the patch is urgent to be merged, I will help add push label
> > > > to merge it with current process.
> > > >
> > > >   If the patch is not urgent, it can be merged after TianoCore
> > > > Code Review is switched from email to GitHub Pull Requests on US 
> > > > Tuesday.
> > > >
> > > > Thanks
> > > > Liming
> > > > > -邮件原件-
> > > > > 发件人: devel@edk2.groups.io  代表 Yao, Jiewen
> > > > > 发送时间: 2024年5月27日 14:43
> > > > > 收件人: Lin, Du ; devel@edk2.groups.io
> > > > > 抄送: Ard Biesheuvel ; Gerd Hoffmann
> > > > > 
> > > > > 主题: Re: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check
> > > > > to
> > > > support
> > > > > new resource attributes
> > > > >
> > > > > I have approved it.
> > > > >
> > > > > What is the proc

Re: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to support new resource attributes

[Yao, Jiewen]

It is out of date again.

When I click rebase, I notice git uses "merge branch". It seems not what we 
want.

I am not sure how to handle it.

Next time, please tell me ASAP once you submit a new PR.


> -Original Message-
> From: Lin, Du 
> Sent: Thursday, May 30, 2024 6:26 PM
> To: Yao, Jiewen ; devel@edk2.groups.io; gaoliming
> 
> Cc: 'Ard Biesheuvel' ; 'Gerd Hoffmann'
> ; Lin, Du 
> Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> support new resource attributes
> 
> Thanks Jiewen. A new PR has been submitted for this:
> https://github.com/tianocore/edk2/pull/5699.
> 
> BRs,
> Lin, Du
> 
> -Original Message-
> From: Yao, Jiewen 
> Sent: Thursday, May 30, 2024 8:00 AM
> To: devel@edk2.groups.io; Yao, Jiewen ; gaoliming
> ; Lin, Du 
> Cc: 'Ard Biesheuvel' ; 'Gerd Hoffmann'
> 
> Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> support new resource attributes
> 
> Lin Du
> Just FYI: The CI failed after I rebase.
> 
> If possible, I recommend to submit a new PR to get it resolved.
> Then I can approve again.
> 
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Yao,
> > Jiewen
> > Sent: Monday, May 27, 2024 3:13 PM
> > To: gaoliming ; devel@edk2.groups.io; Lin,
> > Du 
> > Cc: 'Ard Biesheuvel' ; 'Gerd Hoffmann'
> > 
> > Subject: Re: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check
> > to support new resource attributes
> >
> > Thanks. Not urgent. Let’s wait.
> >
> >
> > > -Original Message-
> > > From: gaoliming 
> > > Sent: Monday, May 27, 2024 3:12 PM
> > > To: devel@edk2.groups.io; Yao, Jiewen ; Lin,
> > > Du 
> > > Cc: 'Ard Biesheuvel' ; 'Gerd Hoffmann'
> > > 
> > > Subject: 回复: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check
> > > to support new resource attributes
> > >
> > > Jiewen:
> > >   If the patch is urgent to be merged, I will help add push label to
> > > merge it with current process.
> > >
> > >   If the patch is not urgent, it can be merged after TianoCore Code
> > > Review is switched from email to GitHub Pull Requests on US Tuesday.
> > >
> > > Thanks
> > > Liming
> > > > -邮件原件-
> > > > 发件人: devel@edk2.groups.io  代表 Yao, Jiewen
> > > > 发送时间: 2024年5月27日 14:43
> > > > 收件人: Lin, Du ; devel@edk2.groups.io
> > > > 抄送: Ard Biesheuvel ; Gerd Hoffmann
> > > > 
> > > > 主题: Re: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> > > support
> > > > new resource attributes
> > > >
> > > > I have approved it.
> > > >
> > > > What is the process to merge? There is no COMMIT button or PUSH label.
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Lin, Du 
> > > > > Sent: Monday, May 27, 2024 2:23 PM
> > > > > To: devel@edk2.groups.io
> > > > > Cc: Ard Biesheuvel ; Gerd Hoffmann
> > > > > ; Yao, Jiewen ; Lin, Du
> > > > > 
> > > > > Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list
> > > > > check to support new resource attributes
> > > > >
> > > > > Thanks for the review and approval. Could you please help merge
> > > > > this
> > > patch to
> > > > > the upstream? A pull request has been created for this patch:
> > > > > https://github.com/tianocore/edk2/pull/5644. Thanks.
> > > > >
> > > > > BRs,
> > > > > Lin, Du
> > > > >
> > > > > -Original Message-
> > > > > From: Yao, Jiewen 
> > > > > Sent: Thursday, May 16, 2024 5:37 PM
> > > > > To: devel@edk2.groups.io; Lin, Du 
> > > > > Cc: Ard Biesheuvel ; Gerd Hoffmann
> > > > > 
> > > > > Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list
> > > > > check to support new resource attributes
> > > > >
> > > > > Reviewed-by: Jiewen Yao 
> > > > >
> > > > > > -Original Message-
> > > > > > From: devel@edk2.groups.io  On Behalf Of
> > > > > > Lin,
> > Du
> > > > > > Sent: Thursday, May 9, 2024 1:27 PM

Re: [edk2-devel] GitHub PR Code Review process now active

[Yao, Jiewen]

Hey
It is great to see what we have moved to PR process finally.

Just tried today, and I confess I made a mistake - I forget to add PUSH label, 
but just click "Rebase and Merge" button directly when I see it. And the patch 
is merged successfully.

Using github native approval and merge process is very common in all other 
projects I have worked on. I am not sure why we still use PUSH label. Should we 
consider to retire it?

Or, if we cannot get rid of PUSH label, then I think we should disable "Rebase 
and Merge" button.
(For me, I cannot help to click the lovely green button when I see it.)

Thank you
Yao, Jiewen


From: devel@edk2.groups.io  On Behalf Of Chang, Abner via 
groups.io
Sent: Wednesday, May 29, 2024 10:48 PM
To: Kinney, Michael D ; devel@edk2.groups.io
Cc: Kinney, Michael D 
Subject: Re: [edk2-devel] GitHub PR Code Review process now active


[AMD Official Use Only - AMD Internal Distribution Only]

Thanks for the clarification, Mike.

Thanks
Abner

From: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Sent: Wednesday, May 29, 2024 10:44:41 PM
To: Chang, Abner mailto:abner.ch...@amd.com>>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
mailto:devel@edk2.groups.io>>
Cc: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: RE: GitHub PR Code Review process now active

[AMD Official Use Only - AMD Internal Distribution Only]

Caution: This message originated from an External Source. Use proper caution 
when opening attachments, clicking links, or responding.


Hi Abner,

Yes.  The plan is to apply to all repos.

We want to use it on edk2 for a while to make sure we get the
settings and process correct, then we will expand.

Mike

> -Original Message-
> From: Chang, Abner mailto:abner.ch...@amd.com>>
> Sent: Wednesday, May 29, 2024 3:41 AM
> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Kinney, Michael D 
> mailto:michael.d.kin...@intel.com>>
> Subject: RE: GitHub PR Code Review process now active
>
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Hi Mike,
> Wondering if we also plan to apply GitHub PR process on edk2-platforms repo?
> Or other repos under tianocore? I found there is another email thread "Enable
> GitHub PR, protected branches, and 'push' label" on edk2-platforms, but no
> further discussions then.
>
> Thanks
> Abner
>
> > -Original Message-
> > From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
> > mailto:devel@edk2.groups.io>> On Behalf Of Michael D
> > Kinney via groups.io
> > Sent: Wednesday, May 29, 2024 2:54 AM
> > To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> > Cc: Kinney, Michael D 
> > mailto:michael.d.kin...@intel.com>>
> > Subject: [edk2-devel] GitHub PR Code Review process now active
> >
> > Caution: This message originated from an External Source. Use proper
> caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > Hello,
> >
> > The GitHub PR code review process is now active.  Please
> > use the new PR based code review process for all new
> > submissions starting today.
> >
> > * The Wiki has been updated with the process changes.
> >
> >   https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
> > Development-Process
> >
> >   Big thanks to Michael Kubacki for writing up all the
> >   changes based on the RFC proposal and community discussions.
> >
> >   We will learn by using, so if you see anything missing or
> >   incorrect or clarifications needed, please send feedback
> >   here so the Wiki pages can be updated quickly for everyone.
> >
> > * The edk2 repo settings have been updated to require
> >   a GitHub PR code review approval before merging and
> >   all conversations must be resolved before merging.
> >
> > * A PR has been opened that removes the requirement for
> >   Cc: tags in the commit messages and is the first PR
> >   that will use the new process. This PR needs to be
> >   reviewed and merged to support the revised commit
> >   message format.
> >
> >   https://github.com/tianocore/edk2/pull/5688
> >
> >   https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-
> > Format
> >
> > * Please use "Draft" PRs to run CI without any reviews.
> >   Once ready for reviews, convert from "Draft" to
> >   "Ready for Review".
> >
> > * For active code reviews that are almost complete and will
> >   be ready for merge in the next few days, the submitter may
> >   choose to either c

Re: [edk2-devel] libspdm Breaking Builds

[Yao, Jiewen]

Thanks Michael Kubacki,

It is merged.

> -Original Message-
> From: Michael Kubacki 
> Sent: Thursday, May 30, 2024 3:57 AM
> To: Kinney, Michael D ; Pete Batard
> ; devel@edk2.groups.io; Yao, Jiewen 
> Subject: Re: [edk2-devel] libspdm Breaking Builds
> 
> Since we already reached agreement in libspdm to move its cmocka
> submodule to the gitlab mirror in
> https://github.com/DMTF/libspdm/issues/2707 and that was merged in
> https://github.com/tianocore/edk2/pull/5697.
> 
> I'd like to suggest we go with option 2 as well. This is impacting our
> ability to use the DeviceSecurity modules. We've currently disabled
> those modules entirely in our local copy of SecurityPkg and disabled the
> libspdm submodule until a more stable solution is in place.
> 
> Here's a PR for option 2.
> 
> https://github.com/tianocore/edk2/pull/5697
> 
> Thanks,
> Michael
> 
> On 5/29/2024 3:40 PM, Kinney, Michael D wrote:
> > Hi Pete,
> >
> > I just tested this config command and it works when cryptomilk is down.
> >
> >  git config --global url."https://github.com/tianocore/edk2-
> cmocka.git".insteadOf "https://git.cryptomilk.org/projects/cmocka.git";
> >
> > I updated edk2-cmocka mirror last week.
> >
> > I tested this with
> >
> >  git clone https://github.com/tianocore/edk2 --recursive
> >
> > Best regards,
> >
> > Mike
> >
> >> -Original Message-
> >> From: Kinney, Michael D 
> >> Sent: Wednesday, May 29, 2024 11:33 AM
> >> To: Pete Batard ; devel@edk2.groups.io; Yao, Jiewen
> >> ; mikub...@linux.microsoft.com
> >> Cc: Kinney, Michael D 
> >> Subject: RE: [edk2-devel] libspdm Breaking Builds
> >>
> >> Hi Pete,
> >>
> >> There is another option for developers and CI agents.
> >>
> >> Git supports a URL insteadof option to redirect git requests.
> >>
> >>  https://git-scm.com/docs/git-config#Documentation/git-config.txt-
> >> urlltbasegtinsteadOf
> >>
> >> We can use this to redirect a request from cryptomilk cmocka to the
> >> TianoCore mirror of cryptomilk cmocka.
> >>
> >> For developers, this can be a global config setting so it works
> >> for all edk2 trees on their system.
> >>
> >> For a CI agent, this could be ab early step in all CI jobs to perform
> >> a git config action.  Perhaps a feature Stuart could adopt to support
> >> URL redirects.
> >>
> >> Mike
> >>
> >>
> >>> -Original Message-
> >>> From: Pete Batard 
> >>> Sent: Wednesday, May 29, 2024 11:18 AM
> >>> To: devel@edk2.groups.io; Yao, Jiewen ; Kinney,
> >> Michael
> >>> D ; mikub...@linux.microsoft.com
> >>> Subject: Re: [edk2-devel] libspdm Breaking Builds
> >>>
> >>> Hello all,
> >>>
> >>> On 2024.05.24 03:13, Yao, Jiewen via groups.io wrote:
> >>>> Please let us know if the preference for libspdm submodule. (Below
> >> options)
> >>>> 1) Keep current libspdm official 3.3.0 release, and update to next
> >> release
> >>> at the beginning of July.
> >>>> 2) Update libspdm immediately with the new cmocka submodule, which is
> NOT
> >>> an official release.
> >>>
> >>> Considering that I (and I expect anybody who tries to use EDK2 as a
> >>> submodule in their UEFI build projects with GitHub Actions), I have to
> >>> vote for option 2.
> >>>
> >>> An example of the current issue can be shown on a project that simply
> >>> attempts to build the UEFI Shell from the latest stable EDK2 release,
> >>> using EDK2 as a submodule, can be shown at
> >>> https://github.com/pbatard/UEFI-
> >> Shell/actions/runs/9290685065/job/25567879807
> >>> or
> >>> https://github.com/pbatard/UEFI-
> >> Shell/actions/runs/9290988138/job/25568511355
> >>> and as you can see, it makes building the project completely impossible
> >>> unless you ditch using EDK2 as a submodule (which isn't a viable option
> >>> IMO, because a build toolchain that cannot be used as a git submodule is
> >>> a very limiting toolchain).
> >>>
> >>> For information, there's only so much fine grained tuning GitHub Actions
> >>> offers on submodules, and no matter how you try to play with the fetch
> >>> depth, the fact that one of the libspdm sub-dependency has essentially
> >>> become M.I.A. is something that should be addressed as a matter of 
> >>> urgency.
> >>>
> >>> So I hope that a commit that updates libspdm to the new cmocka submodule
> >>> can find its way into EDK2 fairly soon, as it is currently halting a
> >>> projects that aims at producing trusted UEFI Shell releases.
> >>>
> >>> Regards,
> >>>
> >>> /Pete


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119370): https://edk2.groups.io/g/devel/message/119370
Mute This Topic: https://groups.io/mt/106250971/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: Update VMM Hob list check to support new resource attributes

[Yao, Jiewen]

Lin Du
Just FYI: The CI failed after I rebase.

If possible, I recommend to submit a new PR to get it resolved.
Then I can approve again.


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Yao, Jiewen
> Sent: Monday, May 27, 2024 3:13 PM
> To: gaoliming ; devel@edk2.groups.io; Lin, Du
> 
> Cc: 'Ard Biesheuvel' ; 'Gerd Hoffmann'
> 
> Subject: Re: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> support new resource attributes
> 
> Thanks. Not urgent. Let’s wait.
> 
> 
> > -Original Message-
> > From: gaoliming 
> > Sent: Monday, May 27, 2024 3:12 PM
> > To: devel@edk2.groups.io; Yao, Jiewen ; Lin, Du
> > 
> > Cc: 'Ard Biesheuvel' ; 'Gerd Hoffmann'
> > 
> > Subject: 回复: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> > support new resource attributes
> >
> > Jiewen:
> >   If the patch is urgent to be merged, I will help add push label to merge
> > it with current process.
> >
> >   If the patch is not urgent, it can be merged after TianoCore Code Review
> > is switched from email to GitHub Pull Requests on US Tuesday.
> >
> > Thanks
> > Liming
> > > -邮件原件-
> > > 发件人: devel@edk2.groups.io  代表 Yao, Jiewen
> > > 发送时间: 2024年5月27日 14:43
> > > 收件人: Lin, Du ; devel@edk2.groups.io
> > > 抄送: Ard Biesheuvel ; Gerd Hoffmann
> > > 
> > > 主题: Re: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> > support
> > > new resource attributes
> > >
> > > I have approved it.
> > >
> > > What is the process to merge? There is no COMMIT button or PUSH label.
> > >
> > >
> > > > -Original Message-
> > > > From: Lin, Du 
> > > > Sent: Monday, May 27, 2024 2:23 PM
> > > > To: devel@edk2.groups.io
> > > > Cc: Ard Biesheuvel ; Gerd Hoffmann
> > > > ; Yao, Jiewen ; Lin, Du
> > > > 
> > > > Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> > > > support new resource attributes
> > > >
> > > > Thanks for the review and approval. Could you please help merge this
> > patch to
> > > > the upstream? A pull request has been created for this patch:
> > > > https://github.com/tianocore/edk2/pull/5644. Thanks.
> > > >
> > > > BRs,
> > > > Lin, Du
> > > >
> > > > -Original Message-
> > > > From: Yao, Jiewen 
> > > > Sent: Thursday, May 16, 2024 5:37 PM
> > > > To: devel@edk2.groups.io; Lin, Du 
> > > > Cc: Ard Biesheuvel ; Gerd Hoffmann
> > > > 
> > > > Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> > > > support new resource attributes
> > > >
> > > > Reviewed-by: Jiewen Yao 
> > > >
> > > > > -Original Message-
> > > > > From: devel@edk2.groups.io  On Behalf Of Lin,
> Du
> > > > > Sent: Thursday, May 9, 2024 1:27 PM
> > > > > To: devel@edk2.groups.io
> > > > > Cc: Lin, Du ; Ard Biesheuvel
> > > > > ; Gerd Hoffmann ;
> Yao,
> > > > > Jiewen 
> > > > > Subject: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> > > > > support new resource attributes
> > > > >
> > > > > Encrypted and Special Purpose resource attributes are introduced in PI
> > > > > 1.8 Specification. This patch is to update VMM Hob list integrity
> > > > > check to recognise these resource attributes.
> > > > >
> > > > > Cc: Ard Biesheuvel 
> > > > > Cc: Gerd Hoffmann 
> > > > > Cc: Jiewen Yao 
> > > > > Signed-off-by: Du Lin 
> > > > > ---
> > > > >  OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c | 2 ++
> > > > >  1 file changed, 2 insertions(+)
> > > > >
> > > > > diff --git a/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> > > > > b/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> > > > > index b6085eab44..19e9b1bf54 100644
> > > > > --- a/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> > > > > +++ b/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> > > > > @@ -643,6 +643,8 @@ ValidateHobList (
> > > > >
> > > > > EFI_RESOURCE_ATTRIBUTE_PERSISTABLE |
> > > > >
> > > > > EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTED |
> > > > >
> > > > > EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTABLE |
> > > > > +
> > > > > + EFI_RESOURCE_ATTRIBUTE_ENCRYPTED|
> > > > > +
> > > > > EFI_RESOURCE_ATTRIBUTE_SPECIAL_PURPOSE |
> > > > >
> > > > > EFI_RESOURCE_ATTRIBUTE_MORE_RELIABLE))) != 0)
> > > > >  {
> > > > >DEBUG ((DEBUG_ERROR, "HOB: Unknow ResourceDescriptor
> > > > > ResourceAttribute type. Type: 0x%08x\n", Hob.ResourceDescriptor-
> > > > > >ResourceAttribute));
> > > > > --
> > > > > 2.44.0.windows.1
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119368): https://edk2.groups.io/g/devel/message/119368
Mute This Topic: https://groups.io/mt/106379971/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: Update VMM Hob list check to support new resource attributes

[Yao, Jiewen]

Thanks. Not urgent. Let’s wait.


> -Original Message-
> From: gaoliming 
> Sent: Monday, May 27, 2024 3:12 PM
> To: devel@edk2.groups.io; Yao, Jiewen ; Lin, Du
> 
> Cc: 'Ard Biesheuvel' ; 'Gerd Hoffmann'
> 
> Subject: 回复: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> support new resource attributes
> 
> Jiewen:
>   If the patch is urgent to be merged, I will help add push label to merge
> it with current process.
> 
>   If the patch is not urgent, it can be merged after TianoCore Code Review
> is switched from email to GitHub Pull Requests on US Tuesday.
> 
> Thanks
> Liming
> > -邮件原件-
> > 发件人: devel@edk2.groups.io  代表 Yao, Jiewen
> > 发送时间: 2024年5月27日 14:43
> > 收件人: Lin, Du ; devel@edk2.groups.io
> > 抄送: Ard Biesheuvel ; Gerd Hoffmann
> > 
> > 主题: Re: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> support
> > new resource attributes
> >
> > I have approved it.
> >
> > What is the process to merge? There is no COMMIT button or PUSH label.
> >
> >
> > > -Original Message-
> > > From: Lin, Du 
> > > Sent: Monday, May 27, 2024 2:23 PM
> > > To: devel@edk2.groups.io
> > > Cc: Ard Biesheuvel ; Gerd Hoffmann
> > > ; Yao, Jiewen ; Lin, Du
> > > 
> > > Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> > > support new resource attributes
> > >
> > > Thanks for the review and approval. Could you please help merge this
> patch to
> > > the upstream? A pull request has been created for this patch:
> > > https://github.com/tianocore/edk2/pull/5644. Thanks.
> > >
> > > BRs,
> > > Lin, Du
> > >
> > > -Original Message-
> > > From: Yao, Jiewen 
> > > Sent: Thursday, May 16, 2024 5:37 PM
> > > To: devel@edk2.groups.io; Lin, Du 
> > > Cc: Ard Biesheuvel ; Gerd Hoffmann
> > > 
> > > Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> > > support new resource attributes
> > >
> > > Reviewed-by: Jiewen Yao 
> > >
> > > > -Original Message-
> > > > From: devel@edk2.groups.io  On Behalf Of Lin, Du
> > > > Sent: Thursday, May 9, 2024 1:27 PM
> > > > To: devel@edk2.groups.io
> > > > Cc: Lin, Du ; Ard Biesheuvel
> > > > ; Gerd Hoffmann ; Yao,
> > > > Jiewen 
> > > > Subject: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> > > > support new resource attributes
> > > >
> > > > Encrypted and Special Purpose resource attributes are introduced in PI
> > > > 1.8 Specification. This patch is to update VMM Hob list integrity
> > > > check to recognise these resource attributes.
> > > >
> > > > Cc: Ard Biesheuvel 
> > > > Cc: Gerd Hoffmann 
> > > > Cc: Jiewen Yao 
> > > > Signed-off-by: Du Lin 
> > > > ---
> > > >  OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> > > > b/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> > > > index b6085eab44..19e9b1bf54 100644
> > > > --- a/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> > > > +++ b/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> > > > @@ -643,6 +643,8 @@ ValidateHobList (
> > > >
> > > > EFI_RESOURCE_ATTRIBUTE_PERSISTABLE |
> > > >
> > > > EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTED |
> > > >
> > > > EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTABLE |
> > > > +
> > > > + EFI_RESOURCE_ATTRIBUTE_ENCRYPTED|
> > > > +
> > > > EFI_RESOURCE_ATTRIBUTE_SPECIAL_PURPOSE |
> > > >
> > > > EFI_RESOURCE_ATTRIBUTE_MORE_RELIABLE))) != 0)
> > > >  {
> > > >DEBUG ((DEBUG_ERROR, "HOB: Unknow ResourceDescriptor
> > > > ResourceAttribute type. Type: 0x%08x\n", Hob.ResourceDescriptor-
> > > > >ResourceAttribute));
> > > > --
> > > > 2.44.0.windows.1
> > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> > 
> >
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119278): https://edk2.groups.io/g/devel/message/119278
Mute This Topic: https://groups.io/mt/106326545/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: Update VMM Hob list check to support new resource attributes

[Yao, Jiewen]

I have approved it.

What is the process to merge? There is no COMMIT button or PUSH label.


> -Original Message-
> From: Lin, Du 
> Sent: Monday, May 27, 2024 2:23 PM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Gerd Hoffmann
> ; Yao, Jiewen ; Lin, Du
> 
> Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> support new resource attributes
> 
> Thanks for the review and approval. Could you please help merge this patch to
> the upstream? A pull request has been created for this patch:
> https://github.com/tianocore/edk2/pull/5644. Thanks.
> 
> BRs,
> Lin, Du
> 
> -Original Message-
> From: Yao, Jiewen 
> Sent: Thursday, May 16, 2024 5:37 PM
> To: devel@edk2.groups.io; Lin, Du 
> Cc: Ard Biesheuvel ; Gerd Hoffmann
> 
> Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> support new resource attributes
> 
> Reviewed-by: Jiewen Yao 
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Lin, Du
> > Sent: Thursday, May 9, 2024 1:27 PM
> > To: devel@edk2.groups.io
> > Cc: Lin, Du ; Ard Biesheuvel
> > ; Gerd Hoffmann ; Yao,
> > Jiewen 
> > Subject: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to
> > support new resource attributes
> >
> > Encrypted and Special Purpose resource attributes are introduced in PI
> > 1.8 Specification. This patch is to update VMM Hob list integrity
> > check to recognise these resource attributes.
> >
> > Cc: Ard Biesheuvel 
> > Cc: Gerd Hoffmann 
> > Cc: Jiewen Yao 
> > Signed-off-by: Du Lin 
> > ---
> >  OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> > b/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> > index b6085eab44..19e9b1bf54 100644
> > --- a/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> > +++ b/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> > @@ -643,6 +643,8 @@ ValidateHobList (
> >
> > EFI_RESOURCE_ATTRIBUTE_PERSISTABLE |
> >
> > EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTED |
> >
> > EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTABLE |
> > +
> > + EFI_RESOURCE_ATTRIBUTE_ENCRYPTED|
> > +
> > EFI_RESOURCE_ATTRIBUTE_SPECIAL_PURPOSE |
> >
> > EFI_RESOURCE_ATTRIBUTE_MORE_RELIABLE))) != 0)
> >  {
> >DEBUG ((DEBUG_ERROR, "HOB: Unknow ResourceDescriptor
> > ResourceAttribute type. Type: 0x%08x\n", Hob.ResourceDescriptor-
> > >ResourceAttribute));
> > --
> > 2.44.0.windows.1
> >
> >
> >
> > 
> >



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119276): https://edk2.groups.io/g/devel/message/119276
Mute This Topic: https://groups.io/mt/105996363/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 07/20] SecurityPkg: RngDxe: Remove incorrect limitation on GetRng

[Yao, Jiewen]

Acked-by: Jiewe Yao 

BTW: This patch is already got RB from below people. I suggest you can put them 
in commit directly.

Reviewed-by: Pierre Gondois 
Reviewed-by: Ard Biesheuvel 

Thank you
Yao, Jiewen

> -Original Message-
> From: Flickdm 
> Sent: Friday, May 24, 2024 1:45 PM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen 
> Subject: [PATCH v3 07/20] SecurityPkg: RngDxe: Remove incorrect limitation on
> GetRng
> 
> Removed from gEfiRngAlgorithmRaw an incorrect assumption that
> Raw cannot return less than 256 bits. The DRNG Algorithms
> should always use a 256 bit seed as per nist standards
> however a caller is free to request less than 256 bits.
> >
> > //
> >// When a DRBG is used on the output of a entropy source,
> >// its security level must be at least 256 bits according to UEFI
> Spec.
> >//
> >if (RNGValueLength < 32) {
> >  return EFI_INVALID_PARAMETER;
> >}
> >
> 
> AARCH64 platforms do not have this limitation and this brings both
> implementations into alignment with each other and the spec.
> 
> Cc: Jiewen Yao 
> 
> Signed-off-by: Doug Flick [MSFT] 
> Reviewed-by: Ard Biesheuvel 
> ---
>  SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c | 8 
>  1 file changed, 8 deletions(-)
> 
> diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
> b/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
> index 7e06e16e4b..5723ed6957 100644
> --- a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
> +++ b/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
> @@ -116,14 +116,6 @@ RngGetRNG (
>// The "raw" algorithm is intended to provide entropy directly
> 
>//
> 
>if (CompareGuid (RNGAlgorithm, &gEfiRngAlgorithmRaw)) {
> 
> -//
> 
> -// When a DRBG is used on the output of a entropy source,
> 
> -// its security level must be at least 256 bits according to UEFI Spec.
> 
> -//
> 
> -if (RNGValueLength < 32) {
> 
> -  return EFI_INVALID_PARAMETER;
> 
> -}
> 
> -
> 
>  Status = GenerateEntropy (RNGValueLength, RNGValue);
> 
>  return Status;
> 
>}
> 
> --
> 2.34.1



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

Re: [edk2-devel] libspdm Breaking Builds

[Yao, Jiewen]

Hello
Thanks for Michael Kubacki's effort. The cmocka for libspdm is switched to 
https://gitlab.com/cmocka/cmocka.git 
(https://github.com/DMTF/libspdm/pull/2710).

The next libspdm release is planned at the end of June.

Please let us know if the preference for libspdm submodule. (Below options)
1) Keep current libspdm official 3.3.0 release, and update to next release at 
the beginning of July.
2) Update libspdm immediately with the new cmocka submodule, which is NOT an 
official release.


Thank you
Yao, Jiewen

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Yao, Jiewen
> Sent: Thursday, May 23, 2024 10:17 AM
> To: Kinney, Michael D ; devel@edk2.groups.io;
> mikub...@linux.microsoft.com
> Subject: Re: [edk2-devel] libspdm Breaking Builds
> 
> Hello
> I am sorry to bring the inconvenience.
> I think the libspdm maintainers are aware of fact that the breaking of cmoka
> impacts the CI.
> 
> In history of libspdm, we did see this sometimes, but usually it was back 
> online
> after a while.
> That is the reason libspdm project is still using cmoka github, since it is 
> good at
> most of time.
> 
> I will discuss libspdm/cmoka issue in regular SPDM TF meeting, and update the
> issue https://github.com/DMTF/libspdm/issues/2707.
> 
> 
> It is similar to what I have observed in tianocore project. Tianocore CI 
> breaks
> sometimes, and works again after a while. But that is NOT a reason to disable 
> it.
> 
> Anyway, I think tianocore project has freedom to choose whatever options,
> independent with libspdm project. And I hope we have a consistent way to 
> handle
> all projects.
> 
> Thank you
> Yao, Jiewen
> 
> 
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Thursday, May 23, 2024 9:52 AM
> > To: devel@edk2.groups.io; mikub...@linux.microsoft.com; Yao, Jiewen
> > 
> > Cc: Kinney, Michael D 
> > Subject: RE: [edk2-devel] libspdm Breaking Builds
> >
> > We have a mirror of cmocka in tianocore.
> >
> > https://github.com/tianocore/edk2-cmocka
> >
> > It is out of sync because GitHub keep disabling the workflow.
> >
> > And the workflow can not run until cmocka repo is back up.
> >
> > We updated UnitTestFrameworkPkg to use tianocore cmocka mirror long ago
> > for this exact failure case.
> >
> > Since we do not have control over libspdm submodule link to cmocka, what
> > we need is an override or a failover submodule link to tianocore mirror.
> >
> > Any ideas on how to implement that concept.  Does git have failover or
> > override URL for git submodules?
> >
> > Or do we need more stuart feature to have more fine grain control over
> > Submodules?
> >
> > Mike
> >
> > > -Original Message-
> > > From: devel@edk2.groups.io  On Behalf Of Michael
> > > Kubacki
> > > Sent: Wednesday, May 22, 2024 6:04 PM
> > > To: Kinney, Michael D ; devel@edk2.groups.io;
> > > Yao, Jiewen 
> > > Subject: Re: [edk2-devel] libspdm Breaking Builds
> > >
> > > We looked at Stuart and it can prevent a recursive submodule update at
> > > the first level but then it would prevent further updates. Here Repo A
> > > can prevent a recursive update in edk2 but it would then not be able to
> > > get libspdm.
> > >
> > >[Repo A] -[1]> [edk2] -[2]> [libspdm] -[3]> [cmocka]
> > >
> > > At its root, the issue is that this is broken, not wasteful. Therefore,
> > > it is disruptive and a regression for existing workflows.
> > >
> > > We, and I'm sure many other projects, recursively clone packages in edk2
> > > with submodules. For years, this has been fine except for a few brief
> > > exceptions. We pulled the change with the libspdm dependency into our
> > > codebase 8 days ago and this has been broken all day. The track record
> > > of cryptomilk.org in the past was also very poor and frequently caused
> > > problems. There is not an incident response team that I'm aware of at
> > > cryptomilk.org that provides status updates and proactively addresses
> > > services issues (i.e. https://www.githubstatus.com/).
> > >
> > > Also, libspdm is now a dependency and cloning cmocka there may fail.
> > > Users should expect that they can clone and work in that repo as part of
> > > their firmware development process without frequent service disruptions
> > > in the way.
> > >
> > > While I started this thread to raise the issue for users impacted here,
> > > I filed https://g

Re: [edk2-devel] libspdm Breaking Builds

[Yao, Jiewen]

Hello
I am sorry to bring the inconvenience.
I think the libspdm maintainers are aware of fact that the breaking of cmoka 
impacts the CI.

In history of libspdm, we did see this sometimes, but usually it was back 
online after a while. 
That is the reason libspdm project is still using cmoka github, since it is 
good at most of time.

I will discuss libspdm/cmoka issue in regular SPDM TF meeting, and update the 
issue https://github.com/DMTF/libspdm/issues/2707.


It is similar to what I have observed in tianocore project. Tianocore CI breaks 
sometimes, and works again after a while. But that is NOT a reason to disable 
it.

Anyway, I think tianocore project has freedom to choose whatever options, 
independent with libspdm project. And I hope we have a consistent way to handle 
all projects.

Thank you
Yao, Jiewen


> -Original Message-
> From: Kinney, Michael D 
> Sent: Thursday, May 23, 2024 9:52 AM
> To: devel@edk2.groups.io; mikub...@linux.microsoft.com; Yao, Jiewen
> 
> Cc: Kinney, Michael D 
> Subject: RE: [edk2-devel] libspdm Breaking Builds
> 
> We have a mirror of cmocka in tianocore.
> 
>   https://github.com/tianocore/edk2-cmocka
> 
> It is out of sync because GitHub keep disabling the workflow.
> 
> And the workflow can not run until cmocka repo is back up.
> 
> We updated UnitTestFrameworkPkg to use tianocore cmocka mirror long ago
> for this exact failure case.
> 
> Since we do not have control over libspdm submodule link to cmocka, what
> we need is an override or a failover submodule link to tianocore mirror.
> 
> Any ideas on how to implement that concept.  Does git have failover or
> override URL for git submodules?
> 
> Or do we need more stuart feature to have more fine grain control over
> Submodules?
> 
> Mike
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Michael
> > Kubacki
> > Sent: Wednesday, May 22, 2024 6:04 PM
> > To: Kinney, Michael D ; devel@edk2.groups.io;
> > Yao, Jiewen 
> > Subject: Re: [edk2-devel] libspdm Breaking Builds
> >
> > We looked at Stuart and it can prevent a recursive submodule update at
> > the first level but then it would prevent further updates. Here Repo A
> > can prevent a recursive update in edk2 but it would then not be able to
> > get libspdm.
> >
> >[Repo A] -[1]> [edk2] -[2]> [libspdm] -[3]> [cmocka]
> >
> > At its root, the issue is that this is broken, not wasteful. Therefore,
> > it is disruptive and a regression for existing workflows.
> >
> > We, and I'm sure many other projects, recursively clone packages in edk2
> > with submodules. For years, this has been fine except for a few brief
> > exceptions. We pulled the change with the libspdm dependency into our
> > codebase 8 days ago and this has been broken all day. The track record
> > of cryptomilk.org in the past was also very poor and frequently caused
> > problems. There is not an incident response team that I'm aware of at
> > cryptomilk.org that provides status updates and proactively addresses
> > services issues (i.e. https://www.githubstatus.com/).
> >
> > Also, libspdm is now a dependency and cloning cmocka there may fail.
> > Users should expect that they can clone and work in that repo as part of
> > their firmware development process without frequent service disruptions
> > in the way.
> >
> > While I started this thread to raise the issue for users impacted here,
> > I filed https://github.com/DMTF/libspdm/issues/2707 to track the request
> > in the libspdm repo.
> >
> > Thanks,
> > Michael
> >
> > On 5/22/2024 6:24 PM, Kinney, Michael D wrote:
> > > Libspdm also depends on openssl.  We did not want to clone openssl twice.
> > >
> > > I though stuart config specifies which submodules to clone.  Can’t we skip
> > > all the submodules within libspdm to fix CI?
> > >
> > > Can't devs choose to not use --recursive?
> > >
> > > Mike
> > >
> > >> -Original Message-
> > >> From: Michael Kubacki 
> > >> Sent: Wednesday, May 22, 2024 3:16 PM
> > >> To: devel@edk2.groups.io; Kinney, Michael D
> ;
> > >> Yao, Jiewen 
> > >> Subject: Re: [edk2-devel] libspdm Breaking Builds
> > >>
> > >> I don't think that's a very good solution given the diversity of
> > >> downstream projects dependent on the repo or even for the libspdm repo
> > >> itself.
> > >>
> > >> Thanks,
> > >> Michael
> > >>
> > >> On 

Re: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to support new resource attributes

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Lin, Du
> Sent: Thursday, May 9, 2024 1:27 PM
> To: devel@edk2.groups.io
> Cc: Lin, Du ; Ard Biesheuvel ;
> Gerd Hoffmann ; Yao, Jiewen 
> Subject: [edk2-devel] [PATCH] OvmfPkg: Update VMM Hob list check to support
> new resource attributes
> 
> Encrypted and Special Purpose resource attributes are introduced in
> PI 1.8 Specification. This patch is to update VMM Hob list integrity
> check to recognise these resource attributes.
> 
> Cc: Ard Biesheuvel 
> Cc: Gerd Hoffmann 
> Cc: Jiewen Yao 
> Signed-off-by: Du Lin 
> ---
>  OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> b/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> index b6085eab44..19e9b1bf54 100644
> --- a/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> +++ b/OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
> @@ -643,6 +643,8 @@ ValidateHobList (
>  
> EFI_RESOURCE_ATTRIBUTE_PERSISTABLE |
> 
> EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTED |
> 
> EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTABLE |
> +
> EFI_RESOURCE_ATTRIBUTE_ENCRYPTED|
> +
> EFI_RESOURCE_ATTRIBUTE_SPECIAL_PURPOSE |
> 
> EFI_RESOURCE_ATTRIBUTE_MORE_RELIABLE))) != 0)
>  {
>DEBUG ((DEBUG_ERROR, "HOB: Unknow ResourceDescriptor
> ResourceAttribute type. Type: 0x%08x\n", Hob.ResourceDescriptor-
> >ResourceAttribute));
> --
> 2.44.0.windows.1
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118955): https://edk2.groups.io/g/devel/message/118955
Mute This Topic: https://groups.io/mt/105996363/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 07/13] SecurityPkg: RngDxe: Remove incorrect limitation on GetRng

[Yao, Jiewen]

Thanks to confirm that.
I am OK on what you have said.

Since the ARM part is added by Pierre Gondois 
pierre.gond...@arm.com<mailto:pierre.gond...@arm.com>, I will let him comment 
if there is any concern on the change for ARM.

Thank you
Yao, Jiewen


From: Doug Flick via groups.io 
Sent: Saturday, May 11, 2024 5:12 AM
To: Yao, Jiewen ; devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH v2 07/13] SecurityPkg: RngDxe: Remove 
incorrect limitation on GetRng


So, I'm trying to consult with some RNG experts because I'm by no means an 
expert and anything I say should be taken with huge grain of salt. When I get 
the experts take, I'll share it.

Basically, the way I read this code is that it by no means tries to enforce any 
entropy requirement outside of what you ask for.

My understanding is the 256 Bit Entropy requirements comes from when you are 
using a DRNG algorithm such as:

#define EFI_RNG_ALGORITHM_SP800_90_HASH_256_GUID \

 {0xa7af67cb, 0x603b, 0x4d42,\

 {0xba, 0x21, 0x70, 0xbf, 0xb6, 0x29, 0x3f, 0x96}}



#define EFI_RNG_ALGORITHM_SP800_90_HMAC_256_GUID \

 {0xc5149b43, 0xae85, 0x4f53,\

 {0x99, 0x82, 0xb9, 0x43, 0x35, 0xd3, 0xa9, 0xe7}}



#define EFI_RNG_ALGORITHM_SP800_90_CTR_256_GUID \

 {0x44f0de6e, 0x4d8c, 0x4045, \

 {0xa8, 0xc7, 0x4d, 0xd1, 0x68, 0x85, 0x6b, 0x9e}}

"When a Deterministic Random Bit Generator (DRBG) is used on the output of a 
(raw) entropy source, its security level must be at least 256 bits."

https://uefi.org/specs/UEFI/2.10/37_Secure_Technologies.html#random-number-generator-protocol

That is, the seed of these algorithms must be at a minimum 256 bits from your 
entropy source.

Now when you call for instance EFI_RNG_ALGORITHM_SP800_90_CTR_256_GUID

On an INTEL CPU it uses the Intel RDRAND Instruction

https://github.com/tianocore/edk2/blob/4b6ee06a090d956f80b4a92fb9bf03098a372f39/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c#L108C45-L108C51

Which from what I can tell the generator takes pairs of 256-bit raw entropy 
samples generated by the hardware entropy source and applies them to an 
Advanced Encryption Standard (AES) (in CBC-MAC mode) conditioner which reduces 
them to a single 256-bit conditioned entropy sample.

https://en.wikipedia.org/wiki/RDRAND

https://www.intel.com/content/www/us/en/developer/articles/guide/intel-digital-random-number-generator-drng-software-implementation-guide.html

Which means, if you are implementing these algorithms in software, you must 
comply with the 256 bit entropy requirement for your source. However in our 
case the CPU is performing that requirement for us.

Again I'm no expert. So if an expert is reading this and I'm completely wrong 
please let me know :)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118828): https://edk2.groups.io/g/devel/message/118828
Mute This Topic: https://groups.io/mt/105996584/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 07/13] SecurityPkg: RngDxe: Remove incorrect limitation on GetRng

[Yao, Jiewen]

Hi Doug
First, I agree with you that "A caller is free to request less than 256 bit".

Second, I think we still need to meet 256 bit entropy requirement in UEFI spec, 
right?
With above assumption, I checked how the callee is implemented when input 
length is small.

https://github.com/tianocore/edk2/blob/master/SecurityPkg/RandomNumberGenerator/RngDxe/ArmTrng.c#L54-L59

EntropyBits = MIN ((RequiredEntropyBits - CollectedEntropyBits), MaxBits);
Status  = GetArmTrngEntropy (
EntropyBits,
(Length - Index),
&Entropy[Index]
);

It seems to me that the EntropyBits is also less than 256, when the input 
requirement is less than 256 bit.

Would you please double check that, to see if the requirement is still 
satisfied?
Please correct me if my understanding is wrong.


Thank you
Yao, Jiewen



> -Original Message-
> From: Doug Flick 
> Sent: Thursday, May 9, 2024 1:56 PM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen 
> Subject: [PATCH v2 07/13] SecurityPkg: RngDxe: Remove incorrect limitation on
> GetRng
> 
> Removed from gEfiRngAlgorithmRaw an incorrect assumption that
> Raw cannot return less than 256 bits. The DRNG Algorithms
> should always use a 256 bit seed as per nist standards
> however a caller is free to request less than 256 bits.
> >
> > //
> >// When a DRBG is used on the output of a entropy source,
> >// its security level must be at least 256 bits according to UEFI Spec.
> >//
> >if (RNGValueLength < 32) {
> >  return EFI_INVALID_PARAMETER;
> >}
> >
> 
> AARCH64 platforms do not have this limitation and this brings both
> implementations into alignment with each other and the spec.
> 
> Cc: Jiewen Yao 
> 
> Signed-off-by: Doug Flick [MSFT] 
> ---
>  SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c | 8 
>  1 file changed, 8 deletions(-)
> 
> diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
> b/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
> index 7e06e16e4be5..5723ed695747 100644
> --- a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
> +++ b/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
> @@ -116,14 +116,6 @@ RngGetRNG (
>// The "raw" algorithm is intended to provide entropy directly
> 
>//
> 
>if (CompareGuid (RNGAlgorithm, &gEfiRngAlgorithmRaw)) {
> 
> -//
> 
> -// When a DRBG is used on the output of a entropy source,
> 
> -// its security level must be at least 256 bits according to UEFI Spec.
> 
> -//
> 
> -if (RNGValueLength < 32) {
> 
> -  return EFI_INVALID_PARAMETER;
> 
> -}
> 
> -
> 
>  Status = GenerateEntropy (RNGValueLength, RNGValue);
> 
>  return Status;
> 
>}
> 
> --
> 2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118811): https://edk2.groups.io/g/devel/message/118811
Mute This Topic: https://groups.io/mt/105996584/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 00/11] Add more crypt APIs based on Mbedtls

[Yao, Jiewen]

Acked-by: Jiewen Yao 

> -Original Message-
> From: Li, Yi1 
> Sent: Thursday, May 9, 2024 4:33 PM
> To: Hou, Wenxing ; gaoliming
> ; devel@edk2.groups.io
> Cc: Yao, Jiewen 
> Subject: RE: [PATCH v3 00/11] Add more crypt APIs based on Mbedtls
> 
> This patch set was submitted before soft freeze and will not affect other 
> existed
> codes, I am OK to merge it.
> 
> Hi Liming,
> 
> Do you have any comments?  I will merge it if no objections.
> 
> Thanks,
> Yi
> 
> -Original Message-
> From: Hou, Wenxing 
> Sent: Thursday, May 9, 2024 4:29 PM
> To: Li, Yi1 ; devel@edk2.groups.io
> Cc: Yao, Jiewen ; gaoliming
> 
> Subject: RE: [PATCH v3 00/11] Add more crypt APIs based on Mbedtls
> 
> Hi,
> 
> Thanks for your feedback.
> The new PR is: https://github.com/tianocore/edk2/pull/5645
> 
> Could Li Yi help me merge the PR?
> 
> Thanks,
> Wenxing
> 
> -Original Message-
> From: Li, Yi1 
> Sent: Thursday, May 9, 2024 2:54 PM
> To: Hou, Wenxing ; devel@edk2.groups.io
> Cc: Yao, Jiewen 
> Subject: RE: [PATCH v3 00/11] Add more crypt APIs based on Mbedtls
> 
> For this patch set:
> 
> Looks good to me.
> Reviewed-by: Yi Li 
> 
> 
> -Original Message-
> From: Hou, Wenxing 
> Sent: Thursday, May 9, 2024 2:27 PM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen ; Li, Yi1 
> Subject: [PATCH v3 00/11] Add more crypt APIs based on Mbedtls
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4177
> 
> Add AeadAesGcm/Pem(only RSA)/X509(only RSA)/More
> RSA/PKCS5/pKCS7/Authenticode/Timestamp
> implementation based on Mbedtls.
> 
> The patch has passed the EDKII CI check:
> https://github.com/tianocore/edk2/pull/5552
> 
> And the patch has passed unit_test in EDKII and integration test for platform.
> And the patch hass passed the fuzz test:
> https://github.com/tianocore/edk2-
> staging/commit/4f19398053c92e4f7791d468a184530b6ab89128
> 
> v2 changes:
>  - Fix format variable name/hardcode number issue;
>  - Fix Pkcs7 memory leak;
> 
> v3 changes:
>  - Fix some issues form reviewer;
>  - Add SHA3/SM3 implementation;
>  - Update *.inf files;
> 
> Cc: Jiewen Yao 
> Cc: Yi Li 
> Signed-off-by: Wenxing Hou 
> 
> Wenxing Hou (11):
>   CryptoPkg: Add AeadAesGcm based on Mbedtls
>   CryptoPkg: Add rand function for BaseCryptLibMbedTls
>   CryptoPkg: Add Pem APIs based on Mbedtls
>   CryptoPkg: Add X509 functions based on Mbedtls
>   CryptoPkg: Add Pkcs7 related functions based on Mbedtls
>   CryptoPkg: Add Pkcs5 functions based on Mbedtls
>   CryptoPkg: Add more RSA related functions based on Mbedtls
>   CryptoPkg: Add AuthenticodeVerify based on Mbedtls
>   CryptoPkg: Add ImageTimestampVerify based on Mbedtls
>   CryptoPkg: Update *.inf in BaseCryptLibMbedTls
>   Add SHA3/SM3 functions with openssl for Mbedtls
> 
>  CryptoPkg/Include/Library/BaseCryptLib.h  |4 +
>  .../BaseCryptLibMbedTls/BaseCryptLib.inf  |   47 +-
>  .../Cipher/CryptAeadAesGcm.c  |  227 ++
>  .../BaseCryptLibMbedTls/InternalCryptLib.h|   49 +
>  .../BaseCryptLibMbedTls/PeiCryptLib.inf   |   27 +-
>  .../BaseCryptLibMbedTls/Pem/CryptPem.c|  138 ++
>  .../Pk/CryptAuthenticode.c|  214 ++
>  .../BaseCryptLibMbedTls/Pk/CryptPkcs1Oaep.c   |  278 +++
>  .../BaseCryptLibMbedTls/Pk/CryptPkcs5Pbkdf2.c |  100 +
>  .../Pk/CryptPkcs7Internal.h   |   29 +-
>  .../BaseCryptLibMbedTls/Pk/CryptPkcs7Sign.c   |  635 ++
>  .../Pk/CryptPkcs7VerifyBase.c |  113 +
>  .../Pk/CryptPkcs7VerifyCommon.c   | 1354 
>  .../Pk/CryptPkcs7VerifyEku.c  |  689 ++
>  .../BaseCryptLibMbedTls/Pk/CryptRsaExt.c  |  352 +++
>  .../BaseCryptLibMbedTls/Pk/CryptRsaPssSign.c  |  140
> ++  .../Library/BaseCryptLibMbedTls/Pk/CryptTs.c  |  381 
>  .../BaseCryptLibMbedTls/Pk/CryptX509.c| 1940 +
>  .../BaseCryptLibMbedTls/Rand/CryptRand.c  |  114 +
>  .../BaseCryptLibMbedTls/Rand/CryptRandTsc.c   |  114 +
>  .../BaseCryptLibMbedTls/RuntimeCryptLib.inf   |   26 +-
>  .../BaseCryptLibMbedTls/SmmCryptLib.inf   |   36 +-
>  .../BaseCryptLibMbedTls/TestBaseCryptLib.inf  |   39 +-
>  CryptoPkg/Library/MbedTlsLib/MbedTlsLib.inf   |6 +
>  .../Library/MbedTlsLib/MbedTlsLibFull.inf |6 +
>  25 files changed, 6973 insertions(+), 85 deletions(-)  create mode 100644
> CryptoPkg/Library/BaseCryptLibMbedTls/Cipher/CryptAeadAesGcm.c
>  create mode 100644 CryptoPkg/Library/BaseCryptLibMbedTls/Pem/CryptPem.c
>  create mode 100644
> CryptoPkg/Library/BaseCryptLibMbedTls/Pk/CryptAuthenticode.c
>  create mode 100644
> CryptoPkg/Libr

Re: [edk2-devel] [PATCH v4 00/14] Add SmmRelocationLib

[Yao, Jiewen]

Acked-by: Jiewen Yao 

From: Wu, Jiaxin 
Sent: Tuesday, May 7, 2024 11:39 AM
To: Ni, Ray ; devel@edk2.groups.io; Ard Biesheuvel 
; Yao, Jiewen 
Cc: Zeng, Star ; Gerd Hoffmann ; Kumar, 
Rahul R ; Dong, Guo ; Rhodes, Sean 
; Lu, James ; Guo, Gua 
; Abdul Lateef Attar ; Abner 
Chang ; Tom Lendacky 
Subject: RE: [PATCH v4 00/14] Add SmmRelocationLib

Hi Jiewen and Ard,

@Yao, Jiewen<mailto:jiewen@intel.com>, @Ard 
Biesheuvel<mailto:ardb+tianoc...@kernel.org>, do you agree we merge the change 
related to OVMF package since you are the OVMF maintainers. Please help check 
/review.

The patches have been acked/tested by the Gerd.

  [PATCH v4 08/14] OvmfPkg/SmmRelocationLib: Add library instance for OVMF
  [PATCH v4 09/14] OvmfPkg/PlatformInitLib: Create gEfiSmmSmramMemoryGuid
  [PATCH v4 10/14]  OvmfPkg: Refine SmmAccess implementation
  [PATCH v4 11/14] OvmfPkg/SmmCpuFeaturesLib: Check Smbase Relocation is done 
or not
  [PATCH v4 12/14] OvmfPkg/PlatformPei: Relocate SmBases in PEI phase

Thanks,
Jiaxin

From: Wu, Jiaxin
Sent: Tuesday, April 30, 2024 6:14 PM
To: Ni, Ray mailto:ray...@intel.com>>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Zeng, Star mailto:star.z...@intel.com>>; Gerd Hoffmann 
mailto:kra...@redhat.com>>; Kumar, Rahul R 
mailto:rahul.r.ku...@intel.com>>; Dong, Guo 
mailto:guo.d...@intel.com>>; Rhodes, Sean 
mailto:sean@starlabs.systems>>; Lu, James 
mailto:james...@intel.com>>; Guo, Gua 
mailto:gua@intel.com>>; Ard Biesheuvel 
mailto:ardb+tianoc...@kernel.org>>; Yao, Jiewen 
mailto:jiewen@intel.com>>; Abdul Lateef Attar 
mailto:abdullateef.at...@amd.com>>; Abner Chang 
mailto:abner.ch...@amd.com>>; Tom Lendacky 
mailto:thomas.lenda...@amd.com>>
Subject: RE: [PATCH v4 00/14] Add SmmRelocationLib

Thanks Ray, I missed to add some already reviewed-by tag in v4. All V4 patches 
are tested & acted by Gerd:

Tested-by: Gerd Hoffmann mailto:kra...@redhat.com>>

Acked-by: Gerd Hoffmann mailto:kra...@redhat.com>>

For each one: listed as below, *so need Ray "reviewed-by" tag on the patch: 
05/06/14, need Gerd "reviewed-by" tag on the patch:  08/09/10/11/12*

  [PATCH v4 01/14] UefiCpuPkg: Add SmmRelocationLib class
Reviewed-by: Ray Ni mailto:ray...@intel.com>>  --> no change 
compared to V3

  [PATCH v4 02/14] UefiCpuPkg/SmmRelocationLib: Add SmmRelocationLib library 
instance
Reviewed-by: Ray Ni mailto:ray...@intel.com>> --> no change 
compared to V3

  [PATCH v4 03/14] UefiCpuPkg/SmmRelocationLib: Rename global variables
Reviewed-by: Ray Ni mailto:ray...@intel.com>> --> no change 
compared to V3

 [PATCH v4 04/14]  UefiCpuPkg/SmmRelocationLib: Avoid unnecessary memory 
allocation
Reviewed-by: Ray Ni mailto:ray...@intel.com>> --> no change 
compared to V3

  [PATCH v4 05/14] UefiCpuPkg/SmmRelocationLib: Remove unnecessary global 
variable
  [PATCH v4 06/14] UefiCpuPkg/SmmRelocationLib: Remove unnecessary CpuIndex
* Change Based on Ray's comment on V3: split the removal of CpuIndex parameter 
in a new patch, so add the 06 patch in V4.*

  [PATCH v4 07/14] UefiCpuPkg/SmmRelocationLib: Add library instance for AMD
Reviewed-by: Abdul Lateef Attar 
mailto:abdullateef.at...@amd.com>> --> no change 
compared to V3

  [PATCH v4 08/14] OvmfPkg/SmmRelocationLib: Add library instance for OVMF
  [PATCH v4 09/14] OvmfPkg/PlatformInitLib: Create gEfiSmmSmramMemoryGuid
  [PATCH v4 10/14]  OvmfPkg: Refine SmmAccess implementation
  [PATCH v4 11/14] OvmfPkg/SmmCpuFeaturesLib: Check Smbase Relocation is done 
or not
  [PATCH v4 12/14] OvmfPkg/PlatformPei: Relocate SmBases in PEI phase
*Change Based on Gerd's  comment on V3: 1. Creating the 
EFI_SMM_SMRAM_MEMORY_GUID HOB should be moved to its own function.  2) refine 
the comment in SmmAccess 3) refine the commit log.*

  [PATCH v4 13/14] UefiPayloadPkg/UefiPayloadPkg.dsc: Include SmmRelocationLib
Reviewed-by: Gua Guo mailto:gua@intel.com>>
Reviewed-by: Guo Dong mailto:guo.d...@intel.com>>

  [PATCH v4 14/14] UefiCpuPkg/PiSmmCpuDxeSmm: Remove SmBases relocation logic
*Change Based on Ray's comment on V3: move the "TileSize" check just below the 
original TileSize calculation logic*

Thanks,
Jiaxin

From: Ni, Ray mailto:ray...@intel.com>>
Sent: Tuesday, April 30, 2024 2:01 PM
To: Wu, Jiaxin mailto:jiaxin...@intel.com>>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Zeng, Star mailto:star.z...@intel.com>>; Gerd Hoffmann 
mailto:kra...@redhat.com>>; Kumar, Rahul R 
mailto:rahul.r.ku...@intel.com>>; Dong, Guo 
mailto:guo.d...@intel.com>>; Rhodes, Sean 
mailto:sean@starlabs.systems>>; Lu, James 
mailto:james...@intel.com>>; Guo, Gua 
mailto:gua@intel.com>>; Ard Biesheuvel 
mailto:ardb+tianoc...@kernel.org>>; Yao, Jiewen 
mailto:jiewen@intel.com>&

Re: [edk2-devel] [PATCH v4 0/3] TCG_Sp800_155_PlatformId_Event3 support

[Yao, Jiewen]

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

> -Original Message-
> From: Dionna Glaze 
> Sent: Tuesday, May 7, 2024 2:08 AM
> To: devel@edk2.groups.io
> Cc: Dionna Glaze ; Kinney, Michael D
> ; Liming Gao ; Liu,
> Zhiguang ; Yao, Jiewen ;
> Kumar, Rahul R ; Ard Biesheuvel
> ; Gerd Hoffmann 
> Subject: [PATCH v4 0/3] TCG_Sp800_155_PlatformId_Event3 support
> 
> In December 2023, the TCG published the PC Client Platform Firmware
> Profile version 1.06 revision 52. This revision includes a new event
> type for NIST SP 800-155 recommended signed BIOS reference measurements.
> The new type allows for the event log auditor to find local or remote
> copies of the signed reference measurements.
> 
> Supporting this new event type eases the process of distributing signed
> reference measurements since the machine can now simply report where
> they can be found in a standard way.
> 
> Changes since v3:
>   - Fixed build error from 1 too many ')'s.
>   - Fixed formatting for uncrustify.
> Changes since v2:
>   - Removed errant spacing.
> Changes since v1:
>   - MdePkg defines TCG_Sp800_155_PlatformId_Event3 instead of adding a
> comment about Event3 to Event2.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Jiewen Yao 
> Cc: Rahul Kumar 
> Cc: Ard Biesheuvel 
> Cc: Gerd Hoffmann 
> Reviewed-by: Jiewen Yao 
> 
> Dionna Glaze (3):
>   MdePkg: Add TcgSp800155Event3 type info
>   SecurityPkg: Recognize sp800155Event3 event
>   OvmfPkg: Add sp800155Event3 support
> 
>  .../IndustryStandard/UefiTcgPlatform.h| 38 ++-
>  OvmfPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c | 15 +---
>  SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c | 15 +---
>  3 files changed, 57 insertions(+), 11 deletions(-)
> 
> --
> 2.45.0.rc1.225.g2a3ae87e7f-goog


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118624): https://edk2.groups.io/g/devel/message/118624
Mute This Topic: https://groups.io/mt/105945150/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 0/3] TCG_Sp800_155_PlatformId_Event3 support

[Yao, Jiewen]

Hi Dionna
I tried to create PR but I saw failure - 
https://github.com/tianocore/edk2/pull/5628

Would you please clarify if you have tested the patch in EDKII CI, before you 
submit the patch?


BTW: I have fixed a typo in the V3 patch. The "Reviewed-By" tag in 1/3 should 
be "Reviewed-by".

Thank you
Yao, Jiewen



> -Original Message-
> From: Dionna Glaze 
> Sent: Thursday, May 2, 2024 8:50 AM
> To: devel@edk2.groups.io
> Cc: Dionna Glaze ; Kinney, Michael D
> ; Liming Gao ; Liu,
> Zhiguang ; Yao, Jiewen ;
> Kumar, Rahul R ; Ard Biesheuvel
> ; Gerd Hoffmann 
> Subject: [PATCH v3 0/3] TCG_Sp800_155_PlatformId_Event3 support
> 
> In December 2023, the TCG published the PC Client Platform Firmware
> Profile version 1.06 revision 52. This revision includes a new event
> type for NIST SP 800-155 recommended signed BIOS reference measurements.
> The new type allows for the event log auditor to find local or remote
> copies of the signed reference measurements.
> 
> Supporting this new event type eases the process of distributing signed
> reference measurements since the machine can now simply report where
> they can be found in a standard way.
> 
> Changes since v2:
>   - Removed errant spacing.
> Changes since v1:
>   - MdePkg defines TCG_Sp800_155_PlatformId_Event3 instead of adding a
> comment about Event3 to Event2.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Jiewen Yao 
> Cc: Rahul Kumar 
> Cc: Ard Biesheuvel 
> Cc: Gerd Hoffmann 
> Reviewed-by: Jiewen Yao 
> 
> Dionna Glaze (3):
>   MdePkg: Add TcgSp800155Event3 type info
>   SecurityPkg: recognize sp800155Event3 event too
>   OvmfPkg: add sp800155Event3 support
> 
>  .../IndustryStandard/UefiTcgPlatform.h| 38 ++-
>  OvmfPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c |  9 -
>  SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c |  9 -
>  3 files changed, 51 insertions(+), 5 deletions(-)
> 
> --
> 2.45.0.rc0.197.gbae5840b3b-goog


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118585): https://edk2.groups.io/g/devel/message/118585
Mute This Topic: https://groups.io/mt/105854725/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/3] MdePkg: Add TcgSp800155Event3 type info

[Yao, Jiewen]

Thanks Dionna.

Almost good, except you create a typo below:
>EFI_GUIDReferenceManifestGuid;
> -  //
> +   //
>// Below structure is newly added in TCG_Sp800_155_PlatformId_Event2.

With typo fix, reviewed-by: Jiewen Yao 

Thank you
Yao, Jiewen


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Dionna Glaze
> via groups.io
> Sent: Thursday, May 2, 2024 12:10 AM
> To: devel@edk2.groups.io
> Cc: Dionna Glaze ; Kinney, Michael D
> ; Liming Gao ; Liu,
> Zhiguang 
> Subject: [edk2-devel] [PATCH v2 1/3] MdePkg: Add TcgSp800155Event3 type info
> 
> TCG PC Client Platform Firmware Profile 1.06 revision 52 of December
> 2023 added a new event signature and extended information about where a
> reference measurement document for the firmware can be found.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> 
> Signed-off-by: Dionna Glaze 
> ---
>  .../IndustryStandard/UefiTcgPlatform.h| 40 ++-
>  1 file changed, 38 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/IndustryStandard/UefiTcgPlatform.h
> b/MdePkg/Include/IndustryStandard/UefiTcgPlatform.h
> index 61bd4e4667..54bdf3a339 100644
> --- a/MdePkg/Include/IndustryStandard/UefiTcgPlatform.h
> +++ b/MdePkg/Include/IndustryStandard/UefiTcgPlatform.h
> @@ -451,6 +451,7 @@ typedef struct tdTCG_PCClientTaggedEvent {
> 
>  #define TCG_Sp800_155_PlatformId_Event_SIGNATURE   "SP800-155 Event"
>  #define TCG_Sp800_155_PlatformId_Event2_SIGNATURE  "SP800-155 Event2"
> +#define TCG_Sp800_155_PlatformId_Event3_SIGNATURE  "SP800-155 Event3"
> 
>  typedef struct tdTCG_Sp800_155_PlatformId_Event2 {
>UINT8   Signature[16];
> @@ -463,7 +464,7 @@ typedef struct tdTCG_Sp800_155_PlatformId_Event2 {
>// 16-byte identifier of a given platform's static configuration of code
>//
>EFI_GUIDReferenceManifestGuid;
> -  //
> +   //
>// Below structure is newly added in TCG_Sp800_155_PlatformId_Event2.
>//
>// UINT8   PlatformManufacturerStrSize;
> @@ -478,9 +479,44 @@ typedef struct tdTCG_Sp800_155_PlatformId_Event2 {
>// UINT8   
> FirmwareManufacturerStr[FirmwareManufacturerStrSize];
>// UINT32  FirmwareManufacturerId;
>// UINT8   FirmwareVersion;
> -  // UINT8   FirmwareVersion[FirmwareVersionSize]];
> +  // UINT8   FirmwareVersion[FirmwareVersionSize];
>  } TCG_Sp800_155_PlatformId_Event2;
> 
> +typedef struct tdTCG_Sp800_155_PlatformId_Event3 {
> +  UINT8   Signature[16];
> +  //
> +  // Where Vendor ID is an integer defined
> +  // at http://www.iana.org/assignments/enterprisenumbers
> +  //
> +  UINT32  VendorId;
> +  //
> +  // 16-byte identifier of a given platform's static configuration of code
> +  //
> +  EFI_GUIDReferenceManifestGuid;
> +  // UINT8   PlatformManufacturerStrSize;
> +  // UINT8   
> PlatformManufacturerStr[PlatformManufacturerStrSize];
> +  // UINT8   PlatformModelSize;
> +  // UINT8   PlatformModel[PlatformModelSize];
> +  // UINT8   PlatformVersionSize;
> +  // UINT8   PlatformVersion[PlatformVersionSize];
> +  // UINT8   PlatformModelSize;
> +  // UINT8   PlatformModel[PlatformModelSize];
> +  // UINT8   FirmwareManufacturerStrSize;
> +  // UINT8   
> FirmwareManufacturerStr[FirmwareManufacturerStrSize];
> +  // UINT32  FirmwareManufacturerId;
> +  // UINT8   FirmwareVersion;
> +  // UINT8   FirmwareVersion[FirmwareVersionSize];
> +  //
> +  // Below structure is newly added in TCG_Sp800_155_PlatformId_Event3
> +  //
> +  // UINT32  RimLocatorType;
> +  // UINT32  RimLocatorLength;
> +  // UINT8   RimLocator[RimLocatorLength];
> +  // UINT32  PlatformCertLocatorType;
> +  // UINT32  PlatformCertLocatorLength;
> +  // UINT8   PlatformCertLocator[PlatformCertLocatorLength];
> +} TCG_Sp800_155_PlatformId_Event3;
> +
>  #define TCG_EfiStartupLocalityEvent_SIGNATURE  "StartupLocality"
> 
>  //
> --
> 2.45.0.rc0.197.gbae5840b3b-goog
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118484): https://edk2.groups.io/g/devel/message/118484
Mute This Topic: https://groups.io/mt/105845524/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/3] MdePkg: Add TcgSp800155Event3 type info

[Yao, Jiewen]

I think it is confusing to add "TCG_Sp800_155_PlatformId_Event3" field for 
"TCG_Sp800_155_PlatformId_Event2" structure.

Maybe just create a new "TCG_Sp800_155_PlatformId_Event3" structure?



> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Dionna Glaze
> via groups.io
> Sent: Wednesday, May 1, 2024 8:53 AM
> To: devel@edk2.groups.io
> Cc: Dionna Glaze ; Kinney, Michael D
> ; Liming Gao ; Liu,
> Zhiguang 
> Subject: [edk2-devel] [PATCH 1/3] MdePkg: Add TcgSp800155Event3 type info
> 
> TCG PC Client Platform Firmware Profile 1.06 revision 52 of December
> 2023 added a new event signature and extended information about where a
> reference measurement document for the firmware can be found.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> 
> Signed-off-by: Dionna Glaze 
> ---
>  MdePkg/Include/IndustryStandard/UefiTcgPlatform.h | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Include/IndustryStandard/UefiTcgPlatform.h
> b/MdePkg/Include/IndustryStandard/UefiTcgPlatform.h
> index 61bd4e4667..30df8302b1 100644
> --- a/MdePkg/Include/IndustryStandard/UefiTcgPlatform.h
> +++ b/MdePkg/Include/IndustryStandard/UefiTcgPlatform.h
> @@ -451,6 +451,7 @@ typedef struct tdTCG_PCClientTaggedEvent {
> 
>  #define TCG_Sp800_155_PlatformId_Event_SIGNATURE   "SP800-155 Event"
>  #define TCG_Sp800_155_PlatformId_Event2_SIGNATURE  "SP800-155 Event2"
> +#define TCG_Sp800_155_PlatformId_Event3_SIGNATURE  "SP800-155 Event3"
> 
>  typedef struct tdTCG_Sp800_155_PlatformId_Event2 {
>UINT8   Signature[16];
> @@ -478,7 +479,16 @@ typedef struct tdTCG_Sp800_155_PlatformId_Event2 {
>// UINT8   
> FirmwareManufacturerStr[FirmwareManufacturerStrSize];
>// UINT32  FirmwareManufacturerId;
>// UINT8   FirmwareVersion;
> -  // UINT8   FirmwareVersion[FirmwareVersionSize]];
> +  // UINT8   FirmwareVersion[FirmwareVersionSize];
> +  //
> +  // Below structure is newly added in TCG_Sp800_155_PlatformId_Event3
> +  //
> +  // UINT32  RimLocatorType;
> +  // UINT32  RimLocatorLength;
> +  // UINT8   RimLocator[RimLocatorLength];
> +  // UINT32  PlatformCertLocatorType;
> +  // UINT32  PlatformCertLocatorLength;
> +  // UINT8   PlatformCertLocator[PlatformCertLocatorLength];
>  } TCG_Sp800_155_PlatformId_Event2;
> 
>  #define TCG_EfiStartupLocalityEvent_SIGNATURE  "StartupLocality"
> --
> 2.45.0.rc0.197.gbae5840b3b-goog
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118453): https://edk2.groups.io/g/devel/message/118453
Mute This Topic: https://groups.io/mt/105833238/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] TCG_Sp800_155_PlatformId_Event3 support

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Dionna Glaze 
> Sent: Wednesday, May 1, 2024 8:53 AM
> To: devel@edk2.groups.io
> Cc: Dionna Glaze ; Kinney, Michael D
> ; Liming Gao ; Liu,
> Zhiguang ; Yao, Jiewen ;
> Kumar, Rahul R ; Ard Biesheuvel
> ; Gerd Hoffmann 
> Subject: [PATCH 0/3] TCG_Sp800_155_PlatformId_Event3 support
> 
> In December 2023, the TCG published the PC Client Platform Firmware
> Profile version 1.06 revision 52. This revision includes a new event
> type for NIST SP 800-155 recommended signed BIOS reference measurements.
> The new type allows for the event log auditor to find local or remote
> copies of the signed reference measurements.
> 
> Supporting this new event type eases the process of distributing signed
> reference measurements since the machine can now simply report where
> they can be found in a standard way.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Jiewen Yao 
> Cc: Rahul Kumar 
> Cc: Ard Biesheuvel 
> Cc: Gerd Hoffmann 
> 
> 
> Dionna Glaze (3):
>   MdePkg: Add TcgSp800155Event3 type info
>   SecurityPkg: recognize sp800155Event3 event too
>   OvmfPkg: add sp800155Event3 support
> 
>  MdePkg/Include/IndustryStandard/UefiTcgPlatform.h | 12 +++-
>  OvmfPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c |  9 +++--
>  SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c |  9 +++--
>  3 files changed, 25 insertions(+), 5 deletions(-)
> 
> --
> 2.45.0.rc0.197.gbae5840b3b-goog


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118452): https://edk2.groups.io/g/devel/message/118452
Mute This Topic: https://groups.io/mt/105833236/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]

Hi All
It has been 4 work weeks and this V4 patch resolved previous comments and 
feedbacks.

If there is no further objection, I plan to merge it tomorrow.

Thank you
Yao, Jiewen


> -Original Message-
> From: Hou, Wenxing 
> Sent: Friday, April 26, 2024 9:52 AM
> To: Yao, Jiewen ; devel@edk2.groups.io; Andrew Fish
> ; Leif Lindholm ; Kinney, Michael
> D ; Liming Gao ;
> Sean Brogan ; Joey Vagedes
> ; Liu, Zhiguang ; Kumar,
> Rahul R 
> Subject: RE: [edk2-devel] [PATCH v4 00/10] Add DeviceSecurity feature based on
> PFP 1.06 spec
> 
> Hi EDKII stewards,
> 
> Could you please review the libspdm license?
> 
> The libspdm(https://github.com/DMTF/libspdm) is a implementation that follows
> the DMTF SPDM(https://www.dmtf.org/standards/spdm) spec.
> 
> And the libspdm library is under DMTF repo.
> The license is: https://github.com/DMTF/libspdm/blob/main/LICENSE.md
> 
> 
> 
> Thanks,
> Wenxing
> 
> 
> -Original Message-
> From: Yao, Jiewen 
> Sent: Sunday, April 21, 2024 10:31 AM
> To: Hou, Wenxing ; devel@edk2.groups.io; Andrew Fish
> ; Leif Lindholm ; Kinney, Michael
> D ; Liming Gao ;
> Sean Brogan ; Joey Vagedes
> ; Liu, Zhiguang ; Kumar,
> Rahul R 
> Subject: RE: [edk2-devel] [PATCH v4 00/10] Add DeviceSecurity feature based on
> PFP 1.06 spec
> 
> 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:

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: W

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 = &AllDescMap[Index];
> >
> > -if (Desc->GcdMemoryType != EFI_GCD_MEMORY_TYPE_UNACCEPTED) {
> >
> > +if (Desc->GcdMemoryType != EfiGcdMem

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   = &InstructionData->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   = &InstructionData->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, ou

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 = &AllDescMap[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_

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-

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 +
> >  .pytoo

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 = &PrivateData->ConfigAccess;
> @@ -879,6 +897,8 @@ InstallTcg2ConfigForm (
>break;
>}
> 
> +  Tcg2HashAlgorithmBitmap = PcdGet32 (PcdTcg2HashAlgorithmBitmap);
> +
&g

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/OpalPasswor

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 (&gSecureBootConfigFormSetGuid,
> 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
> (&gSecureBootConfigFormSetGuid, 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, I

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.
> 

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

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, &mHstiBase, 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
> 
>

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)&Timeout,
> +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

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

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
> (&gSecureBootConfigFormSetGuid, 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
> (&gSecureBootConfigFormSetGuid, mSecureBootStorageName, BufferSize,
> (UINT8 *)IfrNvDa

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 a

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 

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.gro

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/ArmSoftF

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
>&gEfiPeiReadOnlyVariable2PpiGuid, // Guid
>OnReadO

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 chan

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,
> &MapGpaRetryAddr);
> +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,
> &MapGpaRetryAddr);
> +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
>  crea

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: y

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]
-=-=-=-=-=-=-=-=-=-=-=-