> 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 global impact and it can definitely be used to attack the DXE. thank you! Yao, Jiewen > 在 2021年11月23日，下午10:27，James Bottomley <j...@linux.ibm.com> 写道： > > On Tue, 2021-11-23 at 13:07 +0000, 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 don't understand why they must be same. >> >> I don't understand why you want separate them. Improving OvmfPkg >> security is good for both OVMF and TDVF. For TDVF it is clearly much >> more important due to the different threat model, but it is good for >> OVMF too. Likewise edk2 in general. >> >> [Jiewen] My answer is very clear as I mentioned multiple times. >> The threat model is different. >> IMHO, talking about "Improving OvmfPkg security" without a clear >> threat model is *meaningless*. >> All mitigation must be based upon threat mode and security objective. >> Otherwise, what you are doing might be either unnecessary or >> insufficient. > > Can we take a step back and look at the bigger picture. The way EFI is > supposed to operate, according to the architecture model: > > https://uefi.org/sites/default/files/resources/PI_Spec_1_7_final_Jan_2019.pdf > (Figure 1 and Table 4) > > is that SEC is supposed to be as small and compact as possible, so it > could be ROM installed without worrying about upgrade issues. It's job > is only to get the CPU initialized to the point it can run PEI, measure > PEI and transfer control. Security depends on the smallness of SEC > because if it's rom installed (as a root of trust ought to be) it can't > be upgraded to fix a bug. > > PEI is supposed to initialize the hardware: set up the CPU, memory > Application Processors and board configuration so we're in a known > state with described features for DXE. It then measures DXE (only if > SEC didn't measure it) and hands off to DXE. PEI code is designed not > to interact with anything except setup to minimize external > exploitation of internal bugs. > > DXE is supposed to contain only runtime code, including device drivers. > > The security point here is that the job of PEI is over as soon as it > hands off to DXE, so at that point all the PEI code could be discarded > (it usually isn't, but it could be). > > 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. This > allows us to minimize DXE which is where most of the main risk of > configuration based exploitation is. > > In this security model, you increase security by moving as much code as > you can from DXE to PEI because the true attack surface is DXE. > > To a lot of us, cutting out PEI, which requires redistributing code > into DXE sounds like an increase not a reduction in the attack surface > of the code. You can argue that OVMF doesn't obey the model above and > has a lot of initialization code in DXE anyway, but then the correct > route would be to fix our PEI/DXE separation to recover the security > properties. > >>> If you force me to add PEI to config-B. Finally, that causes TDVF >>> config-B is compromised due to an issue in PEI. >>> Who will take the responsibility? Will you or RedHat take that? >> >> Bugs happen. There could also be bugs in the additional SEC code you >> need for platform setup in a non-PEI configuration ... >> >> [Jiewen] I agree. That is why we need smaller code. >> We can just focus on review that small portion of code what we have >> written for TDVF, instead of the whole PEI. >> We have process to review and maintain the extra TDVF code. > > This depends ... if you agree with the security model outlined above, > bugs in PEI are less of a problem because they can't be exploited. Or > do you not agree with this security model? > > Security isn't about total bug elimination, it's about exploit > elimination. You fix a security vulnerability either by fixing the bug > that can be exploited or removing the ability to exploit it. This is > the reason for technologies like NX ... they don't stop people > exploiting bugs to write code to the stack, but they do mean that once > you have the code on the stack you can no-longer execute it and the > attackers have to move on to other means of gaining control. > > The great thing about exploit elimination vs bug elimination is the > former can usually be done on a whole class of bugs and the latter > requires a whack-a-mole per bug type approach. > > James > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#83948): https://edk2.groups.io/g/devel/message/83948 Mute This Topic: https://groups.io/mt/86739864/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
