On 14 May 2018 at 09:50, tip-bot for Hans de Goede <[email protected]> wrote: > Commit-ID: 1de3a1be8a9345fd0c7d9bb1009b21afe6b6b10f > Gitweb: > https://git.kernel.org/tip/1de3a1be8a9345fd0c7d9bb1009b21afe6b6b10f > Author: Hans de Goede <[email protected]> > AuthorDate: Fri, 4 May 2018 08:00:01 +0200 > Committer: Ingo Molnar <[email protected]> > CommitDate: Mon, 14 May 2018 08:57:49 +0200 > > efi/x86: Ignore unrealistically large option ROMs > > setup_efi_pci() tries to save a copy of each PCI option ROM as this may > be necessary for the device driver for the PCI device to have access too. > > On some systems the efi_pci_io_protocol's romimage and romsize fields > contain invalid data, which looks a bit like pointers pointing back into > other EFI code or data. Interpreting these pointers as romsize leads to > a very large value and if we then try to alloc this amount of memory to > save a copy the alloc call fails. > > This leads to a "Failed to alloc mem for rom" error being printed on the > EFI console for each PCI device. > > This commit avoids the printing of these errors, by checking romsize before > doing the alloc and if it is larger then the EFI spec limit of 16 MiB > silently ignore the ROM fields instead of trying to alloc mem and fail. > > Tested-by: Hans de Goede <[email protected]> > [ardb: deduplicate 32/64 bit changes, use SZ_16M symbolic constant] > Signed-off-by: Hans de Goede <[email protected]> > Signed-off-by: Ard Biesheuvel <[email protected]>
This looks odd now: I sent this out as Signed-off-by: Hans de Goede <[email protected]> [ardb: deduplicate 32/64 bit changes, use SZ_16M symbolic constant] Tested-by: Hans de Goede <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> which clearly conveys that Hans tested the updated version of the patch. In general, I don't think there is a need to reorder signoffs unless there is anything wrong with them, no? > Cc: Linus Torvalds <[email protected]> > Cc: Matt Fleming <[email protected]> > Cc: Peter Zijlstra <[email protected]> > Cc: Thomas Gleixner <[email protected]> > Cc: [email protected] > Link: > http://lkml.kernel.org/r/[email protected] > Signed-off-by: Ingo Molnar <[email protected]> > --- > arch/x86/boot/compressed/eboot.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/boot/compressed/eboot.c > b/arch/x86/boot/compressed/eboot.c > index dadf32312082..a8a8642d2b0b 100644 > --- a/arch/x86/boot/compressed/eboot.c > +++ b/arch/x86/boot/compressed/eboot.c > @@ -123,10 +123,17 @@ __setup_efi_pci(efi_pci_io_protocol_t *pci, struct > pci_setup_rom **__rom) > if (status != EFI_SUCCESS) > return status; > > + /* > + * Some firmware images contain EFI function pointers at the place > where the > + * romimage and romsize fields are supposed to be. Typically the EFI > + * code is mapped at high addresses, translating to an unrealistically > + * large romsize. The UEFI spec limits the size of option ROMs to 16 > + * MiB so we reject any ROMs over 16 MiB in size to catch this. > + */ > romimage = (void *)(unsigned long)efi_table_attr(efi_pci_io_protocol, > romimage, pci); > romsize = efi_table_attr(efi_pci_io_protocol, romsize, pci); > - if (!romimage || !romsize) > + if (!romimage || !romsize || romsize > SZ_16M) > return EFI_INVALID_PARAMETER; > > size = romsize + sizeof(*rom);
