Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 12 Aug 2022 06:54:37 +0100
From:   Matthew Garrett <mjg59@srcf.ucam.org>
To:     Brendan Trotter <btrotter@gmail.com>
Cc:     The development of GNU GRUB <grub-devel@gnu.org>,
        Ard Biesheuvel <ardb@kernel.org>,
        Daniel Kiper <daniel.kiper@oracle.com>,
        Alec Brown <alec.r.brown@oracle.com>,
        Kanth Ghatraju <kanth.ghatraju@oracle.com>,
        Ross Philipson <ross.philipson@oracle.com>,
        "piotr.krol@3mdeb.com" <piotr.krol@3mdeb.com>,
        "krystian.hebel@3mdeb.com" <krystian.hebel@3mdeb.com>,
        "persaur@gmail.com" <persaur@gmail.com>,
        "Yoder, Stuart" <stuart.yoder@arm.com>,
        Andrew Cooper <andrew.cooper3@citrix.com>,
        "michal.zygowski@3mdeb.com" <michal.zygowski@3mdeb.com>,
        James Bottomley <James.Bottomley@hansenpartnership.com>,
        "lukasz@hawrylko.pl" <lukasz@hawrylko.pl>,
        linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
        James Morris <jmorris@namei.org>
Subject: Re: Linux DRTM on UEFI platforms
Message-ID: <20220812055437.GA10952@srcf.ucam.org>
References: <b1e7b545-8e66-5dc0-ff5a-9f69d1751a5f@apertussolutions.com>
 <CAELHeEcEN=4YrPJROvzHoOiqqe5Bk0f8pDCZDnQ6aS=2LdwNow@mail.gmail.com>
 <f09fe749-e139-db6a-b2ad-45db76da04ae@apertussolutions.com>
 <CAELHeEe5H8BNf8K22XRm3hXf=_imHBnf-MHcFYvPCXX7GYkt4w@mail.gmail.com>
 <203110bb-b70b-b4f1-9453-46136659f84c@apertussolutions.com>
 <CAELHeEe2CiTXfMf3OYu3bzc_kH=rs4qzC-4XQL12AM=Nq8Csjw@mail.gmail.com>
 <20220810174638.GA7906@srcf.ucam.org>
 <CAELHeEdNgYCh_kQwWpEc4aXw-YL-KGrAeDCL-VaG3ChFs6LNVw@mail.gmail.com>
 <20220811182502.GA32433@srcf.ucam.org>
 <CAELHeEcfHSXewFCywsYeN_g8Q_BNG+4tP-QENO5QBw8Dj91yMA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAELHeEcfHSXewFCywsYeN_g8Q_BNG+4tP-QENO5QBw8Dj91yMA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Fri, Aug 12, 2022 at 12:52:58PM +0930, Brendan Trotter wrote:
> Hi,
> 
> On Fri, Aug 12, 2022 at 3:55 AM Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > On Thu, Aug 11, 2022 at 07:25:58PM +0930, Brendan Trotter wrote:
> > > On Thu, Aug 11, 2022 at 3:16 AM Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > > > The kernel has no way to know this - *any* code you've run before
> > > > performing a measurement could tamper with the kernel such that it
> > > > believes it's fine. This is just as true in DRTM as it is in SRTM. But
> > > > you know what the expected measurements should be, so you're able to
> > > > either seal secrets to those PCR values or rely on remote attestation.
> > >
> > > In this scenario the kernel has no idea what the measurement should
> > > be, it only knows the measurement that a potentially malicious boot
> > > loader felt like giving the kernel previously (e.g. when the kernel
> > > was installed).
> >
> > Even if the kernel has an idea of what the measurement should be, it has
> > no way to verify that what it believes to be true is true - any
> > malicious code could simply have modified the kernel to believe that
> > anything it asks the TPM returns the "correct" answer.
> 
> Right. To achieve the best possible security; you'd need Secure Boot
> to ensure that the kernel itself wasn't modified, and then the kernel
> establishes a dynamic root of trust itself.

You can't rely on Secure Boot because compromised firmware might fail to 
implement it, so you're back to relying on dynamic trust.

> Anything involving a boot loader (e.g. Secure Boot ensure's boot
> loader wasn't modified, then boot loader ensure's kernel wasn't
> modified, then ....) increases the attack surface for no benefit.

I honestly feel like we're talking about different things. Can you 
describe the attack vector you're concerned about here?

> I'm not convinced an external agent can detect "bad/forged
> measurement" either. E.g. if a MiTM boot loader always provided a
> bad/forged measurement the external agent won't detect it (as the
> measurement always matches the expected measurement), and then if the
> MiTM boot loader is replaced by a good/honest boot loader the external
> agent will decide that the good/honest boot loader is malicious
> because its measurement doesn't match the expected bad/forged
> measurement.

The point of DRTM is that the platform (in the form of an authenticated 
code module running on the CPU, outside of the control of the OS) 
performs a measreument of a specific point in time. The policy it's 
provided with allows an external agent to identify which component of 
the runtime system is being measured. If an external malicious agent has 
been executed then the measurement will be different as a result.