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;
MIME-Version: 1.0
References: <CACdnJutT1F7YJ5KFkyuaZv=nj8GqC+mrnoAsHZfMP1ZRNUQg3Q@mail.gmail.com>
 <FE871C2B-15BB-4089-A912-40F2E9FE680B@amacapital.net>
In-Reply-To: <FE871C2B-15BB-4089-A912-40F2E9FE680B@amacapital.net>
From:   Matthew Garrett <mjg59@google.com>
Date:   Thu, 26 Mar 2020 13:40:42 -0700
Message-ID: <CACdnJusd7m-c0zLmAjSq9Sb9HxyCkhyyp5W=4FMdysgu7_g=Sw@mail.gmail.com>
Subject: Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support
To:     Andy Lutomirski <luto@amacapital.net>
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 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 chang=
e on disk somewhere.  When we want to commit those changes, we reboot, comm=
it the changes, and re-launch. Or we deactivate the kernel kexec-style, sea=
l the image against PCRs, blow away PCRs, call EFI, relaunch, unseal the PC=
Rs, 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=E2=80=99m 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 *measu=
re* our exposure to potentially malicious firmware, but we can=E2=80=99t el=
iminate it. I personally trust OEM firmware about as far as I can throw it.