On Thu, Mar 26, 2020 at 3:52 PM Andy Lutomirski <luto@xxxxxxxxxx> wrote: > > On Thu, Mar 26, 2020 at 2:28 PM Matthew Garrett <mjg59@xxxxxxxxxx> wrote: > > https://trustedcomputinggroup.org/wp-content/uploads/TCG_PlatformResetAttackMitigationSpecification_1.10_published.pdf > > - you want to protect in-memory secrets from a physically present > > attacker hitting the reset button, booting something else and just > > dumping RAM. This is avoided by setting a variable at boot time (in > > the boot stub), and then clearing it on reboot once the secrets have > > been cleared from RAM. If the variable isn't cleared, the firmware > > overwrites all RAM contents before booting anything else. > > I admit my information is rather dated, but I'm pretty sure that at > least some and possibly all TXT implementations solve this more > directly. In particular, as I understand it, when you TXT-launch > anything, a nonvolatile flag in the chipset is set. On reboot, the > chipset will not allow access to memory *at all* until an > authenticated code module wipes memory and clears that flag. Mm, yes, this one might be something we can just ignore in the TXT case. > > When you say "re-launch", you mean perform a second secure launch? I > > think that would work, as long as we could reconstruct an identical > > state to ensure that the PCR17 values matched - and that seems like a > > hard problem. > > Exactly. I would hope that performing a second secure launch would > reproduce the same post-launch PCRs as the first launch. If the > kernel were wise enough to record all PCR extensions, it could replay > them. That presumably depends on how much state is in the measured region - we can't just measure the code in order to assert that we're secure. > In any case, I'm kind of with Daniel here. We survived for quite a > long time without EFI variables at all. The ability to write them is > nice, and we certainly need some way, however awkward, to write them > on rare occasions, but I don't think we really need painless runtime > writes to EFI variables. I'm fine with a solution that involves jumping through some hoops, but it feels like simply supporting measuring and passing through the runtime services would be fine - if you want to keep them outside the TCB, build a kernel that doesn't have EFI runtime service support and skip that measurement?
