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
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
> 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 P
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
> 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 - Introdu
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
>
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 cod
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
Tom Lendacky
> Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to
> support Tdx
>
> OK. Got it.
> Let me explain it in more detail.
>
> Let's assume PEI phase include 3 major classes {PEI Core, PEI Arch PEM*,
> Feature X*}. * means 0~multi
ay, 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
> su
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 is co
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
o, 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 Lendacky
>
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
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
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.
> 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
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
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
> -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]
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:
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
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
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
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
In TDX BSP and APs goes to the same entry point in SecEntry.nasm.
BSP initialize the temporary stack and then jumps to SecMain, just as
legacy Ovmf does.
APs spin in a modified mailbox loop using initial mailbox structure.
Its structure
30 matches
Mail list logo
