[Skiboot] [RFC v2 2/8] doc: add opal secvar documentation

[Michael Ellerman]

Hi Eric,

A query below ...

Eric Richter <erichte at linux.ibm.com> writes:
> This patch contains all the relevant documentation for the secure variable
> support in OPAL. This may be split and squashed with their relevant
> implementations in the future, but kept separate for now.
>
> Notably missing at the moment is the documentation for the SECBOOT PNOR
> partition usage, which will be included in a future revision.
>
...
> +OPAL_SECVAR_GET
> +===============
> +::
> +
> +   #define OPAL_SECVAR_GET                         170
> +
> +``OPAL_SECVAR_GET`` call retrieves a data blob associated with the supplied
> +name and vendor guid.
> +
> +Parameters
> +----------
> +::
> +
> +   char16_t *name
> +   guid_t   *vendor
> +   uint32_t *attributes
> +   uint64_t *data_size
> +   void     *data
> +
> +``name``
> +   the name of the requested variable as a 16-bit char
> +
> +``vendor``
> +   the vendor guid of the requested variable
> +
> +``attributes``
> +   optional bitfield reference to be set by OPAL for attributes

I understand the UCS-2 name and guid come from UEFI, but is that really
something we need to bake into the OPAL API?

It seems the (name + vendor) essentially form a key, so could we just
make the API take a key as a byte array? That way we're not tying the
OPAL API or implementation to any details of UEFI, while still allowing
the user of the API (the kernel) to use UEFI style keys if it wants to.

So eg. the parameters for OPAL_SECVAR_GET would be:

   char     *key
   uint32_t key_len
   uint32_t *attributes
   uint64_t *data_size
   void     *data


The kernel could construct the key as the concatenation of the UCS-2
name & vendor or vice versa, or a simple byte string or whatever it
likes.

cheers