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

[Eric Richter]

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
>