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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACdnJus6H3LQww8hkTMpPKN7u_sb1PXmgPwQOCSVZR_fi7GMrA@mail.gmail.com>
Date:   Thu, 26 Mar 2020 14:28:25 -0700
From:   Matthew Garrett <mjg59@...gle.com>
To:     Andy Lutomirski <luto@...capital.net>
Cc:     Daniel Kiper <daniel.kiper@...cle.com>,
        Ross Philipson <ross.philipson@...cle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        linux-doc@...r.kernel.org,
        "Daniel P. Smith" <dpsmith@...rtussolutions.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        trenchboot-devel@...glegroups.com,
        Ard Biesheuvel <ardb@...nel.org>, leif@...iainc.com,
        eric.snowberg@...cle.com, piotr.krol@...eb.com,
        krystian.hebel@...eb.com, michal.zygowski@...eb.com,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        andrew.cooper3@...rix.com
Subject: Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support

On Thu, Mar 26, 2020 at 2:07 PM Andy Lutomirski <luto@...capital.net> wrote:
> > On Mar 26, 2020, at 1:40 PM, Matthew Garrett <mjg59@...gle.com> wrote:
> >
> > On Thu, Mar 26, 2020 at 1:33 PM Andy Lutomirski <luto@...capital.net> 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.

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.

> > 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.

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.