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@xxxxxxxxxxxxx> 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@xxxxxxxxxx/ > > > > 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
