More EFI updates for v5.6
Subsystems (5)
Ard Biesheuvel
maintainerThe following changes since commit 4444f8541dad16fefd9b8807ad1451e806ef1d94:
efi: Allow disabling PCI busmastering on bridges during boot (2020-01-10 18:55:04 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-next
for you to fetch changes up to 743c5dd59f7e4b9e7a28be6a8f0e8d03271a98ab:
efi: Fix handling of multiple efi_fake_mem= entries (2020-01-13 10:41:53 +0100)
----------------------------------------------------------------
Third and final batch of EFI updates for v5.6:
- A few touchups for the x86 libstub changes that have already been queued up.
- Fix memory leaks and crash bugs in the EFI fake_mem driver, which may be used more heavily in the future for device-dax soft reservation (Dan)
- Avoid RWX mappings in the EFI page tables when possible.
- Avoid PCIe probing failures if the EFI framebuffer is probed first when the new of_devlink feature is active.
- Move the support code for the old EFI memory mapping style into its only user, the SGI UV1+ support code.
----------------------------------------------------------------
Anshuman Khandual (1):
efi: Fix comment for efi_mem_type() wrt absent physical addresses
Ard Biesheuvel (7):
efi/libstub/x86: use const attribute for efi_is_64bit() efi/libstub/x86: use mandatory 16-byte stack alignment in mixed mode x86/mm: fix NX bit clearing issue in kernel_map_pages_in_pgd efi/x86: don't map the entire kernel text RW for mixed mode efi/x86: avoid RWX mappings for all of DRAM
efi/x86: limit EFI old memory map to SGI UV machines efi/arm: defer probe of PCIe backed efifb on DT systems
Arnd Bergmann (1):
efi/libstub/x86: fix unused-variable warning
Dan Williams (4):
efi: Add a flags parameter to efi_memory_map
efi: Add tracking for dynamically allocated memmaps
efi: Fix efi_memmap_alloc() leaks
efi: Fix handling of multiple efi_fake_mem= entries
Documentation/admin-guide/kernel-parameters.txt | 3 +- arch/x86/boot/compressed/eboot.c | 16 +- arch/x86/boot/compressed/efi_thunk_64.S | 46 ++---- arch/x86/boot/compressed/head_64.S | 7 +- arch/x86/include/asm/efi.h | 28 ++-- arch/x86/kernel/kexec-bzimage64.c | 2 +- arch/x86/mm/pat/set_memory.c | 8 +- arch/x86/platform/efi/efi.c | 40 +++-- arch/x86/platform/efi/efi_64.c | 190 ++++-------------------- arch/x86/platform/efi/quirks.c | 44 +++--- arch/x86/platform/uv/bios_uv.c | 164 +++++++++++++++++++- drivers/firmware/efi/arm-init.c | 107 ++++++++++++- drivers/firmware/efi/efi.c | 2 +- drivers/firmware/efi/fake_mem.c | 43 +++--- drivers/firmware/efi/memmap.c | 95 ++++++++---- include/linux/efi.h | 17 ++- 16 files changed, 471 insertions(+), 341 deletions(-)
Ard Biesheuvel
maintainerPATCH 1/13 efi/libstub/x86: use const attribute for efi_is_64bit()
Reshuffle the x86 stub code a bit so that we can tag the efi_is_64bit() function with the 'const' attribute, which permits the compiler to optimize away any redundant calls. Since we have two different entry points for 32 and 64 bit firmware in the startup code, this also simplifies the C code since we'll enter it with the efi_is64 variable already set.
--- arch/x86/boot/compressed/eboot.c | 14 ++++++-------- arch/x86/boot/compressed/head_64.S | 7 +++---- arch/x86/include/asm/efi.h | 2 +- 3 files changed, 10 insertions(+), 13 deletions(-)
arch/x86/boot/compressed/eboot.c +6 -8
@@ -21,16 +21,18 @@#include "eboot.h" static efi_system_table_t *sys_table; -static bool efi_is64 =IS_ENABLED (CONFIG_X86_64 ); +extern const bool efi_is64;__pure efi_system_table_t *efi_system_table (void ) {return sys_table; } -__pure bool efi_is_64bit (void ) +__attribute_const__ bool efi_is_64bit(void) { -return efi_is64; +if (IS_ENABLED (CONFIG_EFI_MIXED )) +return efi_is64; +return IS_ENABLED (CONFIG_X64_64 ); } static efi_status_t
@@ -710,8 +712,7 @@ static efi_status_t exit_boot(struct boot_params *boot_params, void *handle)*/ struct boot_params *efi_main (efi_handle_t handle,efi_system_table_t *sys_table_arg, -struct boot_params *boot_params, -bool is64) +struct boot_params *boot_params) {struct desc_ptr *gdt =NULL ;struct setup_header *hdr = &boot_params->hdr;
@@ -721,9 +722,6 @@ struct boot_params *efi_main(efi_handle_t handle, sys_table = sys_table_arg; -if (IS_ENABLED (CONFIG_EFI_MIXED )) - efi_is64 = is64; -/* Check if we were booted by the EFI firmware */ if (sys_table->hdr.signature !=EFI_SYSTEM_TABLE_SIGNATURE ) goto fail;
arch/x86/boot/compressed/head_64.S +3 -4
@@ -211,10 +211,9 @@ SYM_FUNC_START(startup_32) movl efi32_boot_args(%ebp), %edi cmp $0, %edi jz 1f - leal handover_entry(%ebp), %eax + leal efi64_stub_entry(%ebp), %eax movl %esi, %edx movl efi32_boot_args+4(%ebp), %esi - movl $0x0, %ecx 1: #endif pushl %eax
@@ -242,6 +241,7 @@ SYM_FUNC_START(efi32_stub_entry) movl %ecx, efi32_boot_args(%ebp) movl %edx, efi32_boot_args+4(%ebp) sgdtl efi32_boot_gdt(%ebp) + movb $0, efi_is64(%ebp) /* Disable paging */ movl %cr0, %eax
@@ -452,8 +452,6 @@ SYM_CODE_END(startup_64) .org 0x390 SYM_FUNC_START(efi64_stub_entry) SYM_FUNC_START_ALIAS(efi_stub_entry) - movq $1, %rcx -SYM_INNER_LABEL(handover_entry, SYM_L_LOCAL) and $~0xf, %rsp /* realign the stack */ call efi_main movq %rax,%rsi
@@ -632,6 +630,7 @@ SYM_DATA_END_LABEL(gdt, SYM_L_LOCAL, gdt_end) #ifdef CONFIG_EFI_MIXED SYM_DATA_LOCAL(efi32_boot_args, .long 0, 0) +SYM_DATA(efi_is64, .byte 1) #endif /*
arch/x86/include/asm/efi.h +1 -1
@@ -221,7 +221,7 @@ efi_status_t efi_set_virtual_address_map(unsigned long memory_map_size,/* arch specific definitions used by the stub code */ -__pure bool efi_is_64bit (void ); +__attribute_const__ bool efi_is_64bit(void);static inline bool efi_is_native (void ) {
Signature · 1 line
2.20.1
Ard Biesheuvel
maintainerPATCH 2/13 efi/libstub/x86: use mandatory 16-byte stack alignment in mixed mode
In reply to Ard BiesheuvelReduce the stack frame of the EFI stub's mixed mode thunk routine by 8 bytes, by moving the GDT and return addresses to EBP and EBX, which we need to preserve anyway, since their top halves will be cleared by the call into 32-bit firmware code. Doing so results in the UEFI code being entered with a 16 byte aligned stack, as mandated by the UEFI spec, fixing the last occurrence in the 64-bit kernel where we violate this requirement.
Also, move the saved GDT from a global variable to an unused part of the stack frame, and touch up some other parts of the code.
--- arch/x86/boot/compressed/efi_thunk_64.S | 46 +++++++------------------ 1 file changed, 13 insertions(+), 33 deletions(-)
arch/x86/boot/compressed/efi_thunk_64.S +13 -33
@@ -27,12 +27,9 @@ SYM_FUNC_START(__efi64_thunk) push %rbp push %rbx - subq $8, %rsp - leaq 1f(%rip), %rax - movl %eax, 4(%rsp) - leaq efi_gdt64(%rip), %rax - movl %eax, (%rsp) - movl %eax, 2(%rax) /* Fixup the gdt base address */ + leaq 1f(%rip), %rbp + leaq efi_gdt64(%rip), %rbx + movl %ebx, 2(%rbx) /* Fixup the gdt base address */ movl %ds, %eax push %rax
@@ -48,12 +45,10 @@ SYM_FUNC_START(__efi64_thunk) movl %esi, 0x0(%rsp) movl %edx, 0x4(%rsp) movl %ecx, 0x8(%rsp) - movq %r8, %rsi - movl %esi, 0xc(%rsp) - movq %r9, %rsi - movl %esi, 0x10(%rsp) + movl %r8d, 0xc(%rsp) + movl %r9d, 0x10(%rsp) - sgdt save_gdt(%rip) + sgdt 0x14(%rsp) /* * Switch to gdt with 32-bit segments. This is the firmware GDT
@@ -68,11 +63,10 @@ SYM_FUNC_START(__efi64_thunk) pushq %rax lretq -1: addq $32, %rsp +1: lgdt 0x14(%rsp) + addq $32, %rsp movq %rdi, %rax - lgdt save_gdt(%rip) - pop %rbx movl %ebx, %ss pop %rbx
@@ -83,15 +77,9 @@ SYM_FUNC_START(__efi64_thunk) /* * Convert 32-bit status code into 64-bit. */ - test %rax, %rax - jz 1f - movl %eax, %ecx - andl $0x0fffffff, %ecx - andl $0xf0000000, %eax - shl $32, %rax - or %rcx, %rax -1: - addq $8, %rsp + roll $1, %eax + rorq $1, %rax + pop %rbx pop %rbp ret
@@ -135,9 +123,7 @@ SYM_FUNC_START_LOCAL(efi_enter32) */ cli - movl 56(%esp), %eax - movl %eax, 2(%eax) - lgdtl (%eax) + lgdtl (%ebx) movl %cr4, %eax btsl $(X86_CR4_PAE_BIT), %eax
@@ -154,9 +140,8 @@ SYM_FUNC_START_LOCAL(efi_enter32) xorl %eax, %eax lldt %ax - movl 60(%esp), %eax pushl $__KERNEL_CS - pushl %eax + pushl %ebp /* Enable paging */ movl %cr0, %eax
@@ -172,11 +157,6 @@ SYM_DATA_START(efi32_boot_gdt) .quad 0 SYM_DATA_END(efi32_boot_gdt) -SYM_DATA_START_LOCAL(save_gdt) - .word 0 - .quad 0 -SYM_DATA_END(save_gdt) - SYM_DATA_START(efi_gdt64) .word efi_gdt64_end - efi_gdt64 .long 0 /* Filled out by user */
Signature · 1 line
2.20.1
Ard Biesheuvel
maintainerPATCH 3/13 efi/libstub/x86: fix unused-variable warning
In reply to Ard BiesheuvelFrom: Arnd Bergmann <[email protected]>
The only users of these got removed, so they also need to be removed to avoid warnings:
arch/x86/boot/compressed/eboot.c: In function 'setup_efi_pci':arch/x86/boot/compressed/eboot.c:117:16: error: unused variable 'nr_pci' [-Werror=unused-variable]
unsigned long nr_pci;
^~~~~~
arch/x86/boot/compressed/eboot.c: In function 'setup_uga':
arch/x86/boot/compressed/eboot.c:244:16: error: unused variable 'nr_ugas' [-Werror=unused-variable]
unsigned long nr_ugas;
^~~~~~~--- arch/x86/boot/compressed/eboot.c | 2 -- 1 file changed, 2 deletions(-)
arch/x86/boot/compressed/eboot.c +0 -2
@@ -118,7 +118,6 @@ static void setup_efi_pci(struct boot_params *params)void **pci_handle =NULL ;efi_guid_t pci_proto =EFI_PCI_IO_PROTOCOL_GUID ;unsigned long size =0 ; -unsigned long nr_pci;struct setup_data *data;efi_handle_t h;int i;
@@ -245,7 +244,6 @@ setup_uga(struct screen_info *si, efi_guid_t *uga_proto, unsigned long size)u32 width, height;void **uga_handle =NULL ;efi_uga_draw_protocol_t *uga =NULL , *first_uga; -unsigned long nr_ugas;efi_handle_t handle;int i;
Signature · 1 line
2.20.1
Ard Biesheuvel
maintainerPATCH 4/13 x86/mm: fix NX bit clearing issue in kernel_map_pages_in_pgd
In reply to Ard BiesheuvelCommit 15f003d20782 ("x86/mm/pat: Don't implicitly allow _PAGE_RW in kernel_map_pages_in_pgd()") modified kernel_map_pages_in_pgd() to manage writable permissions of memory mappings in the EFI page table in a different way, but in the process, it removed the ability to clear NX attributes from read-only mappings, by clobbering the clear mask if _PAGE_RW is not being requested.
Failure to remove the NX attribute from read-only mappings is unlikely to be a security issue, but it does prevent us from tightening the permissions in the EFI page tables going forward, so let's fix it now.
--- arch/x86/mm/pat/set_memory.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)
arch/x86/mm/pat/set_memory.c +1 -7
@@ -2215,7 +2215,7 @@ int __init kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned long address, .pgd = pgd, .numpages = numpages, .mask_set = __pgprot(0), - .mask_clr = __pgprot(0), + .mask_clr = __pgprot(~page_flags & (_PAGE_NX|_PAGE_RW)), .flags = 0, };
@@ -2224,12 +2224,6 @@ int __init kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned long address,if (!(__supported_pte_mask & _PAGE_NX)) goto out; -if (!(page_flags & _PAGE_NX)) - cpa.mask_clr =__pgprot (_PAGE_NX); - -if (!(page_flags & _PAGE_RW)) - cpa.mask_clr =__pgprot (_PAGE_RW); -if (!(page_flags & _PAGE_ENC)) cpa.mask_clr =pgprot_encrypted (cpa.mask_clr);
Signature · 1 line
2.20.1
Ard Biesheuvel
maintainerPATCH 5/13 efi/x86: don't map the entire kernel text RW for mixed mode
In reply to Ard BiesheuvelThe mixed mode thunking routine requires a part of it to be mapped 1:1, and for this reason, we currently map the entire kernel .text read/write in the EFI page tables, which is bad.
In fact, the kernel_map_pages_in_pgd() invocation that installs this mapping is entirely redundant, since all of DRAM is already 1:1 mapped read/write in the EFI page tables when we reach this point, which means that .rodata is mapped read-write as well.
So let's remap both .text and .rodata read-only in the EFI page tables.
--- arch/x86/platform/efi/efi_64.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/platform/efi/efi_64.c +2 -2
@@ -391,11 +391,11 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages) efi_scratch.phys_stack =page_to_phys (page +1 );/* stack grows down */ - npages = (_etext - _text) >>PAGE_SHIFT ; + npages = (__end_rodata_aligned - _text) >>PAGE_SHIFT ; text =__pa (_text); pfn = text >>PAGE_SHIFT ; - pf = _PAGE_RW | _PAGE_ENC; + pf = _PAGE_ENC;if (kernel_map_pages_in_pgd (pgd, pfn, text, npages, pf)) {pr_err ("Failed to map kernel text 1:1\n" );return 1 ;
Signature · 1 line
2.20.1
Re: [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode
Quoted 11 lines · Ard Biesheuvel
The mixed mode thunking routine requires a part of it to be mapped 1:1, and for this reason, we currently map the entire kernel .text read/write in the EFI page tables, which is bad.
In fact, the
kernel_map_pages_in_pgd()invocation that installs this mapping is entirely redundant, since all of DRAM is already 1:1 mapped read/write in the EFI page tables when we reach this point, which means that .rodata is mapped read-write as well.So let's remap both .text and .rodata read-only in the EFI page tables.
This patch causes unhandled page faults in mixed mode:
Quoted 6 lines
BUG: unable to handle page fault for address: 000000001557ee88 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD fd52063 P4D fd52063 PUD fd53063 PMD 154000e1 Oops: 0003 [#1] SMP PTI CPU: 1 PID: 191 Comm: systemd-escape Not tainted
5.6.2-20.gb22bc26-default #1 openSUSE Tumbleweed (unreleased)
Quoted 1 line
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0
02/06/2015
Quoted 2 lines
RIP: 0008:0x3d2eed95 Code: 8b 45 d4 8b 4d 10 8b 40 04 89 01 89 3b 50 6a 00 8b 55 0c 6a 00
8b 45 08 0f b6 4d e4 6a 01 31 f6 e8 ee c5 fc ff 83 c4 10 eb 07 <89> 03 be 05 00 00 80 a1 74 63 31 3d 83 c0 48 e8 44 d2 ff ff eb 05
Quoted 7 lines
RSP: 0018:000000000fd66fa0 EFLAGS: 00010002 RAX: 0000000000000001 RBX: 000000001557ee88 RCX: 000000003d1f1120 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000001 RBP: 000000000fd66fd8 R08: 000000001557ee88 R09: 0000000000000000 R10: 0000000000000055 R11: 0000000000000000 R12: 0000000015bcf000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f36ee9dc940(0000) GS:ffff9b903d700000(0000)
knlGS:0000000000000000
Quoted 7 lines
CS: 0008 DS: 0018 ES: 0018 CR0: 0000000080050033 CR2: 000000001557ee88 CR3: 000000000fd5e000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: Modules linked in: efivarfsCR2:
000000001557ee88
EFI apparently tries to write to now read-only memory.
See:
https://bugzilla.suse.com/show_bug.cgi?id=1168645
Reverting it on the top of 5.6 fixes the issue.
I am using/usr/share/qemu/ovmf-ia32-code.bin/usr/share/qemu/ovmf-ia32-vars.bin
from qemu-ovmf-ia32-202002-1.1.noarch rpm.
Quoted 14 lines
Signed-off-by Ard Biesheuvel <[email protected]>--- arch/x86/platform/efi/efi_64.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)arch/x86/platform/efi/efi_64.c +0
-0@@ -391,11 +391,11 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages) efi_scratch.phys_stack =page_to_phys (page +1 );/* stack grows down */
arch/x86/platform/efi/efi_64.c int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages) · line 401
Quoted 10 lines
arch/x86/platform/efi/efi_64.c +2
-2- npages = (_etext - _text) >>PAGE_SHIFT ; + npages = (__end_rodata_aligned - _text) >>PAGE_SHIFT ; text =__pa (_text); pfn = text >>PAGE_SHIFT ; - pf = _PAGE_RW | _PAGE_ENC; + pf = _PAGE_ENC;if (kernel_map_pages_in_pgd (pgd, pfn, text, npages, pf)) {pr_err ("Failed to map kernel text 1:1\n" );return 1 ;
thanks,
Signature · 2 lines
js suse labs
Ard Biesheuvel
maintainerRe: [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode
Quoted 50 lines · Jiri Slaby
Quoted 11 lines · Ard Biesheuvel
The mixed mode thunking routine requires a part of it to be mapped 1:1, and for this reason, we currently map the entire kernel .text read/write in the EFI page tables, which is bad.
In fact, the
kernel_map_pages_in_pgd()invocation that installs this mapping is entirely redundant, since all of DRAM is already 1:1 mapped read/write in the EFI page tables when we reach this point, which means that .rodata is mapped read-write as well.So let's remap both .text and .rodata read-only in the EFI page tables.
This patch causes unhandled page faults in mixed mode:
Quoted 6 lines
BUG: unable to handle page fault for address: 000000001557ee88 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD fd52063 P4D fd52063 PUD fd53063 PMD 154000e1 Oops: 0003 [#1] SMP PTI CPU: 1 PID: 191 Comm: systemd-escape Not tainted5.6.2-20.gb22bc26-default #1 openSUSE Tumbleweed (unreleased)
Quoted 1 line
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.002/06/2015
Quoted 2 lines
RIP: 0008:0x3d2eed95 Code: 8b 45 d4 8b 4d 10 8b 40 04 89 01 89 3b 50 6a 00 8b 55 0c 6a 008b 45 08 0f b6 4d e4 6a 01 31 f6 e8 ee c5 fc ff 83 c4 10 eb 07 <89> 03 be 05 00 00 80 a1 74 63 31 3d 83 c0 48 e8 44 d2 ff ff eb 05
Quoted 7 lines
RSP: 0018:000000000fd66fa0 EFLAGS: 00010002 RAX: 0000000000000001 RBX: 000000001557ee88 RCX: 000000003d1f1120 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000001 RBP: 000000000fd66fd8 R08: 000000001557ee88 R09: 0000000000000000 R10: 0000000000000055 R11: 0000000000000000 R12: 0000000015bcf000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f36ee9dc940(0000) GS:ffff9b903d700000(0000)knlGS:0000000000000000
Quoted 7 lines
CS: 0008 DS: 0018 ES: 0018 CR0: 0000000080050033 CR2: 000000001557ee88 CR3: 000000000fd5e000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: Modules linked in: efivarfsCR2:
000000001557ee88EFI apparently tries to write to now read-only memory.
Quoted 7 lines
Reverting it on the top of 5.6 fixes the issue.
I am using
/usr/share/qemu/ovmf-ia32-code.bin/usr/share/qemu/ovmf-ia32-vars.bin
from qemu-ovmf-ia32-202002-1.1.noarch rpm.
Do you have a git tree for Suse's OVMF fork? I did a lot of testing with upstream OVMF, and never ran into this issue.
Quoted 29 lines
Quoted 14 lines
Signed-off-by Ard Biesheuvel <[email protected]>--- arch/x86/platform/efi/efi_64.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)arch/x86/platform/efi/efi_64.c +0
-0@@ -391,11 +391,11 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages) efi_scratch.phys_stack =page_to_phys (page +1 );/* stack grows down */ arch/x86/platform/efi/efi_64.c int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages) · line 401
Quoted 10 lines
arch/x86/platform/efi/efi_64.c +2
-2- npages = (_etext - _text) >>PAGE_SHIFT ; + npages = (__end_rodata_aligned - _text) >>PAGE_SHIFT ; text =__pa (_text); pfn = text >>PAGE_SHIFT ; - pf = _PAGE_RW | _PAGE_ENC; + pf = _PAGE_ENC;if (kernel_map_pages_in_pgd (pgd, pfn, text, npages, pf)) {pr_err ("Failed to map kernel text 1:1\n" );return 1 ;thanks,
--
js
suse labs
Re: [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode
Ccing Gary.
Quoted 53 lines · Ard Biesheuvel
Quoted 52 lines · Jiri Slaby
Quoted 11 lines · Ard Biesheuvel
The mixed mode thunking routine requires a part of it to be mapped 1:1, and for this reason, we currently map the entire kernel .text read/write in the EFI page tables, which is bad.
In fact, the
kernel_map_pages_in_pgd()invocation that installs this mapping is entirely redundant, since all of DRAM is already 1:1 mapped read/write in the EFI page tables when we reach this point, which means that .rodata is mapped read-write as well.So let's remap both .text and .rodata read-only in the EFI page tables.
This patch causes unhandled page faults in mixed mode:
Quoted 6 lines
BUG: unable to handle page fault for address: 000000001557ee88 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD fd52063 P4D fd52063 PUD fd53063 PMD 154000e1 Oops: 0003 [#1] SMP PTI CPU: 1 PID: 191 Comm: systemd-escape Not tainted5.6.2-20.gb22bc26-default #1 openSUSE Tumbleweed (unreleased)
Quoted 1 line
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.002/06/2015
Quoted 2 lines
RIP: 0008:0x3d2eed95 Code: 8b 45 d4 8b 4d 10 8b 40 04 89 01 89 3b 50 6a 00 8b 55 0c 6a 008b 45 08 0f b6 4d e4 6a 01 31 f6 e8 ee c5 fc ff 83 c4 10 eb 07 <89> 03 be 05 00 00 80 a1 74 63 31 3d 83 c0 48 e8 44 d2 ff ff eb 05
Quoted 7 lines
RSP: 0018:000000000fd66fa0 EFLAGS: 00010002 RAX: 0000000000000001 RBX: 000000001557ee88 RCX: 000000003d1f1120 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000001 RBP: 000000000fd66fd8 R08: 000000001557ee88 R09: 0000000000000000 R10: 0000000000000055 R11: 0000000000000000 R12: 0000000015bcf000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f36ee9dc940(0000) GS:ffff9b903d700000(0000)knlGS:0000000000000000
Quoted 7 lines
CS: 0008 DS: 0018 ES: 0018 CR0: 0000000080050033 CR2: 000000001557ee88 CR3: 000000000fd5e000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: Modules linked in: efivarfsCR2:
000000001557ee88EFI apparently tries to write to now read-only memory.
See:
https://bugzilla.suse.com/show_bug.cgi?id=1168645Reverting it on the top of 5.6 fixes the issue.
Quoted 8 lines
Quoted 5 lines
I am using
/usr/share/qemu/ovmf-ia32-code.bin/usr/share/qemu/ovmf-ia32-vars.bin
from qemu-ovmf-ia32-202002-1.1.noarch rpm.Do you have a git tree for Suse's OVMF fork? I did a lot of testing with upstream OVMF, and never ran into this issue.
Not really a git tree, but the sources are here:
https://build.opensuse.org/package/show/openSUSE:Factory/ovmf
Signature · 2 lines
js suse labs
Ard Biesheuvel
maintainerRe: [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode
Quoted 63 lines · Jiri Slaby
Ccing Gary.
Quoted 59 lines · Ard Biesheuvel
Quoted 57 lines · Jiri Slaby
Quoted 11 lines · Ard Biesheuvel
The mixed mode thunking routine requires a part of it to be mapped 1:1, and for this reason, we currently map the entire kernel .text read/write in the EFI page tables, which is bad.
In fact, the
kernel_map_pages_in_pgd()invocation that installs this mapping is entirely redundant, since all of DRAM is already 1:1 mapped read/write in the EFI page tables when we reach this point, which means that .rodata is mapped read-write as well.So let's remap both .text and .rodata read-only in the EFI page tables.
This patch causes unhandled page faults in mixed mode:
Quoted 6 lines
BUG: unable to handle page fault for address: 000000001557ee88 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD fd52063 P4D fd52063 PUD fd53063 PMD 154000e1 Oops: 0003 [#1] SMP PTI CPU: 1 PID: 191 Comm: systemd-escape Not tainted5.6.2-20.gb22bc26-default #1 openSUSE Tumbleweed (unreleased)
Quoted 1 line
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.002/06/2015
Quoted 2 lines
RIP: 0008:0x3d2eed95 Code: 8b 45 d4 8b 4d 10 8b 40 04 89 01 89 3b 50 6a 00 8b 55 0c 6a 008b 45 08 0f b6 4d e4 6a 01 31 f6 e8 ee c5 fc ff 83 c4 10 eb 07 <89> 03 be 05 00 00 80 a1 74 63 31 3d 83 c0 48 e8 44 d2 ff ff eb 05
Quoted 7 lines
RSP: 0018:000000000fd66fa0 EFLAGS: 00010002 RAX: 0000000000000001 RBX: 000000001557ee88 RCX: 000000003d1f1120 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000001 RBP: 000000000fd66fd8 R08: 000000001557ee88 R09: 0000000000000000 R10: 0000000000000055 R11: 0000000000000000 R12: 0000000015bcf000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f36ee9dc940(0000) GS:ffff9b903d700000(0000)knlGS:0000000000000000
Quoted 7 lines
CS: 0008 DS: 0018 ES: 0018 CR0: 0000000080050033 CR2: 000000001557ee88 CR3: 000000000fd5e000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: Modules linked in: efivarfsCR2:
000000001557ee88EFI apparently tries to write to now read-only memory.
See:
https://bugzilla.suse.com/show_bug.cgi?id=1168645Reverting it on the top of 5.6 fixes the issue.
I am using
/usr/share/qemu/ovmf-ia32-code.bin/usr/share/qemu/ovmf-ia32-vars.bin
from qemu-ovmf-ia32-202002-1.1.noarch rpm.
Quoted 6 lines
Quoted 2 lines
Do you have a git tree for Suse's OVMF fork? I did a lot of testing with upstream OVMF, and never ran into this issue.
Not really a git tree, but the sources are here:
https://build.opensuse.org/package/show/openSUSE:Factory/ovmf
Anywhere I can get an actual build? The src rpm only has the sources, and the i586 rpm has nothing except
$ rpm -qlp ~/Downloads/ovmf-202002-1.1.i586.rpm warning: /home/ardbie01/Downloads/ovmf-202002-1.1.i586.rpm: Header V3 RSA/SHA256 Signature, key ID 3dbdc284: NOKEY /usr/share/doc/packages/ovmf /usr/share/doc/packages/ovmf/README
Re: [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode
Quoted 72 lines · Ard Biesheuvel
Quoted 63 lines · Jiri Slaby
Ccing Gary.
Quoted 59 lines · Ard Biesheuvel
Quoted 57 lines · Jiri Slaby
Quoted 11 lines · Ard Biesheuvel
The mixed mode thunking routine requires a part of it to be mapped 1:1, and for this reason, we currently map the entire kernel .text read/write in the EFI page tables, which is bad.
In fact, the
kernel_map_pages_in_pgd()invocation that installs this mapping is entirely redundant, since all of DRAM is already 1:1 mapped read/write in the EFI page tables when we reach this point, which means that .rodata is mapped read-write as well.So let's remap both .text and .rodata read-only in the EFI page tables.
This patch causes unhandled page faults in mixed mode:
Quoted 6 lines
BUG: unable to handle page fault for address: 000000001557ee88 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD fd52063 P4D fd52063 PUD fd53063 PMD 154000e1 Oops: 0003 [#1] SMP PTI CPU: 1 PID: 191 Comm: systemd-escape Not tainted5.6.2-20.gb22bc26-default #1 openSUSE Tumbleweed (unreleased)
Quoted 1 line
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.002/06/2015
Quoted 2 lines
RIP: 0008:0x3d2eed95 Code: 8b 45 d4 8b 4d 10 8b 40 04 89 01 89 3b 50 6a 00 8b 55 0c 6a 008b 45 08 0f b6 4d e4 6a 01 31 f6 e8 ee c5 fc ff 83 c4 10 eb 07 <89> 03 be 05 00 00 80 a1 74 63 31 3d 83 c0 48 e8 44 d2 ff ff eb 05
Quoted 7 lines
RSP: 0018:000000000fd66fa0 EFLAGS: 00010002 RAX: 0000000000000001 RBX: 000000001557ee88 RCX: 000000003d1f1120 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000001 RBP: 000000000fd66fd8 R08: 000000001557ee88 R09: 0000000000000000 R10: 0000000000000055 R11: 0000000000000000 R12: 0000000015bcf000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f36ee9dc940(0000) GS:ffff9b903d700000(0000)knlGS:0000000000000000
Quoted 7 lines
CS: 0008 DS: 0018 ES: 0018 CR0: 0000000080050033 CR2: 000000001557ee88 CR3: 000000000fd5e000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: Modules linked in: efivarfsCR2:
000000001557ee88EFI apparently tries to write to now read-only memory.
See:
https://bugzilla.suse.com/show_bug.cgi?id=1168645Reverting it on the top of 5.6 fixes the issue.
I am using
/usr/share/qemu/ovmf-ia32-code.bin/usr/share/qemu/ovmf-ia32-vars.bin
from qemu-ovmf-ia32-202002-1.1.noarch rpm.Quoted 6 lines
Quoted 2 lines
Do you have a git tree for Suse's OVMF fork? I did a lot of testing with upstream OVMF, and never ran into this issue.
Not really a git tree, but the sources are here:
https://build.opensuse.org/package/show/openSUSE:Factory/ovmf
Quoted 8 lines
Anywhere I can get an actual build? The src rpm only has the sources, and the i586 rpm has nothing except
$ rpm -qlp ~/Downloads/ovmf-202002-1.1.i586.rpm warning: /home/ardbie01/Downloads/ovmf-202002-1.1.i586.rpm: Header V3 RSA/SHA256 Signature, key ID 3dbdc284: NOKEY /usr/share/doc/packages/ovmf /usr/share/doc/packages/ovmf/README
Hmmm, it's weird that OBS doesn't list all derived files. Anyway, the ia32 ovmf is available in
http://download.opensuse.org/tumbleweed/repo/oss/noarch/qemu-ovmf-ia32-202002-1.1.noarch.rpm
Gary Lin
Re: [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode
Quoted 82 lines · Gary Lin
Quoted 72 lines · Ard Biesheuvel
Quoted 63 lines · Jiri Slaby
Ccing Gary.
Quoted 59 lines · Ard Biesheuvel
Quoted 57 lines · Jiri Slaby
Quoted 11 lines · Ard Biesheuvel
The mixed mode thunking routine requires a part of it to be mapped 1:1, and for this reason, we currently map the entire kernel .text read/write in the EFI page tables, which is bad.
In fact, the
kernel_map_pages_in_pgd()invocation that installs this mapping is entirely redundant, since all of DRAM is already 1:1 mapped read/write in the EFI page tables when we reach this point, which means that .rodata is mapped read-write as well.So let's remap both .text and .rodata read-only in the EFI page tables.
This patch causes unhandled page faults in mixed mode:
Quoted 6 lines
BUG: unable to handle page fault for address: 000000001557ee88 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD fd52063 P4D fd52063 PUD fd53063 PMD 154000e1 Oops: 0003 [#1] SMP PTI CPU: 1 PID: 191 Comm: systemd-escape Not tainted5.6.2-20.gb22bc26-default #1 openSUSE Tumbleweed (unreleased)
Quoted 1 line
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.002/06/2015
Quoted 2 lines
RIP: 0008:0x3d2eed95 Code: 8b 45 d4 8b 4d 10 8b 40 04 89 01 89 3b 50 6a 00 8b 55 0c 6a 008b 45 08 0f b6 4d e4 6a 01 31 f6 e8 ee c5 fc ff 83 c4 10 eb 07 <89> 03 be 05 00 00 80 a1 74 63 31 3d 83 c0 48 e8 44 d2 ff ff eb 05
Quoted 7 lines
RSP: 0018:000000000fd66fa0 EFLAGS: 00010002 RAX: 0000000000000001 RBX: 000000001557ee88 RCX: 000000003d1f1120 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000001 RBP: 000000000fd66fd8 R08: 000000001557ee88 R09: 0000000000000000 R10: 0000000000000055 R11: 0000000000000000 R12: 0000000015bcf000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f36ee9dc940(0000) GS:ffff9b903d700000(0000)knlGS:0000000000000000
Quoted 7 lines
CS: 0008 DS: 0018 ES: 0018 CR0: 0000000080050033 CR2: 000000001557ee88 CR3: 000000000fd5e000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: Modules linked in: efivarfsCR2:
000000001557ee88EFI apparently tries to write to now read-only memory.
See:
https://bugzilla.suse.com/show_bug.cgi?id=1168645Reverting it on the top of 5.6 fixes the issue.
I am using
/usr/share/qemu/ovmf-ia32-code.bin/usr/share/qemu/ovmf-ia32-vars.bin
from qemu-ovmf-ia32-202002-1.1.noarch rpm.Quoted 6 lines
Quoted 2 lines
Do you have a git tree for Suse's OVMF fork? I did a lot of testing with upstream OVMF, and never ran into this issue.
Not really a git tree, but the sources are here:
https://build.opensuse.org/package/show/openSUSE:Factory/ovmfQuoted 8 lines
Anywhere I can get an actual build? The src rpm only has the sources, and the i586 rpm has nothing except
$ rpm -qlp ~/Downloads/ovmf-202002-1.1.i586.rpm warning: /home/ardbie01/Downloads/ovmf-202002-1.1.i586.rpm: Header V3 RSA/SHA256 Signature, key ID 3dbdc284: NOKEY /usr/share/doc/packages/ovmf /usr/share/doc/packages/ovmf/README
Quoted 3 lines
Hmmm, it's weird that OBS doesn't list all derived files. Anyway, the ia32 ovmf is available in
http://download.opensuse.org/tumbleweed/repo/oss/noarch/qemu-ovmf-ia32-202002-1.1.noarch.rpm
It indeed does:
https://build.opensuse.org/package/binaries/openSUSE:Factory/ovmf/standard
Note that the ia32 version is noarch, built on i586.
thanks,
Signature · 2 lines
js suse labs
Ard Biesheuvel
maintainerRe: [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode
Quoted 84 lines · Jiri Slaby
Quoted 82 lines · Gary Lin
Quoted 80 lines · Ard Biesheuvel
Quoted 63 lines · Jiri Slaby
Ccing Gary.
Quoted 59 lines · Ard Biesheuvel
Quoted 57 lines · Jiri Slaby
Quoted 11 lines · Ard Biesheuvel
The mixed mode thunking routine requires a part of it to be mapped 1:1, and for this reason, we currently map the entire kernel .text read/write in the EFI page tables, which is bad.
In fact, the
kernel_map_pages_in_pgd()invocation that installs this mapping is entirely redundant, since all of DRAM is already 1:1 mapped read/write in the EFI page tables when we reach this point, which means that .rodata is mapped read-write as well.So let's remap both .text and .rodata read-only in the EFI page tables.
This patch causes unhandled page faults in mixed mode:
Quoted 6 lines
BUG: unable to handle page fault for address: 000000001557ee88 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD fd52063 P4D fd52063 PUD fd53063 PMD 154000e1 Oops: 0003 [#1] SMP PTI CPU: 1 PID: 191 Comm: systemd-escape Not tainted5.6.2-20.gb22bc26-default #1 openSUSE Tumbleweed (unreleased)
Quoted 1 line
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.002/06/2015
Quoted 2 lines
RIP: 0008:0x3d2eed95 Code: 8b 45 d4 8b 4d 10 8b 40 04 89 01 89 3b 50 6a 00 8b 55 0c 6a 008b 45 08 0f b6 4d e4 6a 01 31 f6 e8 ee c5 fc ff 83 c4 10 eb 07 <89> 03 be 05 00 00 80 a1 74 63 31 3d 83 c0 48 e8 44 d2 ff ff eb 05
Quoted 7 lines
RSP: 0018:000000000fd66fa0 EFLAGS: 00010002 RAX: 0000000000000001 RBX: 000000001557ee88 RCX: 000000003d1f1120 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000001 RBP: 000000000fd66fd8 R08: 000000001557ee88 R09: 0000000000000000 R10: 0000000000000055 R11: 0000000000000000 R12: 0000000015bcf000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f36ee9dc940(0000) GS:ffff9b903d700000(0000)knlGS:0000000000000000
Quoted 7 lines
CS: 0008 DS: 0018 ES: 0018 CR0: 0000000080050033 CR2: 000000001557ee88 CR3: 000000000fd5e000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: Modules linked in: efivarfsCR2:
000000001557ee88EFI apparently tries to write to now read-only memory.
See:
https://bugzilla.suse.com/show_bug.cgi?id=1168645Reverting it on the top of 5.6 fixes the issue.
I am using
/usr/share/qemu/ovmf-ia32-code.bin/usr/share/qemu/ovmf-ia32-vars.bin
from qemu-ovmf-ia32-202002-1.1.noarch rpm.Quoted 6 lines
Quoted 2 lines
Do you have a git tree for Suse's OVMF fork? I did a lot of testing with upstream OVMF, and never ran into this issue.
Not really a git tree, but the sources are here:
https://build.opensuse.org/package/show/openSUSE:Factory/ovmfAnywhere I can get an actual build? The src rpm only has the sources, and the i586 rpm has nothing except
$ rpm -qlp ~/Downloads/ovmf-202002-1.1.i586.rpm warning: /home/ardbie01/Downloads/ovmf-202002-1.1.i586.rpm: Header V3 RSA/SHA256 Signature, key ID 3dbdc284: NOKEY /usr/share/doc/packages/ovmf /usr/share/doc/packages/ovmf/README
Quoted 9 lines
Quoted 3 lines
Hmmm, it's weird that OBS doesn't list all derived files. Anyway, the ia32 ovmf is available in
http://download.opensuse.org/tumbleweed/repo/oss/noarch/qemu-ovmf-ia32-202002-1.1.noarch.rpmIt indeed does:
https://build.opensuse.org/package/binaries/openSUSE:Factory/ovmf/standardNote that the ia32 version is noarch, built on i586.
I am not able to reproduce this issue using the linked firmware image and a 5.6 x86_64_defconfig with efivarfs built in.
Could anyone share the full log, please, along with the kernel config that was used? Also, it would be good to know if it is reproducible using a kernel built from upstream.
Re: [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode
Quoted 10 lines · Ard Biesheuvel
Quoted 10 lines
Quoted 9 lines
Quoted 5 lines
$ rpm -qlp ~/Downloads/ovmf-202002-1.1.i586.rpm warning: /home/ardbie01/Downloads/ovmf-202002-1.1.i586.rpm: Header V3 RSA/SHA256 Signature, key ID 3dbdc284: NOKEY /usr/share/doc/packages/ovmf /usr/share/doc/packages/ovmf/READMEHmmm, it's weird that OBS doesn't list all derived files. Anyway, the ia32 ovmf is available in
http://download.opensuse.org/tumbleweed/repo/oss/noarch/qemu-ovmf-ia32-202002-1.1.noarch.rpm
Quoted 8 lines
Quoted 5 lines
It indeed does:
https://build.opensuse.org/package/binaries/openSUSE:Factory/ovmf/standardNote that the ia32 version is noarch, built on i586.
I am not able to reproduce this issue using the linked firmware image and a 5.6
x86_64_defconfigwith efivarfs built in.
Yeah, I had to use the distro config too. Not sure what the trigger is. Maybe some NUMA configs or something.
Quoted 2 lines
Could anyone share the full log, please, along with the kernel config that was used?
Both uploaded:
http://decibel.fi.muni.cz/~xslaby/err/
Note that I switched the for-me-necessary =m configs to =y. So that it is enough to build bzImage, w/o modules...
Quoted 2 lines
Also, it would be good to know if it is reproducible using a kernel built from upstream.
Sure, I was bisecting the upstream kernel:
git bisect start
# bad: [7111951b8d4973bda27ff663f2cf18b663d15b48] Linux 5.6 git bisect bad 7111951b8d4973bda27ff663f2cf18b663d15b48
# good: [d5226fa6dbae0569ee43ecfc08bdcd6770fc4755] Linux 5.5 git bisect good d5226fa6dbae0569ee43ecfc08bdcd6770fc4755
# skip: [9f68e3655aae6d49d6ba05dd263f99f33c2567af] Merge tag 'drm-next-2020-01-30' of git://anongit.freedesktop.org/drm/drm
git bisect skip 9f68e3655aae6d49d6ba05dd263f99f33c2567af
# good: [b4a4bd0f2629ec2ece7690de1b4721529da29871] irqchip/gic-v4.1: Add VPE INVALL callback
git bisect good b4a4bd0f2629ec2ece7690de1b4721529da29871
# good: [c130d2dc93cd03323494d82dbe7b5fb0d101ab62] rcu: Rename some instance of CONFIG_PREEMPTION to CONFIG_PREEMPT_RCU
git bisect good c130d2dc93cd03323494d82dbe7b5fb0d101ab62
# good: [0aee99a1ea53de1aedcf96a4d52d6161ffba011a] iio: gyro: adis16136:
rework locks using ADIS library's state lock
git bisect good 0aee99a1ea53de1aedcf96a4d52d6161ffba011a
# bad: [83576e32a71717d1912b7dcb247a0f15613272da] Merge branch 'macb-TSO-bug-fixes'
git bisect bad 83576e32a71717d1912b7dcb247a0f15613272da
# bad: [7ba31c3f2f1ee095d8126f4d3757fc3b2bc3c838] Merge tag 'staging-5.6-rc1' ofgit://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
git bisect bad 7ba31c3f2f1ee095d8126f4d3757fc3b2bc3c838
# good: [f76e4c167ea2212e23c15ee7e601a865e822c291] net: phy: add default ARCH_BCM_IPROC for MDIO_BCM_IPROC
git bisect good f76e4c167ea2212e23c15ee7e601a865e822c291
# bad: [bd2463ac7d7ec51d432f23bf0e893fb371a908cd] Mergegit://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
git bisect bad bd2463ac7d7ec51d432f23bf0e893fb371a908cd
# good: [e279160f491392f1345f6eb4b0eeec5a6a2ecdd7] Merge tag 'timers-core-2020-01-27' ofgit://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good e279160f491392f1345f6eb4b0eeec5a6a2ecdd7
# bad: [511fdb78442229ac11057b4a55c3f03c253c062f] Merge branch 'x86-mtrr-for-linus' ofgit://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 511fdb78442229ac11057b4a55c3f03c253c062f
# bad: [2180f214f4a5d8e2d8b7138d9a59246ee05753b9] Merge branch 'locking-core-for-linus' ofgit://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 2180f214f4a5d8e2d8b7138d9a59246ee05753b9
# good: [d99391ec2b42d827d92003dcdcb96fadac9d862b] Merge branch 'core-rcu-for-linus' ofgit://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good d99391ec2b42d827d92003dcdcb96fadac9d862b
# good: [57ad87ddce79b6d54f8e442d0ecf4b5bbe8c5a9e] Merge branch 'x86/mm' into efi/core, to pick up dependencies
git bisect good 57ad87ddce79b6d54f8e442d0ecf4b5bbe8c5a9e
# good: [ac3c76cc6d6deef573dd8c14232f20c6aa744f83] efi/libstub/x86: Use mandatory 16-byte stack alignment in mixed mode
git bisect good ac3c76cc6d6deef573dd8c14232f20c6aa744f83
# bad: [484a418d075488c6999528247cc711d12c373447] efi: Fix handling of multiple efi_fake_mem= entries
git bisect bad 484a418d075488c6999528247cc711d12c373447
# bad: [1f299fad1e312947c974c6a1d8a3a484f27a6111] efi/x86: Limit EFI old memory map to SGI UV machines
git bisect bad 1f299fad1e312947c974c6a1d8a3a484f27a6111
# good: [75fbef0a8b6b4bb19b9a91b5214f846c2dc5139e] x86/mm: Fix NX bit clearing issue in kernel_map_pages_in_pgd
git bisect good 75fbef0a8b6b4bb19b9a91b5214f846c2dc5139e
# bad: [97bb9cdc32108036170d9d0d208257168f80d9e9] efi/x86: Avoid RWX mappings for all of DRAM
git bisect bad 97bb9cdc32108036170d9d0d208257168f80d9e9
# bad: [d9e3d2c4f103200d87f2c243a84c1fd3b3bfea8c] efi/x86: Don't map the entire kernel text RW for mixed mode
git bisect bad d9e3d2c4f103200d87f2c243a84c1fd3b3bfea8c
# first bad commit: [d9e3d2c4f103200d87f2c243a84c1fd3b3bfea8c] efi/x86: Don't map the entire kernel text RW for mixed mode
thanks,
Signature · 2 lines
js suse labs
Ard Biesheuvel
maintainerRe: [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode
Quoted 21 lines · Jiri Slaby
Quoted 10 lines · Ard Biesheuvel
Quoted 10 lines
Quoted 9 lines
Quoted 5 lines
$ rpm -qlp ~/Downloads/ovmf-202002-1.1.i586.rpm warning: /home/ardbie01/Downloads/ovmf-202002-1.1.i586.rpm: Header V3 RSA/SHA256 Signature, key ID 3dbdc284: NOKEY /usr/share/doc/packages/ovmf /usr/share/doc/packages/ovmf/READMEHmmm, it's weird that OBS doesn't list all derived files. Anyway, the ia32 ovmf is available in
http://download.opensuse.org/tumbleweed/repo/oss/noarch/qemu-ovmf-ia32-202002-1.1.noarch.rpmQuoted 8 lines
Quoted 5 lines
It indeed does:
https://build.opensuse.org/package/binaries/openSUSE:Factory/ovmf/standardNote that the ia32 version is noarch, built on i586.
I am not able to reproduce this issue using the linked firmware image and a 5.6
x86_64_defconfigwith efivarfs built in.
Quoted 9 lines
Yeah, I had to use the distro config too. Not sure what the trigger is. Maybe some NUMA configs or something.
Quoted 2 lines
Could anyone share the full log, please, along with the kernel config that was used?
Both uploaded:
http://decibel.fi.muni.cz/~xslaby/err/
With the same config, I am still not seeing the issue.
Quoted 3 lines
Note that I switched the for-me-necessary =m configs to =y. So that it is enough to build bzImage, w/o modules...
Could you please try running it again with CONFIG_EFI_PGT_DUMP=y enabled?
In the mean time, I will try to install Tumbleweed from scratch. Do you have any steps I could follow to reproduce your setup?
Quoted 78 lines
Quoted 2 lines
Also, it would be good to know if it is reproducible using a kernel built from upstream.
Sure, I was bisecting the upstream kernel:
git bisect start
# bad: [7111951b8d4973bda27ff663f2cf18b663d15b48] Linux 5.6 git bisect bad7111951b8d4973bda27ff663f2cf18b663d15b48
# good: [d5226fa6dbae0569ee43ecfc08bdcd6770fc4755] Linux 5.5 git bisect goodd5226fa6dbae0569ee43ecfc08bdcd6770fc4755
# skip: [9f68e3655aae6d49d6ba05dd263f99f33c2567af] Merge tag 'drm-next-2020-01-30' ofgit://anongit.freedesktop.org/drm/drm
git bisect skip9f68e3655aae6d49d6ba05dd263f99f33c2567af
# good: [b4a4bd0f2629ec2ece7690de1b4721529da29871] irqchip/gic-v4.1: Add VPE INVALL callback
git bisect goodb4a4bd0f2629ec2ece7690de1b4721529da29871
# good: [c130d2dc93cd03323494d82dbe7b5fb0d101ab62] rcu: Rename some instance ofCONFIG_PREEMPTIONtoCONFIG_PREEMPT_RCU
git bisect goodc130d2dc93cd03323494d82dbe7b5fb0d101ab62
# good: [0aee99a1ea53de1aedcf96a4d52d6161ffba011a] iio: gyro: adis16136:
rework locks using ADIS library's state lock
git bisect good0aee99a1ea53de1aedcf96a4d52d6161ffba011a
# bad: [83576e32a71717d1912b7dcb247a0f15613272da] Merge branch 'macb-TSO-bug-fixes'
git bisect bad83576e32a71717d1912b7dcb247a0f15613272da
# bad: [7ba31c3f2f1ee095d8126f4d3757fc3b2bc3c838] Merge tag 'staging-5.6-rc1' ofgit://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
git bisect bad7ba31c3f2f1ee095d8126f4d3757fc3b2bc3c838
# good: [f76e4c167ea2212e23c15ee7e601a865e822c291] net: phy: add defaultARCH_BCM_IPROCforMDIO_BCM_IPROC
git bisect goodf76e4c167ea2212e23c15ee7e601a865e822c291
# bad: [bd2463ac7d7ec51d432f23bf0e893fb371a908cd] Mergegit://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
git bisect badbd2463ac7d7ec51d432f23bf0e893fb371a908cd
# good: [e279160f491392f1345f6eb4b0eeec5a6a2ecdd7] Merge tag 'timers-core-2020-01-27' ofgit://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect goode279160f491392f1345f6eb4b0eeec5a6a2ecdd7
# bad: [511fdb78442229ac11057b4a55c3f03c253c062f] Merge branch 'x86-mtrr-for-linus' ofgit://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad511fdb78442229ac11057b4a55c3f03c253c062f
# bad: [2180f214f4a5d8e2d8b7138d9a59246ee05753b9] Merge branch 'locking-core-for-linus' ofgit://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad2180f214f4a5d8e2d8b7138d9a59246ee05753b9
# good: [d99391ec2b42d827d92003dcdcb96fadac9d862b] Merge branch 'core-rcu-for-linus' ofgit://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect goodd99391ec2b42d827d92003dcdcb96fadac9d862b
# good: [57ad87ddce79b6d54f8e442d0ecf4b5bbe8c5a9e] Merge branch 'x86/mm' into efi/core, to pick up dependencies
git bisect good57ad87ddce79b6d54f8e442d0ecf4b5bbe8c5a9e
# good: [ac3c76cc6d6deef573dd8c14232f20c6aa744f83] efi/libstub/x86: Use mandatory 16-byte stack alignment in mixed mode
git bisect goodac3c76cc6d6deef573dd8c14232f20c6aa744f83
# bad: [484a418d075488c6999528247cc711d12c373447] efi: Fix handling of multiple efi_fake_mem= entries
git bisect bad484a418d075488c6999528247cc711d12c373447
# bad: [1f299fad1e312947c974c6a1d8a3a484f27a6111] efi/x86: Limit EFI old memory map to SGI UV machines
git bisect bad1f299fad1e312947c974c6a1d8a3a484f27a6111
# good: [75fbef0a8b6b4bb19b9a91b5214f846c2dc5139e] x86/mm: Fix NX bit clearing issue inkernel_map_pages_in_pgd
git bisect good75fbef0a8b6b4bb19b9a91b5214f846c2dc5139e
# bad: [97bb9cdc32108036170d9d0d208257168f80d9e9] efi/x86: Avoid RWX mappings for all of DRAM
git bisect bad97bb9cdc32108036170d9d0d208257168f80d9e9
# bad: [d9e3d2c4f103200d87f2c243a84c1fd3b3bfea8c] efi/x86: Don't map the entire kernel text RW for mixed mode
git bisect badd9e3d2c4f103200d87f2c243a84c1fd3b3bfea8c# first bad commit: [d9e3d2c4f103200d87f2c243a84c1fd3b3bfea8c] efi/x86: Don't map the entire kernel text RW for mixed modethanks,
--
js
suse labs
Ard Biesheuvel
maintainerRe: [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode
Quoted 36 lines · Ard Biesheuvel
Quoted 21 lines · Jiri Slaby
Quoted 10 lines · Ard Biesheuvel
Quoted 10 lines
Quoted 9 lines
Quoted 5 lines
$ rpm -qlp ~/Downloads/ovmf-202002-1.1.i586.rpm warning: /home/ardbie01/Downloads/ovmf-202002-1.1.i586.rpm: Header V3 RSA/SHA256 Signature, key ID 3dbdc284: NOKEY /usr/share/doc/packages/ovmf /usr/share/doc/packages/ovmf/READMEHmmm, it's weird that OBS doesn't list all derived files. Anyway, the ia32 ovmf is available in
http://download.opensuse.org/tumbleweed/repo/oss/noarch/qemu-ovmf-ia32-202002-1.1.noarch.rpmQuoted 8 lines
Quoted 5 lines
It indeed does:
https://build.opensuse.org/package/binaries/openSUSE:Factory/ovmf/standardNote that the ia32 version is noarch, built on i586.
I am not able to reproduce this issue using the linked firmware image and a 5.6
x86_64_defconfigwith efivarfs built in.Quoted 9 lines
Yeah, I had to use the distro config too. Not sure what the trigger is. Maybe some NUMA configs or something.
Quoted 2 lines
Could anyone share the full log, please, along with the kernel config that was used?
Both uploaded:
http://decibel.fi.muni.cz/~xslaby/err/With the same config, I am still not seeing the issue.
Quoted 9 lines
Quoted 3 lines
Note that I switched the for-me-necessary =m configs to =y. So that it is enough to build bzImage, w/o modules...
Could you please try running it again with
CONFIG_EFI_PGT_DUMP=yenabled?In the mean time, I will try to install Tumbleweed from scratch. Do you have any steps I could follow to reproduce your setup?
The faulting code decodes to
2a:* 89 03 mov %eax,(%ebx) <-- trapping instruction 2c: be 05 00 00 80 mov $0x80000005,%esi 31: a1 74 63 31 3d mov 0x3d316374,%eax 36: 83 c0 48 add $0x48,%eax 39: e8 44 d2 ff ff call 0xffffd282 3e: eb 05 jmp 0x45
which looks suspiciously like
MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c-2390- } else { MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c-2391- *DataSize = VarDataSize;MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c:2392: Status
= EFI_BUFFER_TOO_SMALL;
MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c-2393- goto Done;
MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c-2394- }
in EDK2, so it seems like the GetVariable() is being called with a datasize pointer that resides in r/o memory
It would be very helpful if we could get the memory dump that CONFIG_EFI_PGT_DUMP=y provides, as well as some idea of the call stack that performs get GetVariable() call at this point. The mixed mode code just passes the address it gets, but it does translate it to a physical address, which means it accesses the memory via a different mapping.
Re: [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode
In reply to Ard BiesheuvelQuoted 32 lines · Ard Biesheuvel
Quoted 21 lines · Jiri Slaby
Quoted 10 lines · Ard Biesheuvel
Quoted 10 lines
Quoted 9 lines
Quoted 5 lines
$ rpm -qlp ~/Downloads/ovmf-202002-1.1.i586.rpm warning: /home/ardbie01/Downloads/ovmf-202002-1.1.i586.rpm: Header V3 RSA/SHA256 Signature, key ID 3dbdc284: NOKEY /usr/share/doc/packages/ovmf /usr/share/doc/packages/ovmf/READMEHmmm, it's weird that OBS doesn't list all derived files. Anyway, the ia32 ovmf is available in
http://download.opensuse.org/tumbleweed/repo/oss/noarch/qemu-ovmf-ia32-202002-1.1.noarch.rpmQuoted 8 lines
Quoted 5 lines
It indeed does:
https://build.opensuse.org/package/binaries/openSUSE:Factory/ovmf/standardNote that the ia32 version is noarch, built on i586.
I am not able to reproduce this issue using the linked firmware image and a 5.6
x86_64_defconfigwith efivarfs built in.Quoted 9 lines
Yeah, I had to use the distro config too. Not sure what the trigger is. Maybe some NUMA configs or something.
Quoted 2 lines
Could anyone share the full log, please, along with the kernel config that was used?
Both uploaded:
http://decibel.fi.muni.cz/~xslaby/err/
Quoted 8 lines
With the same config, I am still not seeing the issue.
Quoted 3 lines
Note that I switched the for-me-necessary =m configs to =y. So that it is enough to build bzImage, w/o modules...
Could you please try running it again with
CONFIG_EFI_PGT_DUMP=yenabled?
No problem:
http://decibel.fi.muni.cz/~xslaby/err/dmesg2.txt
Quoted 2 lines
In the mean time, I will try to install Tumbleweed from scratch. Do you have any steps I could follow to reproduce your setup?
Not really, just installed TW 64-bit and used efi and grub 32 bit.
Signature · 2 lines
js suse labs
Ard Biesheuvel
maintainerRe: [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode
Quoted 43 lines · Jiri Slaby
Quoted 32 lines · Ard Biesheuvel
Quoted 21 lines · Jiri Slaby
Quoted 10 lines · Ard Biesheuvel
Quoted 10 lines
Quoted 9 lines
Quoted 5 lines
$ rpm -qlp ~/Downloads/ovmf-202002-1.1.i586.rpm warning: /home/ardbie01/Downloads/ovmf-202002-1.1.i586.rpm: Header V3 RSA/SHA256 Signature, key ID 3dbdc284: NOKEY /usr/share/doc/packages/ovmf /usr/share/doc/packages/ovmf/READMEHmmm, it's weird that OBS doesn't list all derived files. Anyway, the ia32 ovmf is available in
http://download.opensuse.org/tumbleweed/repo/oss/noarch/qemu-ovmf-ia32-202002-1.1.noarch.rpmQuoted 8 lines
Quoted 5 lines
It indeed does:
https://build.opensuse.org/package/binaries/openSUSE:Factory/ovmf/standardNote that the ia32 version is noarch, built on i586.
I am not able to reproduce this issue using the linked firmware image and a 5.6
x86_64_defconfigwith efivarfs built in.Quoted 9 lines
Yeah, I had to use the distro config too. Not sure what the trigger is. Maybe some NUMA configs or something.
Quoted 2 lines
Could anyone share the full log, please, along with the kernel config that was used?
Both uploaded:
http://decibel.fi.muni.cz/~xslaby/err/Quoted 8 lines
With the same config, I am still not seeing the issue.
Quoted 3 lines
Note that I switched the for-me-necessary =m configs to =y. So that it is enough to build bzImage, w/o modules...
Could you please try running it again with
CONFIG_EFI_PGT_DUMP=yenabled?
Quoted 8 lines
No problem:
http://decibel.fi.muni.cz/~xslaby/err/dmesg2.txtQuoted 2 lines
In the mean time, I will try to install Tumbleweed from scratch. Do you have any steps I could follow to reproduce your setup?
Not really, just installed TW 64-bit and used efi and grub 32 bit.
OK, so you installed using a 64-bit EFI, and then switched to a 32-bit one? Or is there a special mixed-mode capable installer?
(The ones I found are x86_64 only)
Ard Biesheuvel
maintainerRe: [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode
Quoted 51 lines · Ard Biesheuvel
Quoted 49 lines · Jiri Slaby
Quoted 32 lines · Ard Biesheuvel
Quoted 21 lines · Jiri Slaby
Quoted 10 lines · Ard Biesheuvel
Quoted 10 lines
Quoted 9 lines
Quoted 5 lines
$ rpm -qlp ~/Downloads/ovmf-202002-1.1.i586.rpm warning: /home/ardbie01/Downloads/ovmf-202002-1.1.i586.rpm: Header V3 RSA/SHA256 Signature, key ID 3dbdc284: NOKEY /usr/share/doc/packages/ovmf /usr/share/doc/packages/ovmf/READMEHmmm, it's weird that OBS doesn't list all derived files. Anyway, the ia32 ovmf is available in
http://download.opensuse.org/tumbleweed/repo/oss/noarch/qemu-ovmf-ia32-202002-1.1.noarch.rpmQuoted 8 lines
Quoted 5 lines
It indeed does:
https://build.opensuse.org/package/binaries/openSUSE:Factory/ovmf/standardNote that the ia32 version is noarch, built on i586.
I am not able to reproduce this issue using the linked firmware image and a 5.6
x86_64_defconfigwith efivarfs built in.Quoted 9 lines
Yeah, I had to use the distro config too. Not sure what the trigger is. Maybe some NUMA configs or something.
Quoted 2 lines
Could anyone share the full log, please, along with the kernel config that was used?
Both uploaded:
http://decibel.fi.muni.cz/~xslaby/err/Quoted 8 lines
With the same config, I am still not seeing the issue.
Quoted 3 lines
Note that I switched the for-me-necessary =m configs to =y. So that it is enough to build bzImage, w/o modules...
Could you please try running it again with
CONFIG_EFI_PGT_DUMP=yenabled?No problem:
http://decibel.fi.muni.cz/~xslaby/err/dmesg2.txtQuoted 2 lines
In the mean time, I will try to install Tumbleweed from scratch. Do you have any steps I could follow to reproduce your setup?
Quoted 7 lines
Quoted 2 lines
Not really, just installed TW 64-bit and used efi and grub 32 bit.
OK, so you installed using a 64-bit EFI, and then switched to a 32-bit one? Or is there a special mixed-mode capable installer?
(The ones I found are
x86_64only)
OK, I have managed to install tumbleweed into a 64-bit VM with 64-bit GRUB.
Could you give any instructions how to convert to 32-bit GRUB please?
Ard Biesheuvel
maintainerRe: [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode
Quoted 56 lines · Ard Biesheuvel
Quoted 54 lines · Ard Biesheuvel
Quoted 51 lines · Jiri Slaby
Quoted 32 lines · Ard Biesheuvel
Quoted 21 lines · Jiri Slaby
Quoted 10 lines · Ard Biesheuvel
Quoted 10 lines
Quoted 9 lines
Quoted 5 lines
$ rpm -qlp ~/Downloads/ovmf-202002-1.1.i586.rpm warning: /home/ardbie01/Downloads/ovmf-202002-1.1.i586.rpm: Header V3 RSA/SHA256 Signature, key ID 3dbdc284: NOKEY /usr/share/doc/packages/ovmf /usr/share/doc/packages/ovmf/READMEHmmm, it's weird that OBS doesn't list all derived files. Anyway, the ia32 ovmf is available in
http://download.opensuse.org/tumbleweed/repo/oss/noarch/qemu-ovmf-ia32-202002-1.1.noarch.rpmQuoted 8 lines
Quoted 5 lines
It indeed does:
https://build.opensuse.org/package/binaries/openSUSE:Factory/ovmf/standardNote that the ia32 version is noarch, built on i586.
I am not able to reproduce this issue using the linked firmware image and a 5.6
x86_64_defconfigwith efivarfs built in.Quoted 9 lines
Yeah, I had to use the distro config too. Not sure what the trigger is. Maybe some NUMA configs or something.
Quoted 2 lines
Could anyone share the full log, please, along with the kernel config that was used?
Both uploaded:
http://decibel.fi.muni.cz/~xslaby/err/Quoted 8 lines
With the same config, I am still not seeing the issue.
Quoted 3 lines
Note that I switched the for-me-necessary =m configs to =y. So that it is enough to build bzImage, w/o modules...
Could you please try running it again with
CONFIG_EFI_PGT_DUMP=yenabled?No problem:
http://decibel.fi.muni.cz/~xslaby/err/dmesg2.txtQuoted 2 lines
In the mean time, I will try to install Tumbleweed from scratch. Do you have any steps I could follow to reproduce your setup?
Not really, just installed TW 64-bit and used efi and grub 32 bit.
Quoted 8 lines
Quoted 4 lines
OK, so you installed using a 64-bit EFI, and then switched to a 32-bit one? Or is there a special mixed-mode capable installer?
(The ones I found are
x86_64only)OK, I have managed to install tumbleweed into a 64-bit VM with 64-bit GRUB.
Could you give any instructions how to convert to 32-bit GRUB please?
Never mind - I managed to switch. I still don't see the issue though :-(
Ard Biesheuvel
maintainerRe: [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode
Quoted 61 lines · Ard Biesheuvel
Quoted 59 lines · Ard Biesheuvel
Quoted 57 lines · Ard Biesheuvel
Quoted 43 lines · Jiri Slaby
Quoted 32 lines · Ard Biesheuvel
Quoted 21 lines · Jiri Slaby
Quoted 10 lines · Ard Biesheuvel
Quoted 10 lines
Quoted 9 lines
Quoted 5 lines
$ rpm -qlp ~/Downloads/ovmf-202002-1.1.i586.rpm warning: /home/ardbie01/Downloads/ovmf-202002-1.1.i586.rpm: Header V3 RSA/SHA256 Signature, key ID 3dbdc284: NOKEY /usr/share/doc/packages/ovmf /usr/share/doc/packages/ovmf/READMEHmmm, it's weird that OBS doesn't list all derived files. Anyway, the ia32 ovmf is available in
http://download.opensuse.org/tumbleweed/repo/oss/noarch/qemu-ovmf-ia32-202002-1.1.noarch.rpmQuoted 8 lines
Quoted 5 lines
It indeed does:
https://build.opensuse.org/package/binaries/openSUSE:Factory/ovmf/standardNote that the ia32 version is noarch, built on i586.
I am not able to reproduce this issue using the linked firmware image and a 5.6
x86_64_defconfigwith efivarfs built in.Quoted 9 lines
Yeah, I had to use the distro config too. Not sure what the trigger is. Maybe some NUMA configs or something.
Quoted 2 lines
Could anyone share the full log, please, along with the kernel config that was used?
Both uploaded:
http://decibel.fi.muni.cz/~xslaby/err/Quoted 8 lines
With the same config, I am still not seeing the issue.
Quoted 3 lines
Note that I switched the for-me-necessary =m configs to =y. So that it is enough to build bzImage, w/o modules...
Could you please try running it again with
CONFIG_EFI_PGT_DUMP=yenabled?Quoted 8 lines
No problem:
http://decibel.fi.muni.cz/~xslaby/err/dmesg2.txtQuoted 2 lines
In the mean time, I will try to install Tumbleweed from scratch. Do you have any steps I could follow to reproduce your setup?
Not really, just installed TW 64-bit and used efi and grub 32 bit.
OK, so you installed using a 64-bit EFI, and then switched to a 32-bit one? Or is there a special mixed-mode capable installer?
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
(The ones I found are
x86_64only)OK, I have managed to install tumbleweed into a 64-bit VM with 64-bit GRUB.
Could you give any instructions how to convert to 32-bit GRUB please?
Never mind - I managed to switch. I still don't see the issue though :-(
Success!!
[ 2.416076] BUG: unable to handle page fault for address: 0000000028348e88 [ 2.417698] #PF: supervisor write access in kernel mode [ 2.418697] #PF: error_code(0x0003) - permissions violation [ 2.419927] PGD fd61063 P4D fd61063 PUD fd62063 PMD 282000e1 [ 2.421131] Oops: 0003 [#1] SMP PTI [ 2.421857] CPU: 3 PID: 254 Comm: systemd-system- Not tainted 5.6.0-rc4-default+ #19 [ 2.423364] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [ 2.424814] RIP: 0008:0x3eaeed95 [ 2.425376] Code: 8b 45 d4 8b 4d 10 8b 40 04 89 01 89 3b 50 6a 00 8b 55 0c 6a 00 8b 45 08 0f b6 4d e4 6a 01 31 f6 e8 ee c5 fc ff 83 c4 10 eb 07 <89> 03 be 05 00 00 80 a1 74 63 b1 3e 83 c0 48 e8 44 d2 ff ff eb 05 [ 2.428159] RSP: 0018:000000000fd73fa0 EFLAGS: 00010002 [ 2.429012] RAX: 0000000000000001 RBX: 0000000028348e88 RCX: 000000003e9f1120 [ 2.430063] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000001 [ 2.431459] RBP: 000000000fd73fd8 R08: 0000000028348e88 R09: 0000000000000000 [ 2.433037] R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000 [ 2.433386] usb 1-2: New USB device found, idVendor=0627, idProduct=0001, bcdDevice= 0.00 [ 2.434484] R13: ffffa02f80220000 R14: 0000000000000000 R15: 0000000000000000 [ 2.436404] usb 1-2: New USB device strings: Mfr=1, Product=3, SerialNumber=5 [ 2.437438] FS: 00007f121439c940(0000) GS:ffff8accbd580000(0000) knlGS:0000000000000000 [ 2.438872] usb 1-2: Product: QEMU USB Tablet [ 2.439986] CS: 0008 DS: 0018 ES: 0018 CR0: 0000000080050033 [ 2.439987] CR2: 0000000028348e88 CR3: 000000000fd6c005 CR4: 00000000003606e0 [ 2.440878] usb 1-2: Manufacturer: QEMU [ 2.441686] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2.442979] usb 1-2: SerialNumber: 42 [ 2.443559] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 2.443561] Call Trace: [ 2.447302] Modules linked in: [ 2.447830] CR2: 0000000028348e88 [ 2.448459] ---[ end trace 604ea22c03fc4e28 ]---
Ard Biesheuvel
maintainerPATCH 6/13 efi/x86: avoid RWX mappings for all of DRAM
In reply to Ard BiesheuvelThe EFI code creates RWX mappings for all memory regions that are occupied after the stub completes, and in the mixed mode case, it even creates RWX mappings for all of the remaining DRAM as well.
Let's try to avoid this, by setting the NX bit for all memory regions except the ones that are marked as EFI runtime services code [which means text+rodata+data in practice, so we cannot mark them read-only right away]. For cases of buggy firmware where boot services code is called during SetVirtualAddressMap(), map those regions with exec permissions as well - they will be unmapped in efi_free_boot_services().
--- arch/x86/platform/efi/efi_64.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-)
arch/x86/platform/efi/efi_64.c +16 -4
@@ -365,10 +365,6 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)* as trim_bios_range() will reserve the first page and isolate it away * from memory allocators anyway. */ - pf = _PAGE_RW; -if (sev_active ()) - pf |= _PAGE_ENC; -if (kernel_map_pages_in_pgd (pgd,0x0 ,0x0 ,1 , pf)) {pr_err ("Failed to create 1:1 mapping for the first page!\n" );return 1 ;
@@ -410,6 +406,22 @@ static void __init __map_region(efi_memory_desc_t *md, u64 va)unsigned long pfn;pgd_t *pgd = efi_mm.pgd; +/* +* EFI_RUNTIME_SERVICES_CODE regions typically cover PE/COFF +* executable images in memory that consist of both R-X and +* RW- sections, so we cannot apply read-only or non-exec +* permissions just yet. However, modern EFI systems provide +* a memory attributes table that describes those sections +* with the appropriate restricted permissions, which are +* applied in efi_runtime_update_mappings() below. All other +* regions can be mapped non-executable at this point, with +* the exception of boot services code regions, but those will +* be unmapped again entirely in efi_free_boot_services(). +*/ +if (md->type !=EFI_BOOT_SERVICES_CODE && + md->type !=EFI_RUNTIME_SERVICES_CODE ) + flags |= _PAGE_NX; +if (!(md->attribute &EFI_MEMORY_WB )) flags |= _PAGE_PCD;
Signature · 1 line
2.20.1
Ard Biesheuvel
maintainerPATCH 7/13 efi/x86: limit EFI old memory map to SGI UV machines
In reply to Ard BiesheuvelWe carry a quirk in the x86 EFI code to switch back to an older method of mapping the EFI runtime services memory regions, because it was deemed risky at the time to implement a new method without providing a fallback to the old method in case problems arose.
Such problems did arise, but they appear to be limited to SGI UV1 machines, and so these are the only ones for which the fallback gets enabled automatically (via a DMI quirk). The fallback can be enabled manually as well, by passing efi=old_map, but there is very little evidence that suggests that this is something that is being relied upon in the field.
Given that UV1 support is not enabled by default by the distros (Ubuntu, Fedora), there is no point in carrying this fallback code all the time if there are no other users. So let's move it into the UV support code, and document that efi=old_map now requires this support code to be enabled.
Note that efi=old_map has been used in the past on other SGI UV machines to work around kernel regressions in production, so we keep the option to enable it by hand, but only if the kernel was built with UV support.
--- .../admin-guide/kernel-parameters.txt | 3 +- arch/x86/include/asm/efi.h | 26 +-- arch/x86/kernel/kexec-bzimage64.c | 2 +- arch/x86/platform/efi/efi.c | 30 ++-- arch/x86/platform/efi/efi_64.c | 166 +----------------- arch/x86/platform/efi/quirks.c | 21 ++- arch/x86/platform/uv/bios_uv.c | 164 ++++++++++++++++- 7 files changed, 211 insertions(+), 201 deletions(-)
Documentation/admin-guide/kernel-parameters.txt +1 -2
@@ -1168,8 +1168,7 @@ "nosoftreserve", "disable_early_pci_dma", "no_disable_early_pci_dma" } old_map [X86-64]: switch to the old ioremap-based EFI - runtime services mapping. 32-bit still uses this one by - default. + runtime services mapping. [Needs CONFIG_X86_UV=y] nochunk: disable reading files in "chunks" in the EFI boot stub, as chunking can cause problems with some firmware implementations.
arch/x86/include/asm/efi.h +14 -12
@@ -20,13 +20,16 @@* This is the main reason why we're doing stable VA mappings for RT * services. * -* This flag is used in conjunction with a chicken bit called -* "efi=old_map" which can be used as a fallback to the old runtime -* services mapping method in case there's some b0rkage with a -* particular EFI implementation (haha, it is hard to hold up the -* sarcasm here...). +* SGI UV1 machines are known to be incompatible with this scheme, so we +* provide an opt-out for these machines via a DMI quirk that sets the +* attribute below. */ -#define EFI_OLD_MEMMAP EFI_ARCH_1 +#define EFI_UV1_MEMMAP EFI_ARCH_1 + +static inline bool efi_have_uv1_memmap (void ) +{ +return IS_ENABLED (CONFIG_X86_UV ) &&efi_enabled (EFI_UV1_MEMMAP ); +}#define EFI32_LOADER_SIGNATURE "EL32"#define EFI64_LOADER_SIGNATURE "EL64"
@@ -119,7 +122,7 @@ struct efi_scratch {kernel_fpu_begin (); \firmware_restrict_branch_speculation_start (); \ \ -if (!efi_enabled (EFI_OLD_MEMMAP )) \ +if (!efi_have_uv1_memmap ()) \efi_switch_mm (&efi_mm); \ })
@@ -128,7 +131,7 @@ struct efi_scratch {#define arch_efi_call_virt_teardown () \ ({ \ - if (!efi_enabled(EFI_OLD_MEMMAP)) \ + if (!efi_have_uv1_memmap()) \ efi_switch_mm(efi_scratch.prev_mm); \ \ firmware_restrict_branch_speculation_end(); \
@@ -172,6 +175,8 @@ extern void efi_delete_dummy_variable(void);extern void efi_switch_mm (struct mm_struct *mm);extern void efi_recover_from_page_fault (unsigned long phys_addr);extern void efi_free_boot_services (void ); +extern pgd_t *__init efi_uv1_memmap_phys_prolog (void ); +extern void __init efi_uv1_memmap_phys_epilog (pgd_t *save_pgd);struct efi_setup_data {u64 fw_vendor;
@@ -203,10 +208,7 @@ static inline bool efi_runtime_supported(void)if (IS_ENABLED (CONFIG_X86_64 ) ==efi_enabled (EFI_64BIT ))return true; -if (IS_ENABLED (CONFIG_EFI_MIXED ) && !efi_enabled (EFI_OLD_MEMMAP )) -return true; - -return false; +return IS_ENABLED (CONFIG_EFI_MIXED ); }extern void parse_efi_setup (u64 phys_addr,u32 data_len);
arch/x86/kernel/kexec-bzimage64.c +1 -1
@@ -177,7 +177,7 @@ setup_efi_state(struct boot_params *params, unsigned long params_load_addr,* acpi_rsdp=<addr> on kernel command line to make second kernel boot * without efi. */ -if (efi_enabled (EFI_OLD_MEMMAP )) +if (efi_have_uv1_memmap ())return 0 ; params->secure_boot = boot_params.secure_boot;
arch/x86/platform/efi/efi.c +10 -20
@@ -497,6 +497,8 @@ void __init efi_init(void)efi_print_memmap (); } +#if defined(CONFIG_X86_32 ) || defined(CONFIG_X86_UV ) +void __init efi_set_executable (efi_memory_desc_t *md,bool executable) {u64 addr, npages;
@@ -561,6 +563,8 @@ void __init old_map_region(efi_memory_desc_t *md) (unsigned long long)md->phys_addr); } +#endif +/* Merge contiguous regions of the same type and attribute */ static void __init efi_merge_regions (void ) {
@@ -659,7 +663,7 @@ static inline void *efi_map_next_entry_reverse(void *entry)*/ static void *efi_map_next_entry (void *entry) { -if (!efi_enabled (EFI_OLD_MEMMAP ) &&efi_enabled (EFI_64BIT )) { +if (!efi_have_uv1_memmap () &&efi_enabled (EFI_64BIT )) {/* * Starting in UEFI v2.5 the EFI_PROPERTIES_TABLE * config table feature requires us to map all entries
@@ -791,11 +795,11 @@ static void __init kexec_enter_virtual_mode(void)/* * We don't do virtual mode, since we don't do runtime services, on -* non-native EFI. With efi=old_map, we don't do runtime services in +* non-native EFI. With the UV1 memmap, we don't do runtime services in * kexec kernel because in the initial boot something else might * have been mapped at these virtual addresses. */ -if (efi_is_mixed () ||efi_enabled (EFI_OLD_MEMMAP )) { +if (efi_is_mixed () ||efi_have_uv1_memmap ()) {efi_memmap_unmap ();clear_bit (EFI_RUNTIME_SERVICES , &efi.flags);return ;
@@ -861,9 +865,9 @@ static void __init kexec_enter_virtual_mode(void)* * The old method which used to update that memory descriptor with the * virtual address obtained from ioremap() is still supported when the -* kernel is booted with efi=old_map on its command line. Same old -* method enabled the runtime services to be called without having to -* thunk back into physical mode for every invocation. +* kernel is booted on SG1 UV1 hardware. Same old method enabled the +* runtime services to be called without having to thunk back into +* physical mode for every invocation. * * The new method does a pagetable switch in a preemption-safe manner * so that we're in a different address space when calling a runtime
@@ -976,20 +980,6 @@ void __init efi_enter_virtual_mode(void)efi_dump_pagetable (); } -static int __init arch_parse_efi_cmdline (char *str) -{ -if (!str) { -pr_warn ("need at least one option\n" ); -return -EINVAL ; - } - -if (parse_option_str (str,"old_map" )) -set_bit (EFI_OLD_MEMMAP , &efi.flags); - -return 0 ; -} -early_param ("efi" , arch_parse_efi_cmdline); -bool efi_is_table_address (unsigned long phys_addr) {unsigned int i;
arch/x86/platform/efi/efi_64.c +9 -157
226 lines not on this page · raw message
arch/x86/platform/efi/quirks.c +14 -7
@@ -384,10 +384,10 @@ static void __init efi_unmap_pages(efi_memory_desc_t *md)/* * To Do: Remove this check after adding functionality to unmap EFI boot -* services code/data regions from direct mapping area because -* "efi=old_map" maps EFI regions in swapper_pg_dir. +* services code/data regions from direct mapping area because the UV1 +* memory map maps EFI regions in swapper_pg_dir. */ -if (efi_enabled (EFI_OLD_MEMMAP )) +if (efi_have_uv1_memmap ())return ;/*
@@ -558,7 +558,7 @@ int __init efi_reuse_config(u64 tables, int nr_tables)return ret; } -static const struct dmi_system_id sgi_uv1_dmi[] = { +static const struct dmi_system_id sgi_uv1_dmi[]__initconst = { {NULL ,"SGI UV1" , {DMI_MATCH (DMI_PRODUCT_NAME ,"Stoutland Platform" ),DMI_MATCH (DMI_PRODUCT_VERSION ,"1.0" ),
@@ -581,8 +581,15 @@ void __init efi_apply_memmap_quirks(void) }/* UV2+ BIOS has a fix for this issue. UV1 still needs the quirk. */ -if (dmi_check_system (sgi_uv1_dmi)) -set_bit (EFI_OLD_MEMMAP , &efi.flags); +if (dmi_check_system (sgi_uv1_dmi)) { +if (IS_ENABLED (CONFIG_X86_UV )) { +set_bit (EFI_UV1_MEMMAP , &efi.flags); + }else { +pr_warn ("EFI runtime disabled, needs CONFIG_X86_UV=y on UV1\n" ); +clear_bit (EFI_RUNTIME_SERVICES , &efi.flags); +efi_memmap_unmap (); + } + } }/*
@@ -720,7 +727,7 @@ void efi_recover_from_page_fault(unsigned long phys_addr)/* * Make sure that an efi runtime service caused the page fault. * "efi_mm" cannot be used to check if the page fault had occurred -* in the firmware context because efi=old_map doesn't use efi_pgd. +* in the firmware context because the UV1 memmap doesn't use efi_pgd. */ if (efi_rts_work.efi_rts_id ==EFI_NONE )return ;
arch/x86/platform/uv/bios_uv.c +162 -2
175 lines not on this page · raw message
Signature · 1 line
2.20.1
Ard Biesheuvel
maintainerPATCH 8/13 efi/arm: defer probe of PCIe backed efifb on DT systems
In reply to Ard BiesheuvelThe new of_devlink support breaks PCIe probing on ARM platforms booting via UEFI if the firmware exposes a EFI framebuffer that is backed by a PCI device. The reason is that the probing order gets reversed, resulting in a resource conflict on the framebuffer memory window when the PCIe probes last, causing it to give up entirely.
Given that we rely on PCI quirks to deal with EFI framebuffers that get moved around in memory, we cannot simply drop the memory reservation, so instead, let's use the device link infrastructure to register this dependency, and force the probing to occur in the expected order.
--- drivers/firmware/efi/arm-init.c | 107 ++++++++++++++++++++++++++++++-- 1 file changed, 103 insertions(+), 4 deletions(-)
drivers/firmware/efi/arm-init.c +103 -4
@@ -10,10 +10,12 @@#define pr_fmt (fmt) "efi: " fmt#include <linux/efi.h> +#include <linux/fwnode.h> #include <linux/init.h> #include <linux/memblock.h> #include <linux/mm_types.h> #include <linux/of.h> +#include <linux/of_address.h> #include <linux/of_fdt.h> #include <linux/platform_device.h> #include <linux/screen_info.h>
@@ -276,15 +278,112 @@ void __init efi_init(void)efi_memmap_unmap (); } +static bool efifb_overlaps_pci_range (const struct of_pci_range *range) +{ +u64 fb_base = screen_info.lfb_base; + +if (screen_info.capabilities &VIDEO_CAPABILITY_64BIT_BASE ) + fb_base |= (u64 )(unsigned long )screen_info.ext_lfb_base <<32 ; + +return fb_base >= range->cpu_addr && + fb_base < (range->cpu_addr + range->size); +} + +static struct device_node *find_pci_overlap_node (void ) +{ +struct device_node *np; + +for_each_node_by_type (np,"pci" ) { +struct of_pci_range_parser parser; +struct of_pci_range range; +int err; + + err =of_pci_range_parser_init (&parser, np); +if (err) { +pr_warn ("of_pci_range_parser_init() failed: %d\n" , err); +continue ; + } + +for_each_of_pci_range (&parser, &range) +if (efifb_overlaps_pci_range (&range)) +return np; + } +return NULL ; +} + +/* +* If the efifb framebuffer is backed by a PCI graphics controller, we have +* to ensure that this relation is expressed using a device link when +* running in DT mode, or the probe order may be reversed, resulting in a +* resource reservation conflict on the memory window that the efifb +* framebuffer steals from the PCIe host bridge. +*/ +static int efifb_add_links (const struct fwnode_handle *fwnode, +struct device *dev) +{ +struct device_node *sup_np; +struct device *sup_dev; + + sup_np =find_pci_overlap_node (); + +/* +* If there's no PCI graphics controller backing the efifb, we are +* done here. +*/ +if (!sup_np) +return 0 ; + + sup_dev =get_dev_from_fwnode (&sup_np->fwnode); +of_node_put (sup_np); + +/* +* Return -ENODEV if the PCI graphics controller device hasn't been +* registered yet. This ensures that efifb isn't allowed to probe +* and this function is retried again when new devices are +* registered. +*/ +if (!sup_dev) +return -ENODEV ; + +/* +* If this fails, retrying this function at a later point won't +* change anything. So, don't return an error after this. +*/ +if (!device_link_add (dev, sup_dev,0 )) +dev_warn (dev,"device_link_add() failed\n" ); + +put_device (sup_dev); + +return 0 ; +} + +static const struct fwnode_operations efifb_fwnode_ops = { + .add_links = efifb_add_links, +}; + +static struct fwnode_handle efifb_fwnode = { + .ops = &efifb_fwnode_ops, +}; +static int __init register_gop_device (void ) { -void *pd; +struct platform_device *pd; +int err;if (screen_info.orig_video_isVGA !=VIDEO_TYPE_EFI )return 0 ; - pd =platform_device_register_data (NULL ,"efi-framebuffer" ,0 , - &screen_info,sizeof (screen_info)); -return PTR_ERR_OR_ZERO (pd); + pd =platform_device_alloc ("efi-framebuffer" ,0 ); +if (!pd) +return -ENOMEM ; + +if (IS_ENABLED (CONFIG_PCI )) + pd->dev.fwnode = &efifb_fwnode; + + err =platform_device_add_data (pd, &screen_info,sizeof (screen_info)); +if (err) +return err; + +return platform_device_add (pd); }subsys_initcall (register_gop_device);
Signature · 1 line
2.20.1
Ard Biesheuvel
maintainerPATCH 9/13 efi: Fix comment for efi_mem_type() wrt absent physical addresses
In reply to Ard BiesheuvelFrom: Anshuman Khandual <[email protected]>
A previous commit f99afd08a45f ("efi: Update efi_mem_type() to return an error rather than 0") changed the return value from EFI_RESERVED_TYPE to -EINVAL when the searched physical address is not present in any memory descriptor. But the comment preceding the function never changed. Let's change the comment now to reflect the new return value -EINVAL.
--- drivers/firmware/efi/efi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/firmware/efi/efi.c +1 -1
@@ -908,7 +908,7 @@ u64 efi_mem_attributes(unsigned long phys_addr)* * Search in the EFI memory map for the region covering @phys_addr. * Returns the EFI memory type if the region was found in the memory -* map, EFI_RESERVED_TYPE (zero) otherwise. +* map, -EINVAL otherwise. */ int efi_mem_type (unsigned long phys_addr) {
Signature · 1 line
2.20.1
Ard Biesheuvel
maintainerPATCH 10/13 efi: Add a flags parameter to efi_memory_map
In reply to Ard BiesheuvelFrom: Dan Williams <[email protected]>
In preparation for garbage collecting dynamically allocated efi memory maps, where the allocation method of memblock vs slab needs to be recalled, convert the existing 'late' flag into a 'flags' bitmask.
Arrange for the flag to be passed via 'struct efi_memory_map_data'. This structure grows additional flags in follow-on changes.
--- drivers/firmware/efi/memmap.c | 31 +++++++++++++++++-------------- include/linux/efi.h | 4 +++- 2 files changed, 20 insertions(+), 15 deletions(-)
drivers/firmware/efi/memmap.c +17 -14
@@ -52,21 +52,20 @@ phys_addr_t __init efi_memmap_alloc(unsigned int num_entries)/** * __efi_memmap_init - Common code for mapping the EFI memory map * @data: EFI memory map data -* @late: Use early or late mapping function? * * This function takes care of figuring out which function to use to * map the EFI memory map in efi.memmap based on how far into the boot * we are. * -* During bootup @late should be %false since we only have access to -* the early_memremap*() functions as the vmalloc space isn't setup. -* Once the kernel is fully booted we can fallback to the more robust -* memremap*() API. +* During bootup EFI_MEMMAP_LATE in data->flags should be clear since we +* only have access to the early_memremap*() functions as the vmalloc +* space isn't setup. Once the kernel is fully booted we can fallback +* to the more robust memremap*() API. * * Returns zero on success, a negative error code on failure. */ static int __init -__efi_memmap_init (struct efi_memory_map_data *data,bool late) +__efi_memmap_init (struct efi_memory_map_data *data) {struct efi_memory_map map;phys_addr_t phys_map;
@@ -76,7 +75,7 @@ __efi_memmap_init(struct efi_memory_map_data *data, bool late) phys_map = data->phys_map; -if (late) +if (data->flags &EFI_MEMMAP_LATE ) map.map =memremap (phys_map, data->size,MEMREMAP_WB );else map.map =early_memremap (phys_map, data->size);
@@ -92,7 +91,7 @@ __efi_memmap_init(struct efi_memory_map_data *data, bool late) map.desc_version = data->desc_version; map.desc_size = data->desc_size; - map.late = late; + map.flags = data->flags;set_bit (EFI_MEMMAP , &efi.flags);
@@ -111,9 +110,10 @@ __efi_memmap_init(struct efi_memory_map_data *data, bool late)int __init efi_memmap_init_early (struct efi_memory_map_data *data) {/* Cannot go backwards */ -WARN_ON (efi.memmap.late); +WARN_ON (efi.memmap.flags &EFI_MEMMAP_LATE ); -return __efi_memmap_init (data, false); + data->flags =0 ; +return __efi_memmap_init (data); }void __init efi_memmap_unmap (void )
@@ -121,7 +121,7 @@ void __init efi_memmap_unmap(void)if (!efi_enabled (EFI_MEMMAP ))return ; -if (!efi.memmap.late) { +if (!(efi.memmap.flags &EFI_MEMMAP_LATE )) {unsigned long size; size = efi.memmap.desc_size * efi.memmap.nr_map;
@@ -162,13 +162,14 @@ int __init efi_memmap_init_late(phys_addr_t addr, unsigned long size)struct efi_memory_map_data data = { .phys_map = addr, .size = size, + .flags =EFI_MEMMAP_LATE , };/* Did we forget to unmap the early EFI memmap? */ WARN_ON (efi.memmap.map);/* Were we already called? */ -WARN_ON (efi.memmap.late); +WARN_ON (efi.memmap.flags &EFI_MEMMAP_LATE );/* * It makes no sense to allow callers to register different
@@ -178,7 +179,7 @@ int __init efi_memmap_init_late(phys_addr_t addr, unsigned long size) data.desc_version = efi.memmap.desc_version; data.desc_size = efi.memmap.desc_size; -return __efi_memmap_init (&data, true); +return __efi_memmap_init (&data); }/**
@@ -195,6 +196,7 @@ int __init efi_memmap_init_late(phys_addr_t addr, unsigned long size)int __init efi_memmap_install (phys_addr_t addr,unsigned int nr_map) {struct efi_memory_map_data data; +unsigned long flags;efi_memmap_unmap ();
@@ -202,8 +204,9 @@ int __init efi_memmap_install(phys_addr_t addr, unsigned int nr_map) data.size = efi.memmap.desc_size * nr_map; data.desc_version = efi.memmap.desc_version; data.desc_size = efi.memmap.desc_size; + data.flags = efi.memmap.flags &EFI_MEMMAP_LATE ; -return __efi_memmap_init (&data, efi.memmap.late); +return __efi_memmap_init (&data); }/**
include/linux/efi.h +3 -1
@@ -767,6 +767,7 @@ struct efi_memory_map_data {unsigned long size;unsigned long desc_version;unsigned long desc_size; +unsigned long flags; };struct efi_memory_map {
@@ -776,7 +777,8 @@ struct efi_memory_map {int nr_map;unsigned long desc_version;unsigned long desc_size; -bool late; +#define EFI_MEMMAP_LATE (1UL << 0) +unsigned long flags; };struct efi_mem_range {
Signature · 1 line
2.20.1
Ard Biesheuvel
maintainerPATCH 11/13 efi: Add tracking for dynamically allocated memmaps
In reply to Ard BiesheuvelFrom: Dan Williams <[email protected]>
In preparation for fixing efi_memmap_alloc() leaks, add support for recording whether the memmap was dynamically allocated from slab, memblock, or is the original physical memmap provided by the platform.
Given this tracking is established in efi_memmap_alloc() and needs to be carried to efi_memmap_install(), use 'struct efi_memory_map_data' to convey the flags.
Some small cleanups result from this reorganization, specifically the removal of local variables for 'phys' and 'size' that are already tracked in @data.
--- arch/x86/platform/efi/efi.c | 10 +++++-- arch/x86/platform/efi/quirks.c | 23 +++++++--------- drivers/firmware/efi/fake_mem.c | 14 +++++----- drivers/firmware/efi/memmap.c | 47 ++++++++++++++++++--------------- include/linux/efi.h | 11 +++++--- 5 files changed, 56 insertions(+), 49 deletions(-)
arch/x86/platform/efi/efi.c +8 -2
@@ -304,10 +304,16 @@ static void __init efi_clean_memmap(void) }if (n_removal >0 ) { -u64 size = efi.memmap.nr_map - n_removal; +struct efi_memory_map_data data = { + .phys_map = efi.memmap.phys_map, + .desc_version = efi.memmap.desc_version, + .desc_size = efi.memmap.desc_size, + .size = data.desc_size * (efi.memmap.nr_map - n_removal), + .flags =0 , + };pr_warn ("Removing %d invalid memory map entries.\n" , n_removal); -efi_memmap_install (efi.memmap.phys_map, size); +efi_memmap_install (&data); } }
arch/x86/platform/efi/quirks.c +9 -14
@@ -243,7 +243,7 @@ EXPORT_SYMBOL_GPL(efi_query_variable_store);*/ void __init efi_arch_mem_reserve (phys_addr_t addr,u64 size) { -phys_addr_t new_phys, new_size; +struct efi_memory_map_data data = {0 };struct efi_mem_range mr;efi_memory_desc_t md;int num_entries;
@@ -271,24 +271,21 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size) num_entries =efi_memmap_split_count (&md, &mr.range); num_entries += efi.memmap.nr_map; - new_size = efi.memmap.desc_size * num_entries; - - new_phys =efi_memmap_alloc (num_entries); -if (!new_phys) { +if (efi_memmap_alloc (num_entries, &data) !=0 ) {pr_err ("Could not allocate boot services memmap\n" );return ; } - new =early_memremap (new_phys, new_size); + new =early_memremap (data.phys_map, data.size);if (!new) {pr_err ("Failed to map new boot services memmap\n" );return ; }efi_memmap_insert (&efi.memmap, new, &mr); -early_memunmap (new, new_size); +early_memunmap (new, data.size); -efi_memmap_install (new_phys, num_entries); +efi_memmap_install (&data);e820__range_update (addr, size,E820_TYPE_RAM ,E820_TYPE_RESERVED );e820__update_table (e820_table); }
@@ -407,7 +404,7 @@ static void __init efi_unmap_pages(efi_memory_desc_t *md)void __init efi_free_boot_services (void ) { -phys_addr_t new_phys, new_size; +struct efi_memory_map_data data = {0 };efi_memory_desc_t *md;int num_entries =0 ;void *new, *new_md;
@@ -462,14 +459,12 @@ void __init efi_free_boot_services(void)if (!num_entries)return ; - new_size = efi.memmap.desc_size * num_entries; - new_phys =efi_memmap_alloc (num_entries); -if (!new_phys) { +if (efi_memmap_alloc (num_entries, &data) !=0 ) {pr_err ("Failed to allocate new EFI memmap\n" );return ; } - new =memremap (new_phys, new_size,MEMREMAP_WB ); + new =memremap (data.phys_map, data.size,MEMREMAP_WB );if (!new) {pr_err ("Failed to map new EFI memmap\n" );return ;
@@ -493,7 +488,7 @@ void __init efi_free_boot_services(void)memunmap (new); -if (efi_memmap_install (new_phys, num_entries)) { +if (efi_memmap_install (&data) !=0 ) {pr_err ("Could not install new EFI memmap\n" );return ; }
drivers/firmware/efi/fake_mem.c +6 -8
@@ -36,9 +36,9 @@ static int __init cmp_fake_mem(const void *x1, const void *x2)void __init efi_fake_memmap (void ) { +struct efi_memory_map_data data = {0 };int new_nr_map = efi.memmap.nr_map;efi_memory_desc_t *md; -phys_addr_t new_memmap_phy;void *new_memmap;int i;
@@ -55,15 +55,13 @@ void __init efi_fake_memmap(void) }/* allocate memory for new EFI memmap */ - new_memmap_phy =efi_memmap_alloc (new_nr_map); -if (!new_memmap_phy) +if (efi_memmap_alloc (new_nr_map, &data) !=0 )return ;/* create new EFI memmap */ - new_memmap =early_memremap (new_memmap_phy, - efi.memmap.desc_size * new_nr_map); + new_memmap =early_memremap (data.phys_map, data.size);if (!new_memmap) { -memblock_free (new_memmap_phy, efi.memmap.desc_size * new_nr_map); +memblock_free (data.phys_map, data.size);return ; }
@@ -71,9 +69,9 @@ void __init efi_fake_memmap(void)efi_memmap_insert (&efi.memmap, new_memmap, &efi_fake_mems[i]);/* swap into new EFI memmap */ -early_memunmap (new_memmap, efi.memmap.desc_size * new_nr_map); +early_memunmap (new_memmap, data.size); -efi_memmap_install (new_memmap_phy, new_nr_map); +efi_memmap_install (&data);/* print new EFI memmap */ efi_print_memmap ();
drivers/firmware/efi/memmap.c +26 -21
82 lines not on this page · raw message
include/linux/efi.h +7 -4
@@ -759,8 +759,8 @@ typedef union {/* * Architecture independent structure for describing a memory map for the -* benefit of efi_memmap_init_early(), saving us the need to pass four -* parameters. +* benefit of efi_memmap_init_early(), and for passing context between +* efi_memmap_alloc() and efi_memmap_install(). */ struct efi_memory_map_data {phys_addr_t phys_map;
@@ -778,6 +778,8 @@ struct efi_memory_map {unsigned long desc_version;unsigned long desc_size;#define EFI_MEMMAP_LATE (1UL << 0) +#define EFI_MEMMAP_MEMBLOCK (1UL << 1) +#define EFI_MEMMAP_SLAB (1UL << 2)unsigned long flags; };
@@ -972,11 +974,12 @@ static inline efi_status_t efi_query_variable_store(u32 attributes,#endif extern void __iomem *efi_lookup_mapped_addr (u64 phys_addr); -extern phys_addr_t __init efi_memmap_alloc (unsigned int num_entries); +extern int __init efi_memmap_alloc (unsigned int num_entries, +struct efi_memory_map_data *data);extern int __init efi_memmap_init_early (struct efi_memory_map_data *data);extern int __init efi_memmap_init_late (phys_addr_t addr,unsigned long size);extern void __init efi_memmap_unmap (void ); -extern int __init efi_memmap_install (phys_addr_t addr,unsigned int nr_map); +extern int __init efi_memmap_install (struct efi_memory_map_data *data);extern int __init efi_memmap_split_count (efi_memory_desc_t *md,struct range *range); extern void __init efi_memmap_insert(struct efi_memory_map *old_memmap,
Signature · 1 line
2.20.1
Ard Biesheuvel
maintainerPATCH 12/13 efi: Fix efi_memmap_alloc() leaks
In reply to Ard BiesheuvelFrom: Dan Williams <[email protected]>
With efi_fake_memmap() and efi_arch_mem_reserve() the efi table may be updated and replaced multiple times. When that happens a previous dynamically allocated efi memory map can be garbage collected. Use the new EFI_MEMMAP_{SLAB,MEMBLOCK} flags to detect when a dynamically allocated memory map is being replaced.
Debug statements in efi_memmap_free() reveal:
efi: __efi_memmap_free:37: phys: 0x23ffdd580 size: 2688 flags: 0x2
efi: __efi_memmap_free:37: phys: 0x9db00 size: 2640 flags: 0x2
efi: __efi_memmap_free:37: phys: 0x9e580 size: 2640 flags: 0x2
...a savings of 7968 bytes on a qemu boot with 2 entries specified to efi_fake_mem=.
[ ardb: added a comment to clarify that efi_memmap_free() does nothing when
called from efi_clean_memmap(), i.e., with data->flags == 0x0 ]
--- drivers/firmware/efi/memmap.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
drivers/firmware/efi/memmap.c +25 -0
@@ -29,6 +29,28 @@ static phys_addr_t __init __efi_memmap_alloc_late(unsigned long size)return PFN_PHYS (page_to_pfn (p)); } +static void __init __efi_memmap_free (u64 phys,unsigned long size,unsigned long flags) +{ +if (flags &EFI_MEMMAP_MEMBLOCK ) { +if (slab_is_available ()) +memblock_free_late (phys, size); +else +memblock_free (phys, size); + }else if (flags &EFI_MEMMAP_SLAB ) { +struct page *p =pfn_to_page (PHYS_PFN (phys)); +unsigned int order =get_order (size); + +free_pages ((unsigned long )page_address (p), order); + } +} + +static void __init efi_memmap_free (void ) +{ +__efi_memmap_free (efi.memmap.phys_map, + efi.memmap.desc_size * efi.memmap.nr_map, + efi.memmap.flags); +} +/** * efi_memmap_alloc - Allocate memory for the EFI memory map * @num_entries: Number of entries in the allocated map.
@@ -100,6 +122,9 @@ static int __init __efi_memmap_init(struct efi_memory_map_data *data)return -ENOMEM ; } +/* NOP if data->flags & (EFI_MEMMAP_MEMBLOCK | EFI_MEMMAP_SLAB) == 0 */ +efi_memmap_free (); + map.phys_map = data->phys_map; map.nr_map = data->size / data->desc_size; map.map_end = map.map + data->size;
Signature · 1 line
2.20.1
Ard Biesheuvel
maintainerPATCH 13/13 efi: Fix handling of multiple efi_fake_mem= entries
In reply to Ard BiesheuvelFrom: Dan Williams <[email protected]>
Dave noticed that when specifying multiple efi_fake_mem= entries only the last entry was successfully being reflected in the efi memory map. This is due to the fact that the efi_memmap_insert() is being called multiple times, but on successive invocations the insertion should be applied to the last new memmap rather than the original map at efi_fake_memmap() entry.
Rework efi_fake_memmap() to install the new memory map after each efi_fake_mem= entry is parsed.
This also fixes an issue in efi_fake_memmap() that caused it to litter emtpy entries into the end of the efi memory map. An empty entry causes efi_memmap_insert() to attempt more memmap splits / copies than efi_memmap_split_count() accounted for when sizing the new map. When that happens efi_memmap_insert() may overrun its allocation, and if you are lucky will spill over to an unmapped page leading to crash signature like the following rather than silent corruption:
BUG: unable to handle page fault for address: ffffffffff281000
[..]
RIP: 0010:efi_memmap_insert+0x11d/0x191
[..]
Call Trace:
? bgrt_init+0xbe/0xbe
? efi_arch_mem_reserve+0x1cb/0x228
? acpi_parse_bgrt+0xa/0xd
? acpi_table_parse+0x86/0xb8
? acpi_boot_init+0x494/0x4e3
? acpi_parse_x2apic+0x87/0x87
? setup_acpi_sci+0xa2/0xa2
? setup_arch+0x8db/0x9e1
? start_kernel+0x6a/0x547
? secondary_startup_64+0xb6/0xc0Commit af1648984828 "x86/efi: Update e820 with reserved EFI boot services data to fix kexec breakage" introduced more occurrences where efi_memmap_insert() is invoked after an efi_fake_mem= configuration has been parsed. Previously the side effects of vestigial empty entries were benign, but with commit af1648984828 that follow-on efi_memmap_insert() invocation triggers efi_memmap_insert() overruns.
--- drivers/firmware/efi/fake_mem.c | 31 ++++++++++++++++--------------- drivers/firmware/efi/memmap.c | 2 +- include/linux/efi.h | 2 ++ 3 files changed, 19 insertions(+), 16 deletions(-)
drivers/firmware/efi/fake_mem.c +16 -15
@@ -34,25 +34,16 @@ static int __init cmp_fake_mem(const void *x1, const void *x2)return 0 ; } -void __init efi_fake_memmap (void ) +static void __init efi_fake_range (struct efi_mem_range *efi_range) {struct efi_memory_map_data data = {0 };int new_nr_map = efi.memmap.nr_map;efi_memory_desc_t *md;void *new_memmap; -int i; - -if (!efi_enabled (EFI_MEMMAP ) || !nr_fake_mem) -return ;/* count up the number of EFI memory descriptor */ -for (i =0 ; i < nr_fake_mem; i++) { -for_each_efi_memory_desc (md) { -struct range *r = &efi_fake_mems[i].range; - - new_nr_map +=efi_memmap_split_count (md, r); - } - } +for_each_efi_memory_desc (md) + new_nr_map +=efi_memmap_split_count (md, &efi_range->range);/* allocate memory for new EFI memmap */ if (efi_memmap_alloc (new_nr_map, &data) !=0 )
@@ -61,17 +52,27 @@ void __init efi_fake_memmap(void)/* create new EFI memmap */ new_memmap =early_memremap (data.phys_map, data.size);if (!new_memmap) { -memblock_free (data.phys_map, data.size); +__efi_memmap_free (data.phys_map, data.size, data.flags);return ; } -for (i =0 ; i < nr_fake_mem; i++) -efi_memmap_insert (&efi.memmap, new_memmap, &efi_fake_mems[i]); +efi_memmap_insert (&efi.memmap, new_memmap, efi_range);/* swap into new EFI memmap */ early_memunmap (new_memmap, data.size);efi_memmap_install (&data); +} + +void __init efi_fake_memmap (void ) +{ +int i; + +if (!efi_enabled (EFI_MEMMAP ) || !nr_fake_mem) +return ; + +for (i =0 ; i < nr_fake_mem; i++) +efi_fake_range (&efi_fake_mems[i]);/* print new EFI memmap */ efi_print_memmap ();
drivers/firmware/efi/memmap.c +1 -1
@@ -29,7 +29,7 @@ static phys_addr_t __init __efi_memmap_alloc_late(unsigned long size)return PFN_PHYS (page_to_pfn (p)); } -static void __init __efi_memmap_free (u64 phys,unsigned long size,unsigned long flags) +void __init __efi_memmap_free (u64 phys,unsigned long size,unsigned long flags) {if (flags &EFI_MEMMAP_MEMBLOCK ) {if (slab_is_available ())
include/linux/efi.h +2 -0
@@ -976,6 +976,8 @@ extern void __iomem *efi_lookup_mapped_addr(u64 phys_addr);extern int __init efi_memmap_alloc (unsigned int num_entries,struct efi_memory_map_data *data); +extern void __efi_memmap_free (u64 phys,unsigned long size, +unsigned long flags);extern int __init efi_memmap_init_early (struct efi_memory_map_data *data);extern int __init efi_memmap_init_late (phys_addr_t addr,unsigned long size);extern void __init efi_memmap_unmap (void );
Signature · 1 line
2.20.1
Quoted 55 lines · Ard Biesheuvel
The following changes since commit
4444f8541dad16fefd9b8807ad1451e806ef1d94:efi: Allow disabling PCI busmastering on bridges during boot (2020-01-10 18:55:04 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.gittags/efi-nextfor you to fetch changes up to
743c5dd59f7e4b9e7a28be6a8f0e8d03271a98ab:efi: Fix handling of multiple efi_fake_mem= entries (2020-01-13 10:41:53 +0100)
----------------------------------------------------------------
Third and final batch of EFI updates for v5.6:
- A few touchups for the x86 libstub changes that have already been queued up.
- Fix memory leaks and crash bugs in the EFIfake_memdriver, which may be used more heavily in the future for device-dax soft reservation (Dan)
- Avoid RWX mappings in the EFI page tables when possible.
- Avoid PCIe probing failures if the EFI framebuffer is probed first when the newof_devlinkfeature is active.
- Move the support code for the old EFI memory mapping style into its only user, the SGI UV1+ support code.----------------------------------------------------------------
Anshuman Khandual (1):
efi: Fix comment forefi_mem_type()wrt absent physical addressesArd Biesheuvel (7):
efi/libstub/x86: use const attribute forefi_is_64bit()efi/libstub/x86: use mandatory 16-byte stack alignment in mixed mode x86/mm: fix NX bit clearing issue inkernel_map_pages_in_pgdefi/x86: don't map the entire kernel text RW for mixed mode efi/x86: avoid RWX mappings for all of DRAM
efi/x86: limit EFI old memory map to SGI UV machines efi/arm: defer probe of PCIe backed efifb on DT systemsArnd Bergmann (1):
efi/libstub/x86: fix unused-variable warningDan Williams (4):
efi: Add a flags parameter toefi_memory_map
efi: Add tracking for dynamically allocated memmaps
efi: Fixefi_memmap_alloc()leaks
efi: Fix handling of multiple efi_fake_mem= entriesDocumentation/admin-guide/kernel-parameters.txt | 3 +- arch/x86/boot/compressed/eboot.c | 16 +- arch/x86/boot/compressed/efi_thunk_64.S | 46 ++---- arch/x86/boot/compressed/head_64.S | 7 +- arch/x86/include/asm/efi.h | 28 ++-- arch/x86/kernel/kexec-bzimage64.c | 2 +- arch/x86/mm/pat/set_memory.c | 8 +- arch/x86/platform/efi/efi.c | 40 +++-- arch/x86/platform/efi/efi_64.c | 190 ++++--------------------
Quoted 8 lines
arch/x86/platform/efi/quirks.c | 44 +++--- arch/x86/platform/uv/bios_uv.c | 164 +++++++++++++++++++- drivers/firmware/efi/arm-init.c | 107 ++++++++++++- drivers/firmware/efi/efi.c | 2 +- drivers/firmware/efi/fake_mem.c | 43 +++--- drivers/firmware/efi/memmap.c | 95 ++++++++---- include/linux/efi.h | 17 ++- 16 files changed, 471 insertions(+), 341 deletions(-)
Thanks Ard, I've applied these and the 3 fixes in the second series to tip:efi/core. It all merged nicely and looks good here. Let me know if there's anything amiss.
Thanks,
Ingo
Quoted 68 lines · Ingo Molnar
Quoted 55 lines · Ard Biesheuvel
The following changes since commit
4444f8541dad16fefd9b8807ad1451e806ef1d94:efi: Allow disabling PCI busmastering on bridges during boot (2020-01-10 18:55:04 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.gittags/efi-nextfor you to fetch changes up to
743c5dd59f7e4b9e7a28be6a8f0e8d03271a98ab:efi: Fix handling of multiple efi_fake_mem= entries (2020-01-13 10:41:53 +0100)
----------------------------------------------------------------
Third and final batch of EFI updates for v5.6:
- A few touchups for the x86 libstub changes that have already been queued up.
- Fix memory leaks and crash bugs in the EFIfake_memdriver, which may be used more heavily in the future for device-dax soft reservation (Dan)
- Avoid RWX mappings in the EFI page tables when possible.
- Avoid PCIe probing failures if the EFI framebuffer is probed first when the newof_devlinkfeature is active.
- Move the support code for the old EFI memory mapping style into its only user, the SGI UV1+ support code.----------------------------------------------------------------
Anshuman Khandual (1):
efi: Fix comment forefi_mem_type()wrt absent physical addressesArd Biesheuvel (7):
efi/libstub/x86: use const attribute forefi_is_64bit()efi/libstub/x86: use mandatory 16-byte stack alignment in mixed mode x86/mm: fix NX bit clearing issue inkernel_map_pages_in_pgdefi/x86: don't map the entire kernel text RW for mixed mode efi/x86: avoid RWX mappings for all of DRAM
efi/x86: limit EFI old memory map to SGI UV machines efi/arm: defer probe of PCIe backed efifb on DT systemsArnd Bergmann (1):
efi/libstub/x86: fix unused-variable warningDan Williams (4):
efi: Add a flags parameter toefi_memory_map
efi: Add tracking for dynamically allocated memmaps
efi: Fixefi_memmap_alloc()leaks
efi: Fix handling of multiple efi_fake_mem= entriesDocumentation/admin-guide/kernel-parameters.txt | 3 +- arch/x86/boot/compressed/eboot.c | 16 +- arch/x86/boot/compressed/efi_thunk_64.S | 46 ++---- arch/x86/boot/compressed/head_64.S | 7 +- arch/x86/include/asm/efi.h | 28 ++-- arch/x86/kernel/kexec-bzimage64.c | 2 +- arch/x86/mm/pat/set_memory.c | 8 +- arch/x86/platform/efi/efi.c | 40 +++-- arch/x86/platform/efi/efi_64.c | 190 ++++--------------------Quoted 8 lines
arch/x86/platform/efi/quirks.c | 44 +++--- arch/x86/platform/uv/bios_uv.c | 164 +++++++++++++++++++- drivers/firmware/efi/arm-init.c | 107 ++++++++++++- drivers/firmware/efi/efi.c | 2 +- drivers/firmware/efi/fake_mem.c | 43 +++--- drivers/firmware/efi/memmap.c | 95 ++++++++---- include/linux/efi.h | 17 ++- 16 files changed, 471 insertions(+), 341 deletions(-)
Quoted 4 lines
Thanks Ard, I've applied these and the 3 fixes in the second series to tip:efi/core. It all merged nicely and looks good here. Let me know if there's anything amiss.
Thanks Ingo,
Apart from the mismatched parens in the commit log of the top commit, everything looks fine.
It does appear that the KASAN fix is not 100% sufficient for mixed mode, so I'll need to apply another fix on top there, but we may have other things to fix during the cycle so I'll leave that for later.
Quoted 8 lines · Ard Biesheuvel
Quoted 3 lines
Thanks Ard, I've applied these and the 3 fixes in the second series to tip:efi/core. It all merged nicely and looks good here. Let me know if there's anything amiss.
Thanks Ingo,
Apart from the mismatched parens in the commit log of the top commit, everything looks fine.
Indeed - and since it was the top commit I amended it, and while at it I fixed not just the parenthesis error I introduced, but added the right SHA1 as well:
efi/x86: Disallow efi=old_map in mixed mode
Before:
1f299fad1e31: ("efi/x86: Limit EFI old memory map to SGI UV machines")
enabling the old EFI memory map on mixed mode systems disabled EFI runtime services altogether.
Quoted 3 lines
It does appear that the KASAN fix is not 100% sufficient for mixed mode, so I'll need to apply another fix on top there, but we may have other things to fix during the cycle so I'll leave that for later.
Sounds good!
Thanks,
Ingo