Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support

[Andy Lutomirski]

> On Mar 26, 2020, at 1:40 PM, Matthew Garrett <mjg59@xxxxxxxxxx> wrote:
> 
> ïOn Thu, Mar 26, 2020 at 1:33 PM Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>> As a straw-man approach: make the rule that we never call EFI after secure launch. Instead we write out any firmware variables that we want to change on disk somewhere.  When we want to commit those changes, we reboot, commit the changes, and re-launch. Or we deactivate the kernel kexec-style, seal the image against PCRs, blow away PCRs, call EFI, relaunch, unseal the PCRs, and continue on our merry way.
> 
> That breaks the memory overwrite protection code, where a variable is
> set at boot and cleared on a controlled reboot.

Can you elaborate?  Iâm not familiar with this.

> We'd also need to read
> every variable and pass those values to the kernel in some way so the
> read interfaces still work.

Indeed.

> Some platforms may also expect to be able
> to use the EFI reboot call.

Reboot is easy-ish: idle all APs, zero all but one page of text and the page tables, and call reboot. There arenât any secrets that need to stay in memory when rebooting.


> As for the second approach - how would we
> verify that the EFI code hadn't modified any user pages? Those
> wouldn't be measured during the second secure launch. If we're calling
> the code at runtime then I think we need to assert that it's trusted.

Maybe youâre misunderstanding my suggestion.  Iâm suggesting that we hibernate the whole running system to memory (more like kexec jump than hibernate) and authenticated-encrypt the whole thing (including user memory) with a PCR-sealed key. We jump to a stub that zaps PCRs does EFI calls. Then we re-launch and decrypt memory.

Kind of like S3 implementation wise too except with an encryption step.  And if we support secure launch and S3 together we probably have to implement this.

> 
>> Iâm not sure how SMM fits in to this whole mess.
> 
> SMM's basically an unsolved problem, which makes the whole DRTM
> approach somewhat questionable unless you include the whole firmware
> in the TCB, which is kind of what we're trying to get away from.
> 
>> If we insist on allowing EFI calls and SMM, then we may be able to *measure* our exposure to potentially malicious firmware, but we canât eliminate it. I personally trust OEM firmware about as far as I can throw it.