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

Eric Richter 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
> stuff?

...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
more sense.

> 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