On 06/02/2016 11:24 AM, Matt Fleming wrote:
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.
I have tested that this does indeed fix the warning for Andy's value of
->image_address, but off course I can't test this with the actual
hardware that Andy has. Do you want me to resend this with a commit
message so it can be applied?
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
