Re: [PATCH v7 0/5] Allow guest access to EFI confidential computing secret area

Greg KH
2022-02-02T08:25:21Z

On Wed, Feb 02, 2022 at 08:04:01AM +0000, Matthew Garrett wrote:
> On Wed, Feb 02, 2022 at 08:22:03AM +0100, Ard Biesheuvel wrote:
> > On Wed, 2 Feb 2022 at 08:10, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > > Which other examples are you thinking of? I think this conversation may
> > > have accidentally become conflated with a different prior one and now
> > > we're talking at cross purposes.
> >
> > This came up a while ago during review of one of the earlier revisions
> > of this patch set.
> >
> > https://lore.kernel.org/linux-efi/YRZuIIVIzMfgjtEl@google.com/
> >
> > which describes another two variations on the theme, for pKVM guests
> > as well as Android bare metal.
>
> Oh, I see! That makes much more sense - sorry, I wasn't Cc:ed on that,
> so thought this was related to the efivars/Power secure boot. My
> apologies, sorry for the noise. In that case, given the apparent
> agreement between the patch owners that a consistent interface would
> work for them, I think I agree with Greg that we should strive for that.
> Given the described behaviour of the Google implementation, it feels
> like the semantics in this implementation would be sufficient for them
> as well, but having confirmation of that would be helpful.
>
> On the other hand, I also agree that a new filesystem for this is
> overkill. I did that for efivarfs and I think the primary lesson from
> that is that people who aren't familiar with the vfs shouldn't be
> writing filesystems. Securityfs seems entirely reasonable, and it's
> consistent with other cases where we expose firmware-provided data
> that's security relevant.
>
> The only thing I personally struggle with here is whether "coco" is the
> best name for it, and whether there are reasonable use cases that
> wouldn't be directly related to confidential computing (eg, if the
> firmware on a bare-metal platform had a mechanism for exposing secrets
> to the OS based on some specific platform security state, it would seem
> reasonable to expose it via this mechanism but it may not be what we'd
> normally think of as Confidential Computing).
>
> But I'd also say that while we only have one implementation currently
> sending patches, it's fine for the code to live in that implementation
> and then be abstracted out once we have another.

Well right now the Android code looks the cleanest and should be about
ready to be merged into my tree.

But I can almost guarantee that that interface is not what anyone else
wants to use, so if you think somehow that everyone else is going to
want to deal with a char device node and a simple mmap, with a DT
description of the thing, hey, I'm all for it :)

Seriously, people need to come up with something sane or this is going
to be a total mess.

thanks,

greg k-h