Re: [PATCH] x86/efi: update e820 about reserved EFI boot services data to fix kexec breakage
Hi Dan, [snip] > I reproduced some other panics with or without my fix about the efi boot > mem, but not 100% reproducible although high likely. I'm using params > below: > efi_fake_mem=200M@5G:0x4,300M@5600M:0x4 > > I suspect efi_fake_mem needs more careful sanity checks about the memory > user provided, but I'm not very familiar with the details though.. > > The issues I notices are two different ones: > First one is a panic during booting: > [0.210239] mem auto-init: stack:off, heap alloc:off, heap free:off > [0.215983] BUG: kernel NULL pointer dereference, address: 0008 > [0.216835] #PF: supervisor write access in kernel mode > [0.217384] #PF: error_code(0x0002) - not-present page > [0.217976] PGD 0 P4D 0 > [0.218248] Oops: 0002 [#1] SMP PTI > [0.218668] CPU: 0 PID: 0 Comm: swapper Not tainted 5.5.0-rc3+ #3 > [0.219315] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 > 02/06/2015 > [0.220191] RIP: 0010:__free_pages_ok+0x2de/0x5c0 > [0.220690] Code: 00 00 4b 8d 04 a4 48 c1 e5 04 48 c1 e0 08 48 89 c1 48 01 > c5 4b 8d 04 c0 48 c1 e0 03 48 01 c5 48 01 c8 49 8b b4 2e c0 00 00 00 <48> 89 > 7e 08 48 89 73 08 48 89 53 10 48 89 3a 49 83 84 06 00 01 00 > [0.222843] RSP: :97e03e60 EFLAGS: 00010002 > [0.223400] RAX: 07d0 RBX: da4d0005 RCX: > 0500 > [0.224200] RDX: a2a9bd3fe900 RSI: RDI: > da4d00050008 > [0.224984] RBP: 0840 R08: 000a R09: > 0400 > [0.225825] R10: dead0100 R11: 0039 R12: > 0001 > [0.226793] R13: a2a9bd3fe500 R14: a2a9bd3fe000 R15: > 000a > [0.227764] FS: () GS:a2a9b760() > knlGS: > [0.228799] CS: 0010 DS: ES: CR0: 80050033 > [0.229511] CR2: 0008 CR3: 0001cf80a001 CR4: > 000606b0 > [0.230323] DR0: DR1: DR2: > > [0.231399] DR3: DR6: fffe0ff0 DR7: > 0400 > [0.232219] Call Trace: > [0.232524] memblock_free_all+0x127/0x195 > [0.233090] mem_init+0x15/0x9d > [0.233450] start_kernel+0x215/0x4e0 > [0.233875] ? load_ucode_bsp+0x3e/0x11b > [0.234325] secondary_startup_64+0xa4/0xb0 > [0.234833] Modules linked in: > [0.235197] CR2: 0008 > [0.235610] random: get_random_bytes called from > print_oops_end_marker+0x26/0x40 with crng_init=0 > [0.237389] ---[ end trace 58f36740c65a5535 ]--- > [0.238111] RIP: 0010:__free_pages_ok+0x2de/0x5c0 > [0.238747] Code: 00 00 4b 8d 04 a4 48 c1 e5 04 48 c1 e0 08 48 89 c1 48 01 > c5 4b 8d 04 c0 48 c1 e0 03 48 01 c5 48 01 c8 49 8b b4 2e c0 00 00 00 <48> 89 > 7e 08 48 89 73 08 48 89 53 10 48 89 3a 49 83 84 06 00 01 00 > [0.241001] RSP: :97e03e60 EFLAGS: 00010002 > [0.241618] RAX: 07d0 RBX: da4d0005 RCX: > 0500 > [0.242461] RDX: a2a9bd3fe900 RSI: RDI: > da4d00050008 > [0.243308] RBP: 0840 R08: 000a R09: > 0400 > [0.244161] R10: dead0100 R11: 0039 R12: > 0001 > [0.245093] R13: a2a9bd3fe500 R14: a2a9bd3fe000 R15: > 000a > [0.245995] FS: () GS:a2a9b760() > knlGS: > [0.246972] CS: 0010 DS: ES: CR0: 80050033 > [0.247863] CR2: 0008 CR3: 0001cf80a001 CR4: > 000606b0 > [0.248950] DR0: DR1: DR2: > > [0.249978] DR3: DR6: fffe0ff0 DR7: > 0400 > [0.250976] Kernel panic - not syncing: Attempted to kill the idle task! > [0.251915] Rebooting in 10 seconds.. > > The second one is when reading some files after login, eg. cat > /proc/iomem: > > [ 51.732899] BUG: unable to handle page fault for address: 7cfa9028 > [ 51.736351] #PF: supervisor read access in kernel mode > [ 51.737549] #PF: error_code(0x) - not-present page > [ 51.738645] PGD 0 P4D 0 > [ 51.738929] Oops: [#1] SMP PTI > [ 51.739290] CPU: 1 PID: 467 Comm: cat Not tainted 5.5.0-rc3+ #3 > [ 51.740040] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 > 02/06/2015 > [ 51.741084] RIP: 0010:r_show+0x33/0xc0 > [ 51.741591] Code: fd 41 54 55 53 48 8b 47 70 48 89 f3 48 8b 78 20 e8 c2 1f > 1d 00 48 89 da 48 81 78 08 00 00 01 00 19 ed 31 c9 83 e5 fc 83 c5 08 <48> 8b > 52 28 48 39 c2 74 73 83 c1 01 83 f9 05 75 ef 41 bc 0a 00 00 > [ 51.743884] RSP: 0018:9a983145be30 EFLAGS: 00010202 > [ 51.744538] RAX: 94632c00 RBX: 7cfa9000 RCX: > > [ 51.745359] RDX: 7cfa9000 RSI: 7cfa9000 RDI: > 9a9828138048 > [ 51.746363]
Re: [PATCH] x86/efi: update e820 about reserved EFI boot services data to fix kexec breakage
On 12/29/19 at 10:24pm, Dave Young wrote: > Hi Dan, > On 12/28/19 at 10:13pm, Dan Williams wrote: > > On Sat, Dec 28, 2019 at 12:54 PM Dan Williams > > wrote: > > > > > > On Tue, Dec 3, 2019 at 11:53 PM Dave Young wrote: > > > > > > > > Michael Weiser reported he got below error during a kexec rebooting: > > > > esrt: Unsupported ESRT version 2904149718861218184. > > > > > > > > The ESRT memory stays in EFI boot services data, and it was reserved > > > > in kernel via efi_mem_reserve(). The initial purpose of the reservation > > > > is to reuse the EFI boot services data across kexec reboot. For example > > > > the BGRT image data and some ESRT memory like Michael reported. > > > > > > > > But although the memory is reserved it is not updated in X86 e820 table. > > > > And kexec_file_load iterate system ram in io resource list to find > > > > places > > > > for kernel, initramfs and other stuff. In Michael's case the kexec > > > > loaded > > > > initramfs overwritten the ESRT memory and then the failure happened. > > > > > > > > Since kexec_file_load depends on the e820 to be updated, just fix this > > > > by updating the reserved EFI boot services memory as reserved type in > > > > e820. > > > > > > > > Originally any memory descriptors with EFI_MEMORY_RUNTIME attribute are > > > > bypassed in the reservation code path because they are assumed as > > > > reserved. > > > > But the reservation is still needed for multiple kexec reboot. > > > > And it is the only possible case we come here thus just drop the code > > > > chunk then everything works without side effects. > > > > > > > > On my machine the ESRT memory sits in an EFI runtime data range, it does > > > > not trigger the problem, but I successfully tested with BGRT instead. > > > > both kexec_load and kexec_file_load work and kdump works as well. > > > > > > > > Signed-off-by: Dave Young > > > > --- > > > > arch/x86/platform/efi/quirks.c |6 ++ > > > > 1 file changed, 2 insertions(+), 4 deletions(-) > > > > > > > > --- linux-x86.orig/arch/x86/platform/efi/quirks.c > > > > +++ linux-x86/arch/x86/platform/efi/quirks.c > > > > @@ -260,10 +260,6 @@ void __init efi_arch_mem_reserve(phys_ad > > > > return; > > > > } > > > > > > > > - /* No need to reserve regions that will never be freed. */ > > > > - if (md.attribute & EFI_MEMORY_RUNTIME) > > > > - return; > > > > - > > > > size += addr % EFI_PAGE_SIZE; > > > > size = round_up(size, EFI_PAGE_SIZE); > > > > addr = round_down(addr, EFI_PAGE_SIZE); > > > > @@ -293,6 +289,8 @@ void __init efi_arch_mem_reserve(phys_ad > > > > early_memunmap(new, new_size); > > > > > > > > efi_memmap_install(new_phys, num_entries); > > > > + e820__range_update(addr, size, E820_TYPE_RAM, > > > > E820_TYPE_RESERVED); > > > > + e820__update_table(e820_table); > > > > } > > > > > > > > /* > > > > > > > > > > Bisect says this change (commit af1648984828) is triggering a > > > regression, likely not urgent, in my testing of the new efi_fake_mem= > > > facility to allow memory to be marked "soft reserved" via the kernel > > > command line (commit 199c84717612 x86/efi: Add efi_fake_mem support > > > for EFI_MEMORY_SP). The following command line triggers the crash > > > signature below: > > > > > > efi_fake_mem=4G@9G:0x4,4G@13G:0x4 > > > > > > However, this command line works ok: > > > > > > efi_fake_mem=8G@9G:0x4 > > > > > > So, something about multiple efi_fake_mem statements interacts badly > > > with this change. Nothing obvious occurs to me at the moment, I'll > > > keep debugging, but wanted to highlight this in the meantime in case > > > someone else sees a deeper issue or the root cause. > > > > Still looking, but this failure does not seem to be specific to the > > "soft reservation" changes. Any update to the efi memmap that pushes > > it over a page boundary triggers this failure. I.e. I can fix the > > problem by over-allocating the efi memmap and then page aligning the > > result. __early_ioremap "should" be handling this case, but it appears > > something else is messing this up. > > I seems can not reproduce the bug, but maybe my vm setup is different. > Can you do some debugging about the efi_memmap_insert function see if > something wrong happened, maybe happens when memcpy to some new allocated > buffer via > memblock_alloc, just some guess. I reproduced some other panics with or without my fix about the efi boot mem, but not 100% reproducible although high likely. I'm using params below: efi_fake_mem=200M@5G:0x4,300M@5600M:0x4 I suspect efi_fake_mem needs more careful sanity checks about the memory user provided, but I'm not very familiar with the details though.. The issues I notices are two different ones: First one is a panic during booting: [0.210239] mem auto-init: stack:off, heap alloc:off, heap free:off [0.215983] BUG: kernel NULL pointer
Greetings
Dear Sir/Madam, I have investor that want to invest $6.8 Billion into a company that needs fund for expansion only.He can not invest the money to new Companies that want to start up but into Companies that has been making good profits but needs funds for EXPANSION. He can only invest in start up if the investment proposal is realistic. The investor is a former Petroleum Minister. His Area of concentrations are Real Estate, Biotech,Textiles , Information technology, Pharmaceuticals , Oil & Energy Industries, Mining Industry, Management Consulting Industry ,Maritime industry, Hospital & Health Care Industry, Consumer Services Industry, International Trade and Development Industry ,Gambling & Casinos Industry, Electrical/Electronic Manufacturing Industry, Insurance Industry, Chemical industries, Marketing and Advertising Industry, Leisure, Travel & Tourism Industry, Agriculture, Aviation, Retail, Import and Export, Trade and development industry, Real Estate & Construction Industry and any other viable investment opportunities. If you recommend a Company to take loan or investment funds from from my client the investor, me and you will be entitled to 5% of any amount received by the Company from the investor but if you are taking the fund directly as a company i will be entitled to 2.5% and you will retain 2.5% as Global Finder's fee commission. There will be a face to face meeting between the investor and the investee after signing (MOU) the (AORI) should not be less than 3% per annul if it's loan or direct project financing. Look for a reliable Company that need funding and we can easily make 5% of the amount received from the investor but we need to maintain absolute confidentiality in the transaction as the fund provider want to remain silent, so you have to keep it highly confidential between us. I will need the company profile and the project summary of the company that will need funding to present to my investor. I look forward to hearing from you. Mr. Moon David. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 5.4 302/434] x86/crash: Add a forward declaration of struct kimage
From: Lianbo Jiang [ Upstream commit 112eee5d06007dae561f14458bde7f2a4879ef4e ] Add a forward declaration of struct kimage to the crash.h header because future changes will invoke a crash-specific function from the realmode init path and the compiler will complain otherwise like this: In file included from arch/x86/realmode/init.c:11: ./arch/x86/include/asm/crash.h:5:32: warning: ‘struct kimage’ declared inside\ parameter list will not be visible outside of this definition or declaration 5 | int crash_load_segments(struct kimage *image); |^~ ./arch/x86/include/asm/crash.h:6:37: warning: ‘struct kimage’ declared inside\ parameter list will not be visible outside of this definition or declaration 6 | int crash_copy_backup_region(struct kimage *image); | ^~ ./arch/x86/include/asm/crash.h:7:39: warning: ‘struct kimage’ declared inside\ parameter list will not be visible outside of this definition or declaration 7 | int crash_setup_memmap_entries(struct kimage *image, | [ bp: Rewrite the commit message. ] Reported-by: kbuild test robot Signed-off-by: Lianbo Jiang Signed-off-by: Borislav Petkov Cc: b...@redhat.com Cc: d.hatay...@fujitsu.com Cc: dhowe...@redhat.com Cc: dyo...@redhat.com Cc: ebied...@xmission.com Cc: ho...@verge.net.au Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jürgen Gross Cc: kexec@lists.infradead.org Cc: Thomas Gleixner Cc: Tom Lendacky Cc: vgo...@redhat.com Cc: x86-ml Link: https://lkml.kernel.org/r/20191108090027.11082-4-liji...@redhat.com Link: https://lkml.kernel.org/r/201910310233.ejrttmwp%25...@intel.com Signed-off-by: Sasha Levin --- arch/x86/include/asm/crash.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/include/asm/crash.h b/arch/x86/include/asm/crash.h index 0acf5ee45a21..ef5638f641f2 100644 --- a/arch/x86/include/asm/crash.h +++ b/arch/x86/include/asm/crash.h @@ -2,6 +2,8 @@ #ifndef _ASM_X86_CRASH_H #define _ASM_X86_CRASH_H +struct kimage; + int crash_load_segments(struct kimage *image); int crash_copy_backup_region(struct kimage *image); int crash_setup_memmap_entries(struct kimage *image, -- 2.20.1 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 4.19 159/219] x86/crash: Add a forward declaration of struct kimage
From: Lianbo Jiang [ Upstream commit 112eee5d06007dae561f14458bde7f2a4879ef4e ] Add a forward declaration of struct kimage to the crash.h header because future changes will invoke a crash-specific function from the realmode init path and the compiler will complain otherwise like this: In file included from arch/x86/realmode/init.c:11: ./arch/x86/include/asm/crash.h:5:32: warning: ‘struct kimage’ declared inside\ parameter list will not be visible outside of this definition or declaration 5 | int crash_load_segments(struct kimage *image); |^~ ./arch/x86/include/asm/crash.h:6:37: warning: ‘struct kimage’ declared inside\ parameter list will not be visible outside of this definition or declaration 6 | int crash_copy_backup_region(struct kimage *image); | ^~ ./arch/x86/include/asm/crash.h:7:39: warning: ‘struct kimage’ declared inside\ parameter list will not be visible outside of this definition or declaration 7 | int crash_setup_memmap_entries(struct kimage *image, | [ bp: Rewrite the commit message. ] Reported-by: kbuild test robot Signed-off-by: Lianbo Jiang Signed-off-by: Borislav Petkov Cc: b...@redhat.com Cc: d.hatay...@fujitsu.com Cc: dhowe...@redhat.com Cc: dyo...@redhat.com Cc: ebied...@xmission.com Cc: ho...@verge.net.au Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jürgen Gross Cc: kexec@lists.infradead.org Cc: Thomas Gleixner Cc: Tom Lendacky Cc: vgo...@redhat.com Cc: x86-ml Link: https://lkml.kernel.org/r/20191108090027.11082-4-liji...@redhat.com Link: https://lkml.kernel.org/r/201910310233.ejrttmwp%25...@intel.com Signed-off-by: Sasha Levin --- arch/x86/include/asm/crash.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/include/asm/crash.h b/arch/x86/include/asm/crash.h index a7adb2bfbf0b..6b8ad6fa3979 100644 --- a/arch/x86/include/asm/crash.h +++ b/arch/x86/include/asm/crash.h @@ -2,6 +2,8 @@ #ifndef _ASM_X86_CRASH_H #define _ASM_X86_CRASH_H +struct kimage; + int crash_load_segments(struct kimage *image); int crash_copy_backup_region(struct kimage *image); int crash_setup_memmap_entries(struct kimage *image, -- 2.20.1 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 4.14 118/161] x86/crash: Add a forward declaration of struct kimage
From: Lianbo Jiang [ Upstream commit 112eee5d06007dae561f14458bde7f2a4879ef4e ] Add a forward declaration of struct kimage to the crash.h header because future changes will invoke a crash-specific function from the realmode init path and the compiler will complain otherwise like this: In file included from arch/x86/realmode/init.c:11: ./arch/x86/include/asm/crash.h:5:32: warning: ‘struct kimage’ declared inside\ parameter list will not be visible outside of this definition or declaration 5 | int crash_load_segments(struct kimage *image); |^~ ./arch/x86/include/asm/crash.h:6:37: warning: ‘struct kimage’ declared inside\ parameter list will not be visible outside of this definition or declaration 6 | int crash_copy_backup_region(struct kimage *image); | ^~ ./arch/x86/include/asm/crash.h:7:39: warning: ‘struct kimage’ declared inside\ parameter list will not be visible outside of this definition or declaration 7 | int crash_setup_memmap_entries(struct kimage *image, | [ bp: Rewrite the commit message. ] Reported-by: kbuild test robot Signed-off-by: Lianbo Jiang Signed-off-by: Borislav Petkov Cc: b...@redhat.com Cc: d.hatay...@fujitsu.com Cc: dhowe...@redhat.com Cc: dyo...@redhat.com Cc: ebied...@xmission.com Cc: ho...@verge.net.au Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jürgen Gross Cc: kexec@lists.infradead.org Cc: Thomas Gleixner Cc: Tom Lendacky Cc: vgo...@redhat.com Cc: x86-ml Link: https://lkml.kernel.org/r/20191108090027.11082-4-liji...@redhat.com Link: https://lkml.kernel.org/r/201910310233.ejrttmwp%25...@intel.com Signed-off-by: Sasha Levin --- arch/x86/include/asm/crash.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/include/asm/crash.h b/arch/x86/include/asm/crash.h index a7adb2bfbf0b..6b8ad6fa3979 100644 --- a/arch/x86/include/asm/crash.h +++ b/arch/x86/include/asm/crash.h @@ -2,6 +2,8 @@ #ifndef _ASM_X86_CRASH_H #define _ASM_X86_CRASH_H +struct kimage; + int crash_load_segments(struct kimage *image); int crash_copy_backup_region(struct kimage *image); int crash_setup_memmap_entries(struct kimage *image, -- 2.20.1 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] x86/efi: update e820 about reserved EFI boot services data to fix kexec breakage
Hi Dan, On 12/28/19 at 10:13pm, Dan Williams wrote: > On Sat, Dec 28, 2019 at 12:54 PM Dan Williams > wrote: > > > > On Tue, Dec 3, 2019 at 11:53 PM Dave Young wrote: > > > > > > Michael Weiser reported he got below error during a kexec rebooting: > > > esrt: Unsupported ESRT version 2904149718861218184. > > > > > > The ESRT memory stays in EFI boot services data, and it was reserved > > > in kernel via efi_mem_reserve(). The initial purpose of the reservation > > > is to reuse the EFI boot services data across kexec reboot. For example > > > the BGRT image data and some ESRT memory like Michael reported. > > > > > > But although the memory is reserved it is not updated in X86 e820 table. > > > And kexec_file_load iterate system ram in io resource list to find places > > > for kernel, initramfs and other stuff. In Michael's case the kexec loaded > > > initramfs overwritten the ESRT memory and then the failure happened. > > > > > > Since kexec_file_load depends on the e820 to be updated, just fix this > > > by updating the reserved EFI boot services memory as reserved type in > > > e820. > > > > > > Originally any memory descriptors with EFI_MEMORY_RUNTIME attribute are > > > bypassed in the reservation code path because they are assumed as > > > reserved. > > > But the reservation is still needed for multiple kexec reboot. > > > And it is the only possible case we come here thus just drop the code > > > chunk then everything works without side effects. > > > > > > On my machine the ESRT memory sits in an EFI runtime data range, it does > > > not trigger the problem, but I successfully tested with BGRT instead. > > > both kexec_load and kexec_file_load work and kdump works as well. > > > > > > Signed-off-by: Dave Young > > > --- > > > arch/x86/platform/efi/quirks.c |6 ++ > > > 1 file changed, 2 insertions(+), 4 deletions(-) > > > > > > --- linux-x86.orig/arch/x86/platform/efi/quirks.c > > > +++ linux-x86/arch/x86/platform/efi/quirks.c > > > @@ -260,10 +260,6 @@ void __init efi_arch_mem_reserve(phys_ad > > > return; > > > } > > > > > > - /* No need to reserve regions that will never be freed. */ > > > - if (md.attribute & EFI_MEMORY_RUNTIME) > > > - return; > > > - > > > size += addr % EFI_PAGE_SIZE; > > > size = round_up(size, EFI_PAGE_SIZE); > > > addr = round_down(addr, EFI_PAGE_SIZE); > > > @@ -293,6 +289,8 @@ void __init efi_arch_mem_reserve(phys_ad > > > early_memunmap(new, new_size); > > > > > > efi_memmap_install(new_phys, num_entries); > > > + e820__range_update(addr, size, E820_TYPE_RAM, E820_TYPE_RESERVED); > > > + e820__update_table(e820_table); > > > } > > > > > > /* > > > > > > > Bisect says this change (commit af1648984828) is triggering a > > regression, likely not urgent, in my testing of the new efi_fake_mem= > > facility to allow memory to be marked "soft reserved" via the kernel > > command line (commit 199c84717612 x86/efi: Add efi_fake_mem support > > for EFI_MEMORY_SP). The following command line triggers the crash > > signature below: > > > > efi_fake_mem=4G@9G:0x4,4G@13G:0x4 > > > > However, this command line works ok: > > > > efi_fake_mem=8G@9G:0x4 > > > > So, something about multiple efi_fake_mem statements interacts badly > > with this change. Nothing obvious occurs to me at the moment, I'll > > keep debugging, but wanted to highlight this in the meantime in case > > someone else sees a deeper issue or the root cause. > > Still looking, but this failure does not seem to be specific to the > "soft reservation" changes. Any update to the efi memmap that pushes > it over a page boundary triggers this failure. I.e. I can fix the > problem by over-allocating the efi memmap and then page aligning the > result. __early_ioremap "should" be handling this case, but it appears > something else is messing this up. I seems can not reproduce the bug, but maybe my vm setup is different. Can you do some debugging about the efi_memmap_insert function see if something wrong happened, maybe happens when memcpy to some new allocated buffer via memblock_alloc, just some guess. Thanks Dave ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
