On 15.03.24 10:20, Ard Biesheuvel wrote:
On Fri, 15 Mar 2024 at 01:27, Tim Schumacher <timschumi@xxxxxx> wrote:
The UEFI specification does not make any mention of a maximum variable
name size, so the headers and implementation shouldn't claim that one
exists either.
Comments referring to this limit have been removed or rewritten, as this
is an implementation detail local to the Linux kernel.
Where appropriate, the magic value of 1024 has been replaced with
EFI_VAR_NAME_LEN, as this is used for the efi_variable struct
definition. This in itself does not change any behavior, but should
serve as points of interest when making future changes in the same area.
A related build-time check has been added to ensure that the special
512 byte sized buffer will not overflow with a potentially decreased
EFI_VAR_NAME_LEN.
Signed-off-by: Tim Schumacher <timschumi@xxxxxx>
Shouldn't we switch to 512 everywhere while at it?
We probably could, but my general aim for this is to eventually get rid of a
predetermined data storage size anyways.
The only part that needs guesswork is the sizing of the buffer for the
initial read (be it either by estimating a constant or by doing a
challenge-response thing), after that we can just measure the string
once (with an upper bound at the buffer size, similar to what
`var_name_strnsize` already does) and hold on to that length going forward.
The variable name storage situation still isn't entirely clear, so I
just wanted to get rid of most of the magic numbers for now, and guarded the
one "this would lead to a memory corruption with changed values" case with
`BUILD_BUG_ON`. I don't consider the define to be freely changeable at the
moment, but in case it seems like a good idea to someone else, we can at
least save them from one potential headache.
