[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <08302ed1c056da86a71aa2e6ca19111075383e75.camel@linux.ibm.com>
Date: Sat, 14 Jan 2023 09:55:37 -0500
From: James Bottomley <jejb@...ux.ibm.com>
To: Matthew Garrett <mgarrett@...ora.tech>,
William Roberts <bill.c.roberts@...il.com>
Cc: Evan Green <evgreen@...omium.org>, linux-kernel@...r.kernel.org,
corbet@....net, linux-integrity@...r.kernel.org,
Eric Biggers <ebiggers@...nel.org>, gwendal@...omium.org,
dianders@...omium.org, apronin@...omium.org,
Pavel Machek <pavel@....cz>, Ben Boeckel <me@...boeckel.net>,
rjw@...ysocki.net, Kees Cook <keescook@...omium.org>,
dlunev@...gle.com, zohar@...ux.ibm.com, jarkko@...nel.org,
linux-pm@...r.kernel.org, Matthew Garrett <mjg59@...gle.com>,
Jason Gunthorpe <jgg@...pe.ca>, Peter Huewe <peterhuewe@....de>
Subject: Re: [PATCH v5 03/11] tpm: Allow PCR 23 to be restricted to
kernel-only use
On Tue, 2023-01-03 at 13:10 -0800, Matthew Garrett wrote:
> On Tue, Jan 3, 2023 at 1:05 PM William Roberts
> <bill.c.roberts@...il.com> wrote:
>
> > What's the use case of using the creation data and ticket in this
> > context? Who gets the creationData and the ticket?
> > Could a user supplied outsideInfo work? IIRC I saw some patches
> > flying around where the sessions will get encrypted and presumably
> > correctly as well. This would allow the transfer of that
> > outsideInfo, like the NV Index PCR value to be included and
> > integrity protected by the session HMAC.
>
> The goal is to ensure that the key was generated by the kernel. In
> the absence of the creation data, an attacker could generate a
> hibernation image using their own key and trick the kernel into
> resuming arbitrary code. We don't have any way to pass secret data
> from the hibernate kernel to the resume kernel, so I don't think
> there's any easy way to do it with outsideinfo.
Can we go back again to why you can't use locality? It's exactly
designed for this since locality is part of creation data. Currently
everything only uses locality 0, so it's impossible for anyone on Linux
to produce a key with anything other than 0 in the creation data for
locality. However, the dynamic launch people are proposing that the
Kernel should use Locality 2 for all its operations, which would allow
you to distinguish a key created by the kernel from one created by a
user by locality.
I think the previous objection was that not all TPMs implement
locality, but then not all laptops have TPMs either, so if you ever
come across one which has a TPM but no locality, it's in a very similar
security boat to one which has no TPM.
James
Powered by blists - more mailing lists