lkml.org 
[lkml]   [2018]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [tip:efi/core] efi/x86: Ignore unrealistically large option ROMs
On 14 May 2018 at 09:50, tip-bot for Hans de Goede <tipbot@zytor.com> wrote:
> Commit-ID: 1de3a1be8a9345fd0c7d9bb1009b21afe6b6b10f
> Gitweb: https://git.kernel.org/tip/1de3a1be8a9345fd0c7d9bb1009b21afe6b6b10f
> Author: Hans de Goede <hdegoede@redhat.com>
> AuthorDate: Fri, 4 May 2018 08:00:01 +0200
> Committer: Ingo Molnar <mingo@kernel.org>
> 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 <hdegoede@redhat.com>
> [ardb: deduplicate 32/64 bit changes, use SZ_16M symbolic constant]
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

This looks odd now: I sent this out as

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
[ardb: deduplicate 32/64 bit changes, use SZ_16M symbolic constant]
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

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 <torvalds@linux-foundation.org>
> Cc: Matt Fleming <matt@codeblueprint.co.uk>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: linux-efi@vger.kernel.org
> Link: http://lkml.kernel.org/r/20180504060003.19618-16-ard.biesheuvel@linaro.org
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
> ---
> 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);

\
 
 \ /
  Last update: 2018-05-15 11:19    [W:0.132 / U:1.964 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site