[Skiboot] [PATCH v4 04/11] doc: add opal secure variable documentation

Michael Ellerman mpe at ellerman.id.au
Thu Oct 31 13:46:26 AEDT 2019


Eric Richter <erichte at linux.ibm.com> writes:
> On 10/28/19 10:47 PM, Michael Ellerman wrote:
>> Eric Richter <erichte at linux.ibm.com> writes:
...
>>> +    update-status:      contains the return code of the update queue
>>> +                        process run during initialization. Signifies if
>>> +                        updates were processed or not, and if there was
>>> +                        an error. See table below.
>> 
>> Encoded how? I assume you mean as a u32, but please say so.
>> 
>> This is a bit weird, encoding an OPAL return value in a property. I
>> don't understand how the kernel is going to use it. I don't see any
>> patches posted yet that use it?
>> 
>
> It is a u64, will update to mention that.
>
> This isn't a property intended for the kernel to consume, meant for exposing
> to userspace the status of update. Update processing is handled at boot, so
> outside of writing to a log, it seemed like the best way to signal status
> to a user.

But are we expecting a user to look at the device tree to find the
status? That seems suboptimal.

Shouldn't the status be exported via sysfs along with the other secvar
stuff?

> As for the use of OPAL codes: they were convenient to use as they matched the
> error cases that likely all backends will share. Would it be more clear to
> define a new set of return codes, or represent this information in a
> different way?

Using the OPAL codes is fine, if the kernel is going to consume them.

If userspace is going to consume them then I think you'd be better off
using Linux (I guess POSIX) error codes, or possibly a string.

>>> +
>>> +    os-secure-enforcing: If this property exists, the system is in
>>> +                        considered to be in "OS secure mode". Kexec
>>> +                        images should be signature checked, etc.
>> 
>> That's a bit vague, ie. "considered" is not very clear, and this spec
>> shouldn't talk about things like kexec, that's a Linux implementation
>> detail.
>> 
>> What does the presence of this property mean? I think it means that the
>> owner/user of the system has expressed a desire that the boot loader
>> and/or operating system implement "secure boot", ie. only images that
>> are signed by an appropriate key will be loaded. If no such image is
>> found the system must not boot. I think?
>> 
>
> This is correct, I will adjust the description to be less Linux-centric.

Thanks.

cheers


More information about the Skiboot mailing list