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
