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 (#83947): https://edk2.groups.io/g/devel/message/83947 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] -=-=-=-=-=-=-=-=-=-=-=-
