On December 7, 2021 4:05 PM, Gerd Hoffmann wrote:
> > [Jiewen] OK, I talked with Min again. 12ms is not right data today.
> > We have bigger number, but I cannot share the data according to legal
> reason.
> >
> > But I agree with your statement that, if the data is small enough, then we
> don't ne
Hi,
> [Jiewen] OK, I talked with Min again. 12ms is not right data today.
> We have bigger number, but I cannot share the data according to legal reason.
>
> But I agree with your statement that, if the data is small enough, then we
> don't need MP in sec.
>
> I propose this way:
> 1) In firs
> Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to
> support Tdx
>
> Hi,
>
> > [Jiewen] Again, I feel lost.
> >
> > Would you please clarify what is your purpose for this discussion?
> >
> > Yes, Security related stuff in PEI,
Hi,
> [Jiewen] Again, I feel lost.
>
> Would you please clarify what is your purpose for this discussion?
>
> Yes, Security related stuff in PEI, that is not a problem. For
> example, we moved flash lock from DXE to PEI. (I already describe that
> in my previous email.)
Well, you tried to mak
> Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to
> support Tdx
>
> Hi,
>
> > Please refer to PI specification 1.7A
> (https://uefi.org/sites/default/files/resources/PI_Spec_1_7_A_final_May1.pdf)
> > Section 2.1 - Introduction.
>
Hi,
> Please refer to PI specification 1.7A
> (https://uefi.org/sites/default/files/resources/PI_Spec_1_7_A_final_May1.pdf)
> Section 2.1 - Introduction.
> "Philosophically, the PEI phase is intended to be the thinnest amount
> of code to achieve the ends listed above. As such, any more
> soph
Erdem Aktas ; Tom Lendacky
>
> Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to
> support Tdx
>
> Hi,
>
> > So, my judgement is by removing PEI, we can reduce the risk introduce
> > by PEI Core + PEI Arch PEIM*. Reducing code == Redu
Hi,
> So, my judgement is by removing PEI, we can reduce the risk introduce
> by PEI Core + PEI Arch PEIM*. Reducing code == Reducing Security Risk.
Yes, PEI Core goes away.
No, PEI Arch PEIM (aka OvmfPkg/PlatformPei) wouldn't go away, you would
only move the code to SEC or DXE phase, the plat
>
> > -Original Message-
> > From: devel@edk2.groups.io On Behalf Of James
> > Bottomley
> > Sent: Wednesday, November 24, 2021 10:07 PM
> > To: Yao, Jiewen ; devel@edk2.groups.io; Gerd
> > Hoffmann
> > Cc: Xu, Min M ; Ard Biesheuvel
> > ;
dnesday, November 24, 2021 10:07 PM
> To: Yao, Jiewen ; devel@edk2.groups.io; Gerd
> Hoffmann
> Cc: Xu, Min M ; Ard Biesheuvel
> ; Justen, Jordan L ;
> Brijesh Singh ; Erdem Aktas
> ; Tom Lendacky
> Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to
&g
On Wed, 2021-11-24 at 14:03 +, Yao, Jiewen wrote:
> James
> I am sorry that it is hard for me to understand your point.
>
> To be honest, I am not sure what is objective on the discussion.
> Are you question the general threat model analysis on UEFI PI
> architecture?
The object is for me to
On Wed, 2021-11-24 at 11:08 +, Yao, Jiewen wrote:
> > -Original Message-
> > From: Gerd Hoffmann
[...]
> > There isn't much external input to process in PEI phase. Virtual
> > machines are a bit different than physical machines. They need to
> > process some input from the host here
> Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to
> support Tdx
>
> Hi,
>
> > 1. " the PEI domain has very limited exposure, it's the DXE domain that has
> > full
> exposure "
> > [Jiewen] I don’t understand how that
Hi,
> 1. " the PEI domain has very limited exposure, it's the DXE domain that has
> full exposure "
> [Jiewen] I don’t understand how that is concluded, on " limited exposure ", "
> full exposure ".
exposure == "the need to process external input, which an attacker might
use to exploit bugs
ffmann ; Xu, Min M ;
> Ard Biesheuvel ; Justen, Jordan L
> ; Brijesh Singh ; Erdem
> Aktas ; Tom Lendacky
> Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to
> support Tdx
>
> I think we are discussing under different context.
>
> First, the term &q
Thank you
Yao, Jiewen
> -Original Message-
> From: James Bottomley
> Sent: Tuesday, November 23, 2021 11:38 PM
> To: devel@edk2.groups.io; Yao, Jiewen
> Cc: Gerd Hoffmann ; Xu, Min M ;
> Ard Biesheuvel ; Justen, Jordan L
> ; Brijesh Singh ; Erdem
> Aktas ; Tom
On Tue, 2021-11-23 at 15:10 +, Yao, Jiewen wrote:
> I would say the PEI owns the system and all memory (including the
> DXE).
>
> A bug in PEI may override the loaded DXE memory or the whole system.
That's not the correct way to analyse the security properties. From
the security point of vi
I would say the PEI owns the system and all memory (including the DXE).
A bug in PEI may override the loaded DXE memory or the whole system.
In history I did see PEI security issues.
Some security issue in PEI caused system compromised completely. You even have
no chance to run DXE.
thank yo
On Tue, 2021-11-23 at 14:36 +, Yao, Jiewen wrote:
> > This strict isolation between DXE and PEI means that once we're in
> > DXE, any bugs in PEI can't be exploited to attack the DXE
> > environment.
>
> [jiewen] I would disagree the statement above.
> There is not strict isolation. Actuall
> This strict isolation between DXE and PEI means that once we're in DXE,
> any bugs in PEI can't be exploited to attack the DXE environment.
[jiewen] I would disagree the statement above.
There is not strict isolation. Actually no isolation at all.
The DXE is loaded by PEI.
A bug in PEI has g
On Tue, 2021-11-23 at 13:07 +, Yao, Jiewen wrote:
> Comment below only:
>
> > I am persuaded to let config-a adopt the OVMF way, because the
> > threat model of config-A is same as the normal OVMF.
> > But config-B is NOT.
> > Different threat model drives different solution.
> > I completely
Comment below only:
> I am persuaded to let config-a adopt the OVMF way, because the threat model
> of config-A is same as the normal OVMF.
> But config-B is NOT.
> Different threat model drives different solution.
> I completely don't understand why they must be same.
I don't understand why you
Hi,
> > That totally makes sense. I expect TDVF Config-B will look alot like
> > the existing AmdSev configuration variant which is stripped down too.
>
> [Jiewen] I don't think TDVF config-B will be like the AMD SEV is right
> statement.
> TDVF and SEV are two different platforms.
Yes, of c
> -Original Message-
> From: Gerd Hoffmann
> Sent: Friday, November 19, 2021 11:12 PM
> To: Yao, Jiewen
> Cc: Xu, Min M ; devel@edk2.groups.io; Ard Biesheuvel
> ; Justen, Jordan L ;
> Brijesh Singh ; Erdem Aktas
> ; James Bottomley ; Tom
> Lendacky
> Subject: Re: [PATCH V3 15/29] Ovmf
Hi,
> Comment on config-B.
> > I'm sure I've asked this before: Why skip the PEI phase? So far
> > I have not seen any convincing argument for it.
>
> Skipping PEI phase is valid architecture design.
Sure.
> Second, the confidential computing changes the threat model
> completely. One of
Comment on config-B.
> -Original Message-
> From: Gerd Hoffmann
> Sent: Wednesday, November 17, 2021 11:20 PM
> To: Xu, Min M
> Cc: devel@edk2.groups.io; Ard Biesheuvel ; Justen,
> Jordan L ; Brijesh Singh ;
> Erdem Aktas ; James Bottomley
> ; Yao, Jiewen ; Tom Lendacky
>
> Subject: Re:
On Tue, Nov 16, 2021 at 12:11:33PM +, Xu, Min M wrote:
> On November 3, 2021 2:31 PM, Gerd Hoffmann wrote:
> > Hi,
> >
> > > - AcceptPages:
> > >To mitigate the performance impact of accepting pages in SEC phase on
> > >BSP, BSP will parse memory resources and assign each AP the ta
On November 3, 2021 2:31 PM, Gerd Hoffmann wrote:
> Hi,
>
> > - AcceptPages:
> >To mitigate the performance impact of accepting pages in SEC phase on
> >BSP, BSP will parse memory resources and assign each AP the task of
> >accepting a subset of pages. This command may be called se
Hi,
> - AcceptPages:
>To mitigate the performance impact of accepting pages in SEC phase on
>BSP, BSP will parse memory resources and assign each AP the task of
>accepting a subset of pages. This command may be called several times
>until all memory resources are processed. In a
29 matches
Mail list logo
