On 08/30/2012 02:30 AM, Jeremy Kerr wrote:
> From: Matthew Garrett <[email protected]>
>
> The existing EFI variables code only supports variables of up to 1024
> bytes. This limitation existed in version 0.99 of the EFI specification,
> but was removed before any full releases. Since variables can now be
> larger than a single page, sysfs isn't the best interface for this. So,
> instead, let's add a filesystem. Variables can be read, written and
> created, with the first 4 bytes of each variable representing its UEFI
> attributes. The create() method doesn't actually commit to flash since
> zero-length variables can't exist per-spec.
>
> Updates from Jeremy Kerr <[email protected]>.
>
> Signed-off-by: Matthew Garrett <[email protected]>
> Signed-off-by: Jeremy Kerr <[email protected]>
>
> ---
> RFC: With this patch, I can properly mange UEFI key databases from
> userspace. Comments welcome.
>
Nice!
However, I have a question... rather than putting the attributes as the
first data bytes, would it be better to make it either part of the
filename (assuming there is at least one character other than / which
can be reasonably relied upon to not be part of the name); for example:
LangCodes,BS,RT
... or ...
LangCodes,6
-hpa
Hi hpa,
Thanks for the review!
> However, I have a question... rather than putting the attributes as the
> first data bytes, would it be better to make it either part of the
> filename (assuming there is at least one character other than / which
> can be reasonably relied upon to not be part of the name); for example:
>
> LangCodes,BS,RT
>
> ... or ...
>
> LangCodes,6
This will get tricky when handling EFI_VARIABLE_APPEND_WRITE: this
attribute will never appear in the attributes returned by GetVariable(),
but may be passed to SetVariable(). If we put attributes in the
filename, we'd need to handle writes to both names, and/or have
duplicate dentries for each variable. We could do it, but the filesystem
interface might be a little messy.
[Supporting append writes is essential for key database updates, which
may be signed]
Cheers,
Jeremy
Wouldn't that be better handled by O_APPEND?
Jeremy Kerr <[email protected]> wrote:
>Hi hpa,
>
>Thanks for the review!
>
>> However, I have a question... rather than putting the attributes as
>the
>> first data bytes, would it be better to make it either part of the
>> filename (assuming there is at least one character other than / which
>> can be reasonably relied upon to not be part of the name); for
>example:
>>
>> LangCodes,BS,RT
>>
>> ... or ...
>>
>> LangCodes,6
>
>This will get tricky when handling EFI_VARIABLE_APPEND_WRITE: this
>attribute will never appear in the attributes returned by
>GetVariable(),
>but may be passed to SetVariable(). If we put attributes in the
>filename, we'd need to handle writes to both names, and/or have
>duplicate dentries for each variable. We could do it, but the
>filesystem
>interface might be a little messy.
>
>[Supporting append writes is essential for key database updates, which
>may be signed]
>
>Cheers,
>
>
>Jeremy
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.