Re: [PATCH v2] xen/efi: Fix crash with initial empty EFI options

[Jan Beulich <jbeulich@suse.com>]

On 09.07.2025 11:07, Frediano Ziglio wrote:
> On Tue, Jul 8, 2025 at 4:41 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 08.07.2025 15:56, Frediano Ziglio wrote:
>>> EFI code path split options from EFI LoadOptions fields in 2
>>> pieces, first EFI options, second Xen options.
>>> "get_argv" function is called first to get the number of arguments
>>> in the LoadOptions, second, after allocating enough space, to
>>> fill some "argc"/"argv" variable. However the first parsing could
>>> be different from second as second is able to detect "--" argument
>>> separator. So it was possible that "argc" was bigger that the "argv"
>>> array leading to potential buffer overflows, in particular
>>> a string like "-- a b c" would lead to buffer overflow in "argv"
>>> resulting in crashes.
>>> Using EFI shell is possible to pass any kind of string in
>>> LoadOptions.
>>>
>>> Fixes: bf6501a62e80 ("x86-64: EFI boot code")
>>
>> Have you convinced yourself that your change isn't a workaround for a
>> bug elsewhere? You said you repro-ed with grub's chainloader, but that
>> doesn't imply things are being got correct there. I can certainly
>> accept that I may have screwed up back then. But I'd like to understand
>> what the mistake was, and so far I don't see any. As before, being
>> passed just "-- a b c" looks like a bug in the code generating the
>> command line.
>>
> 
> The only reason I put the "Fixes" comments it's that you always asked
> me to do so. From what you wrote it looks like you are taking it
> personally. I don't care much why there is the bug or when it was
> introduced, I found a crash in Xen and I want to fix it. Marek in
> another comment said Xen should not crash that way. IMO even if the
> bug turns out to be outside Xen and GRUB should always provide
> something as argv[0] Xen is failing validating the input received and
> good software should properly validate inputs.

Yes, such an issue wants fixing. But it's also relevant to understand
whether this is a workaround for something, or whether our code was
genuinely broken. In the latter case I'd further learn from that, whatever
it was that I didn't pay attention to back then. The EFI maintainers may
well view this differently, and it is them to eventually approve the patch
in whatever shape or form.

Jan