[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