On Mon, 2021-05-24 at 09:31 -0700, Andi Kleen wrote:

On 5/24/2021 5:08 AM, Dr. David Alan Gilbert wrote:

quoted

* Andi K
Is there any way we could merge these two so that the TDX/SVKL
would look similar to SEV/ES to userspace?  If we needed some
initrd glue here for luks it would be great if we could have one
piece of glue. [I'm not sure if the numbering/naming of the
secrets, and their format are defined in the same way]

Maybe. There might well be differences in the contents as you say.
So far SVKL doesn't really exist yet,  initially there will be the
initrd based agents. The agents definitely will need to know about
TDX.

quoted

Do you think the ioctl is preferable to read+ftruncate/unlink ?
And if it was an ioctl, again could we get some standardisation
here - i.e. maybe a /dev/confguest with a CONF_COMP_GET_KEY etc ?

The advantage of the two ioctls is that they are very simple.
Anything with a file system would be a lot more complicated. For
security related code simplicity is a virtue.

This RFC contained the FS code.  In size terms its very comparable to
your ioctl.

Also since it's a really simple read and clear model I don't expect
the value to be used widely, since it will be gone after boot
anyways.

Enumeration looks to be problematic with your interface ... what are
you supposed to do, keep calling ACPI_SVKL_GET_KEY_INFO on an advancing
index until it gives you an error and then try to work out what key
you're interested in by one of its numeric properties?

I think a GUIDed structure actually helps here because we don't have to
have someone assign, say, u16 types to keys we're interested in and the
filesystem does all the enumeration for us.  It also means new use
cases can simply expand the properties without waiting for any
internals to catch up.

James