On Sun, 29 May, at 06:09:01AM, Môshe van der Sterre wrote:
> ---
> arch/x86/platform/efi/efi-bgrt.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c
> index 6a2f569..a7fdb61 100644
> --- a/arch/x86/platform/efi/efi-bgrt.c
> +++ b/arch/x86/platform/efi/efi-bgrt.c
> @@ -19,6 +19,8 @@
> #include <linux/efi.h>
> #include <linux/efi-bgrt.h>
>
> +#include "../../mm/physaddr.h"
> +
> struct acpi_table_bgrt *bgrt_tab;
> void *__initdata bgrt_image;
> size_t __initdata bgrt_image_size;
> @@ -67,6 +69,11 @@ void __init efi_bgrt_init(void)
> return;
> }
>
> + if (!phys_addr_valid(bgrt_tab->image_address)) {
> + pr_notice("Ignoring BGRT: image address is bogus\n");
> + return;
> + }
> +
> image = memremap(bgrt_tab->image_address, sizeof(bmp_header), MEMREMAP_WB);
> if (!image) {
> pr_notice("Ignoring BGRT: failed to map image header memory\n");
> --
> 2.4.3
>
If this does indeed fix Andy's immediate issue (and it looks like
it would) I'm happy to apply this as an interim solution.
Once we have a persistent EFI memmap available at runtime on x86 we
should attempt to see whether the physical address in ->image_address
is covered by some region in that table. The persistent EFI memmap
patches should be posted in the coming weeks.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
