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 for Android: free password hash cracker in your pocket

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

Message-ID: <7e5fdc3a-c32c-5a1e-60c0-7e0c6e319a6d@apertussolutions.com>
Date:   Thu, 26 Mar 2020 16:59:17 -0400
From:   "Daniel P. Smith" <dpsmith@...rtussolutions.com>
To:     Matthew Garrett <mjg59@...gle.com>,
        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, 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 3/26/20 4:40 PM, Matthew Garrett 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. We'd also need to read
> every variable and pass those values to the kernel in some way so the
> read interfaces still work. Some platforms may also expect to be able
> to use the EFI reboot call. 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.
> 
>> 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.

Yes and no. First, if you have a TXT-aware STM, then its solved (as
solved as it can be). But if you are not that luck(?) it is still not
possible for SMM to disrupt the initial measurements and thus the load
time integrity but it can tamper with the runtime integrity of the
kernel. But again everyone has acknowledge that if SMM is owned its game
over regardless. If EFI is corrupted then launching with Dynamic Launch
and not using Runtime Services, you will not be exposed, i.e. we have
contained the corruption.

An open question I have is whether it might be possible to re-establish
the integrity of runtime services by using a dynamically launched kernel.


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