Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support
Date:   Thu, 26 Mar 2020 14:07:10 -0700
Message-Id: <BB670F86-9362-4A8C-8BE6-64A5AF9537A7@amacapital.net>
References: <CACdnJusd7m-c0zLmAjSq9Sb9HxyCkhyyp5W=4FMdysgu7_g=Sw@mail.gmail.com>
Cc:     Daniel Kiper <daniel.kiper@oracle.com>,
        Ross Philipson <ross.philipson@oracle.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        the arch/x86 maintainers <x86@kernel.org>,
        linux-doc@vger.kernel.org, dpsmith@apertussolutions.com,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "H. Peter Anvin" <hpa@zytor.com>,
        trenchboot-devel@googlegroups.com,
        Ard Biesheuvel <ardb@kernel.org>, leif@nuviainc.com,
        eric.snowberg@oracle.com, piotr.krol@3mdeb.com,
        krystian.hebel@3mdeb.com, michal.zygowski@3mdeb.com,
        James Bottomley <James.Bottomley@hansenpartnership.com>,
        andrew.cooper3@citrix.com
In-Reply-To: <CACdnJusd7m-c0zLmAjSq9Sb9HxyCkhyyp5W=4FMdysgu7_g=Sw@mail.gmail.com>
To:     Matthew Garrett <mjg59@google.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Mar 26, 2020, at 1:40 PM, Matthew Garrett <mjg59@google.com> wrote:
>=20
> =EF=BB=BFOn Thu, Mar 26, 2020 at 1:33 PM Andy Lutomirski <luto@amacapital.=
net> wrote:
>> As a straw-man approach: make the rule that we never call EFI after secur=
e 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 t=
he image against PCRs, blow away PCRs, call EFI, relaunch, unseal the PCRs, a=
nd continue on our merry way.
>=20
> That breaks the memory overwrite protection code, where a variable is
> set at boot and cleared on a controlled reboot.

Can you elaborate?  I=E2=80=99m 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=E2=80=99t 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=E2=80=99re misunderstanding my suggestion.  I=E2=80=99m suggesting=
 that we hibernate the whole running system to memory (more like kexec jump t=
han hibernate) and authenticated-encrypt the whole thing (including user mem=
ory) 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 t=
his.

>=20
>> I=E2=80=99m not sure how SMM fits in to this whole mess.
>=20
> 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.
>=20
>> If we insist on allowing EFI calls and SMM, then we may be able to *measu=
re* our exposure to potentially malicious firmware, but we can=E2=80=99t eli=
minate it. I personally trust OEM firmware about as far as I can throw it.