On 02.12.22 17:07, Michael Adler wrote: > An integer underflow results in the attempt to SetMem a region of > impossible size and thus crashing the machine. > For example, this can happen if something is wrong with the image > assembly process (which was the case for me, even though I used > bg_gen_unified_kernel). > This commit doesn't change the fact that the UKI won't boot, but at > least it won't crash the machine and more importantly, it will tell you > exactly what's wrong and (hopefully) save you some debugging time. > > Signed-off-by: Michael Adler <[email protected]> > --- > kernel-stub/main.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/kernel-stub/main.c b/kernel-stub/main.c > index c0be1f6..1e138c4 100644 > --- a/kernel-stub/main.c > +++ b/kernel-stub/main.c > @@ -198,6 +198,13 @@ EFI_STATUS efi_main(EFI_HANDLE image_handle, > EFI_SYSTEM_TABLE *system_table) > kernel_image.ImageSize = kernel_section->VirtualSize; > > CopyMem(kernel_image.ImageBase, kernel_source, kernel_image.ImageSize); > + > + /* check for underflow, otherwise zeroing .bss crashes the machine */ > + if (pe_header->Opt.SizeOfImage < kernel_image.ImageSize) { > + status = EFI_INVALID_PARAMETER; > + error(L"Error: SizeOfImage smaller than kernel ImageSize", > status); > + goto cleanup_buffer; > + } > /* Clear the rest so that .bss is definitely zero. */ > SetMem((UINT8 *) kernel_image.ImageBase + kernel_image.ImageSize, > pe_header->Opt.SizeOfImage - kernel_image.ImageSize, 0);
All that should be signed, so this is "just" a safety measure, right? Is that enough, or should we look systematically for such things? Jan -- Siemens AG, Technology Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/15b3629a-2e87-c53c-0805-4663b9b7f65a%40siemens.com.
