[PATCH v3 1/3] powerpc/powernv: Add OPAL API interface to get secureboot state

[Nayna]

On 06/12/2019 02:17 AM, Daniel Axtens wrote:
> Nayna Jain <nayna at linux.ibm.com> writes:
>
>> From: Claudio Carvalho <cclaudio at linux.ibm.com>
>>
>> The X.509 certificates trusted by the platform and other information
>> required to secure boot the OS kernel are wrapped in secure variables,
>> which are controlled by OPAL.
>>
>> This patch adds support to read OPAL secure variables through
>> OPAL_SECVAR_GET call. It returns the metadata and data for a given secure
>> variable based on the unique key.
>>
>> Since OPAL can support different types of backend which can vary in the
>> variable interpretation, a new OPAL API call named OPAL_SECVAR_BACKEND, is
>> added to retrieve the supported backend version. This helps the consumer
>> to know how to interpret the variable.
>>
> (Firstly, apologies that I haven't got around to asking about this yet!)
>
> Are pluggable/versioned backend a good idea?
>
> There are a few things that worry me about the idea:
>
>   - It adds complexity in crypto (or crypto-adjacent) code, and that
>     increases the likelihood that we'll accidentally add a bug with bad
>     consequences.

Sorry, I think I am not clear on what exactly you mean here.Can you 
please elaborate or give specifics ?


>
>   - Under what circumstances would would we change the kernel-visible
>     behaviour of skiboot? Are we expecting to change the behaviour,
>     content or names of the variables in future? Otherwise the only
>     relevant change I can think of is a change to hardware platforms, and
>     I'm not sure how a change in hardware would lead to change in
>     behaviour in the kernel. Wouldn't Skiboot hide h/w differences?

Backends are intended to be an agreement for firmware, kernel and 
userspace on what the format of variables are, what variables should be 
expected, how they should be signed, etc. Though we don't expect it to 
happen very often, we want to anticipate possible changes in the 
firmware which may affect the kernel such as new features, support of 
new authentication mechanisms, addition of new variables. Corresponding 
skiboot patches are on - 
https://lists.ozlabs.org/pipermail/skiboot/2019-June/014641.html


>
>   - If we are worried about a long-term-future change to how secure-boot
>     works, would it be better to just add more get/set calls to opal at
>     the point at which we actually implement the new system?

The intention is to avoid to re-implement the key/value interface for 
each scheme. Do you mean to deprecate the old APIs and add new APIs with 
every scheme ?


>     
>   - UEFI added EFI_VARIABLE_AUTHENTICATION_3 in a way that - as far
>     as I know - didn't break backwards compatibility. Is there a reason
>     we cannot add features that way instead? (It also dropped v1 of the
>     authentication header.)
>     
>   - What is the correct fallback behaviour if a kernel receives a result
>     that it does not expect? If a kernel expecting BackendV1 is instead
>     informed that it is running on BackendV2, then the cannot access the
>     secure variable at all, so it cannot load keys that are potentially
>     required to successfully boot (e.g. to validate the module for
>     network card or graphics!)

The backend is declaredby the firmware, and is set at compile-time. The 
kernel queriesfirmware on whichbackend is in use, and the backend will 
not change at runtime.If the backend in use by the firmware is not 
supported by the kernel (e.g. kernel is too old), the kernel does not 
attempt to read any secure variables, as it won't understand what the 
format is. This is a secure boot failure condition, as we cannot verify 
the next kernel. With addition of new backends in the skiboot, the 
support will be added to the kernel. Note: skiboot and skiroot should 
always be in sync with backend support.


Thanks & Regards,
     - Nayna

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20190612/b6d66bc2/attachment-0001.htm>