[Skiboot] [PATCH v4 04/11] doc: add opal secure variable documentation
erichte at linux.ibm.com
Thu Oct 31 14:06:48 AEDT 2019
On 10/30/19 9:46 PM, Michael Ellerman wrote:
> 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.
We don't currently have any tools that check for this, but this information
should be available. Ideally, a script, or petitboot should report the status
of the update to the user.
> Shouldn't the status be exported via sysfs along with the other secvar
...and so maybe it should belong in sysfs as well, but the information still needs
to be handed to the kernel in some form.
>> 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 the value is exposed in sysfs, should the kernel translate the value to
something else? A Linux/POSIX error code or a user-friendly string?
A sysadmin would likely inspect the OPAL msglog for more detail if there were
an error, so I would suspect keeping this as a programmatic value would make
> 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
>>> 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.
More information about the Skiboot