Hi,
> 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.
The implementation can be sorted later when a second implementation
shows up, but it'll be better if we don't have to change the naming
convention.
"coco/efi_secrets" doesn't look like a good choice to me, given that it
is rather likely we see more users for this showing up.
Having a "secrets/" directory looks good to me. Then the individual
implementations can either add files to the directory, i.e. efi_secrets
would create "secrets/<guid>" files. Or each implementation creates a
subdirectory with the secrets, i.e. "secrets/coco/" and
"secrets/coco/<guid>".
Longer-term (i.e once we have more than one implementation) we probably
need a separate module which owns and manages the "secrets/" directory,
and possibly provides some common helper functions too.
take care,
Gerd
On Wed, Feb 02, 2022 at 09:36:53AM +0100, Gerd Hoffmann wrote:
> Having a "secrets/" directory looks good to me. Then the individual
> implementations can either add files to the directory, i.e. efi_secrets
> would create "secrets/<guid>" files. Or each implementation creates a
> subdirectory with the secrets, i.e. "secrets/coco/" and
> "secrets/coco/<guid>".
I prefer a subdirectory, on the basis that we could conceivably end up
with more than one implementation on a single device at some point, and
also because it makes it trivial for userland to determine what the
source is which may make a semantic difference under certain
circumstances.
> Longer-term (i.e once we have more than one implementation) we probably
> need a separate module which owns and manages the "secrets/" directory,
> and possibly provides some common helper functions too.
Agree.
On 02/02/2022 10:45, Matthew Garrett wrote:
> On Wed, Feb 02, 2022 at 09:36:53AM +0100, Gerd Hoffmann wrote:
>
>> Having a "secrets/" directory looks good to me. Then the individual
>> implementations can either add files to the directory, i.e. efi_secrets
>> would create "secrets/<guid>" files. Or each implementation creates a
>> subdirectory with the secrets, i.e. "secrets/coco/" and
>> "secrets/coco/<guid>".
>
> I prefer a subdirectory, on the basis that we could conceivably end up
> with more than one implementation on a single device at some point, and
> also because it makes it trivial for userland to determine what the
> source is which may make a semantic difference under certain
> circumstances.
>
OK, sounds good. In the next round of the series the module will create
the files in <securityfs>/secrets/coco/ .
>> Longer-term (i.e once we have more than one implementation) we probably
>> need a separate module which owns and manages the "secrets/" directory,
>> and possibly provides some common helper functions too.
>
> Agree.
Yes; one candidate for such helper function is a filesystem that
implements the "wipe file content from memory on unlink".
-Dov