Re: [Xen-devel] [PATCHv2] xen: Add EFI_LOAD_OPTION support

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.01.18 at 17:25, <tamas@xxxxxxxxxxxxx> wrote:
> On Fri, Jan 19, 2018 at 2:12 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>> And then - how about a different heuristic altogether: Current
>> code scans the pointed to memory for a nul character, being
>> happy if it is found before having exhausted cmdsize.
> 
> I'm not sure what you are talking about. The nul char is not at the
> end of the EFI_LOAD_OPTION, it is only at the end of the Description
> array. And we have to scan for it because the length of the
> Description array is not recorded anywhere else. So we scan for the
> nul char in the part of the buffer where it would be warranted by the
> EFI spec, then compute the location of the actual option buffer based
> on that checking that it is within bounds of the buffer.

By "current code" I mean what's upstream at present, not yours.
I.e. I'm suggesting to consider proving it's a nul-terminated string
instead of proving its an EFI_LOAD_OPTION structure.

Jan

>> Why not
>> simply scan for the first nul and conclude it's an EFI_LOAD_OPTION
>> structure if that nul isn't right at the end of the buffer?
> 
> I don't follow, how would that be more robust then checking that NULL
> is in the right space within the EFI_LOAD_OPTION according to spec?
> 
>> One could
>> even consider scanning for more than just nul, e.g. any non-blank
>> character with a numeric value below 0x0020.
> 
> Perhaps, but I think that's an overkill. Again, what are the chances
> that a non-EFI loader will pass a string buffer that happens to also
> properly parse as an EFI_LOAD_OPTION?
> 
> Tamas




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel