<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 2/2/22 03:25, Greg KH wrote:<br>
</div>
<blockquote type="cite" cite="mid:Yfo%2F5gYgb9Sv24YB@kroah.com">
<pre class="moz-quote-pre" wrap="">On Wed, Feb 02, 2022 at 08:04:01AM +0000, Matthew Garrett wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Wed, Feb 02, 2022 at 08:22:03AM +0100, Ard Biesheuvel wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Wed, 2 Feb 2022 at 08:10, Matthew Garrett <a class="moz-txt-link-rfc2396E" href="mailto:mjg59@srcf.ucam.org"><mjg59@srcf.ucam.org></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
This came up a while ago during review of one of the earlier revisions
of this patch set.
<a class="moz-txt-link-freetext" href="https://lore.kernel.org/linux-efi/YRZuIIVIzMfgjtEl@google.com/">https://lore.kernel.org/linux-efi/YRZuIIVIzMfgjtEl@google.com/</a>
which describes another two variations on the theme, for pKVM guests
as well as Android bare metal.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<p>Thanks for adding us to this discussion.<br>
</p>
<p>If I have understood the discussion right, the key idea discussed
here is to unify multiple different interfaces(this one, and [1])
exposing secrets for confidential computing usecase via
securityfs.</p>
<p>And the suggestion is to see if the proposed pseries interface
[2] can unify with the coco interface.</p>
<p>At high level, pseries interface is
reading/writing/adding/deleting variables using the sysfs
interface, but the underlying semantics and actual usecases are
quite different.</p>
<p>The variables exposed via pseries proposed interface are:</p>
<p>* Variables owned by firmware as read-only.<br>
* Variables owned by bootloader as read-only.<br>
* Variables owned by OS and get updated as signed updates. These
support both read/write.<br>
* Variables owned by OS and get directly updated(unsigned) eg
config information or some boot variables. These support both
read/write.<br>
</p>
<p>It can be extended to support variables which contain secrets
like symmetric keys, are owned by OS and stored in platform
keystore.</p>
<p>Naming convention wise also, there are differences like pseries
variables do not use GUIDs.</p>
<p>The initial patchset discusses secure boot usecase, but it would
be extended for other usecases as well.<br>
</p>
<p>First, I feel the purpose itself is different here. If we still
continue, I fear if we will get into similar situation as Matthew
mentioned in context of efivars - <br>
</p>
<pre style="font-size: 13px; font-family: monospace; background: rgb(255, 255, 255); color: rgb(0, 0, 51); white-space: pre-wrap; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">"the patches to add support for
manipulating the Power secure boot keys originally attempted to make it
look like efivars, but the underlying firmware semantics are
sufficiently different that even exposing the same kernel interface
wouldn't be a sufficient abstraction and userland would still need to
behave differently. Exposing an interface that looks consistent but
isn't is arguably worse for userland than exposing explicitly distinct
interfaces." </pre>
<p>With that, I believe the scope of pseries interface is different
and much broader than being discussed here. So, I wonder if it
would be better to still keep pseries interface separate from this
and have its own platform specific interface.<br>
</p>
<p>I would be happy to hear the ideas.<br>
</p>
<p>[1]
<a class="moz-txt-link-freetext" href="https://lore.kernel.org/linux-efi/YRZuIIVIzMfgjtEl@google.com/">https://lore.kernel.org/linux-efi/YRZuIIVIzMfgjtEl@google.com/</a></p>
<p>[2]
<a class="moz-txt-link-freetext" href="https://lore.kernel.org/all/20220122005637.28199-1-nayna@linux.ibm.com/">https://lore.kernel.org/all/20220122005637.28199-1-nayna@linux.ibm.com/</a><br>
</p>
<p>Thanks & Regards,</p>
<p> - Nayna<br>
</p>
</body>
</html>