* [PATCH v3 0/2] x86: SME: Kexec/kdump memory loading fix @ 2019-06-19 18:40 Lendacky, Thomas 2019-06-19 18:40 ` [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved Lendacky, Thomas 2019-06-19 18:40 ` [PATCH v3 2/2] x86/mm: Create a workarea in the kernel for SME early encryption Lendacky, Thomas 0 siblings, 2 replies; 32+ messages in thread From: Lendacky, Thomas @ 2019-06-19 18:40 UTC (permalink / raw) To: linux-kernel, x86 Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, Andy Lutomirski, Peter Zijlstra, Lianbo Jiang, Baoquan He This series addresses an issue related to kexec/kdump when SME is active. The SME support uses a workarea located after the end of the kernel to perform "in-place" encryption of the kernel. When kexec/kdump is used, it is possible that some other data used by kexec/kdump could be in this area of memory which would cause the kexec/kdump of the kernel to fail. Create a workarea section for use by SME in vmlinux.lds.S that is positioned after "_end", so that the memory it occupies will be reclaimed after its use during boot. Since it is part of the kernel image, there is no worry now that kexec/kdump will place data in the SME workarea when installing the kexec/kdump kernel. As part of this fix, clarify what occupied kernel memory is reserved and what parts of the kernel memory are discarded. The following patches are included: - Identify and document what parts of the kernel image are reserved (saved) and what is discarded. - Create a new section that lives outside of the kernel proper, so that it will be reclaimed as available memory during boot, thus allowing it to be used as a workarea by SME for kernel in-place encryption during early boot.. This patch series is based on tip/master. --- Changes from v2: - Grammar fixes - A more generic naming of the scratch/workarea section to indicate it is not restricted to SME usage Changes from v1: - Clarify how and where the kernel sections/memory is reserved. - Add an explicit symbol, __end_of_kernel_reserve, for reserving the kernel memory rather than using __bss_stop. Tom Lendacky (2): x86/mm: Identify the end of the kernel area to be reserved x86/mm: Create a workarea in the kernel for SME early encryption arch/x86/include/asm/sections.h | 2 ++ arch/x86/kernel/setup.c | 8 ++++++- arch/x86/kernel/vmlinux.lds.S | 34 +++++++++++++++++++++++++++++- arch/x86/mm/mem_encrypt_identity.c | 22 +++++++++++++++++-- 4 files changed, 62 insertions(+), 4 deletions(-) -- 2.17.1 ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-06-19 18:40 [PATCH v3 0/2] x86: SME: Kexec/kdump memory loading fix Lendacky, Thomas @ 2019-06-19 18:40 ` Lendacky, Thomas 2019-06-20 9:58 ` [tip:x86/kdump] " tip-bot for Thomas Lendacky 2019-07-13 14:59 ` [PATCH v3 1/2] " Mike Lothian 2019-06-19 18:40 ` [PATCH v3 2/2] x86/mm: Create a workarea in the kernel for SME early encryption Lendacky, Thomas 1 sibling, 2 replies; 32+ messages in thread From: Lendacky, Thomas @ 2019-06-19 18:40 UTC (permalink / raw) To: linux-kernel, x86 Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, Andy Lutomirski, Peter Zijlstra, Lianbo Jiang, Baoquan He The memory occupied by the kernel is reserved using memblock_reserve() in setup_arch(). Currently, the area is from symbols _text to __bss_stop. Everything after __bss_stop must be specifically reserved otherwise it is discarded. This is not clearly documented. Add a new symbol, __end_of_kernel_reserve, that more readily identifies what is reserved, along with comments that indicate what is reserved, what is discarded and what needs to be done to prevent a section from being discarded. Tested-by: Lianbo Jiang <lijiang@redhat.com> Reviewed-by: Baoquan He <bhe@redhat.com> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> --- arch/x86/include/asm/sections.h | 2 ++ arch/x86/kernel/setup.c | 8 +++++++- arch/x86/kernel/vmlinux.lds.S | 9 ++++++++- 3 files changed, 17 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/sections.h b/arch/x86/include/asm/sections.h index 8ea1cfdbeabc..71b32f2570ab 100644 --- a/arch/x86/include/asm/sections.h +++ b/arch/x86/include/asm/sections.h @@ -13,4 +13,6 @@ extern char __end_rodata_aligned[]; extern char __end_rodata_hpage_align[]; #endif +extern char __end_of_kernel_reserve[]; + #endif /* _ASM_X86_SECTIONS_H */ diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 08a5f4a131f5..fe0f6ebefeb7 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -827,8 +827,14 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p) void __init setup_arch(char **cmdline_p) { + /* + * Reserve the memory occupied by the kernel between _text and + * __end_of_kernel_reserve symbols. Any kernel sections after the + * __end_of_kernel_reserve symbol must be explicity reserved with a + * separate memblock_reserve() or they will be discarded. + */ memblock_reserve(__pa_symbol(_text), - (unsigned long)__bss_stop - (unsigned long)_text); + (unsigned long)__end_of_kernel_reserve - (unsigned long)_text); /* * Make sure page 0 is always reserved because on systems with diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S index 0850b5149345..ca2252ca6ad7 100644 --- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -368,6 +368,14 @@ SECTIONS __bss_stop = .; } + /* + * The memory occupied from _text to here, __end_of_kernel_reserve, is + * automatically reserved in setup_arch(). Anything after here must be + * explicitly reserved using memblock_reserve() or it will be discarded + * and treated as available memory. + */ + __end_of_kernel_reserve = .; + . = ALIGN(PAGE_SIZE); .brk : AT(ADDR(.brk) - LOAD_OFFSET) { __brk_base = .; @@ -382,7 +390,6 @@ SECTIONS STABS_DEBUG DWARF_DEBUG - /* Sections to be discarded */ DISCARDS /DISCARD/ : { *(.eh_frame) -- 2.17.1 ^ permalink raw reply related [flat|nested] 32+ messages in thread
* [tip:x86/kdump] x86/mm: Identify the end of the kernel area to be reserved 2019-06-19 18:40 ` [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved Lendacky, Thomas @ 2019-06-20 9:58 ` tip-bot for Thomas Lendacky 2019-07-13 14:59 ` [PATCH v3 1/2] " Mike Lothian 1 sibling, 0 replies; 32+ messages in thread From: tip-bot for Thomas Lendacky @ 2019-06-20 9:58 UTC (permalink / raw) To: linux-tip-commits Cc: dave.hansen, keescook, ndesaulniers, luto, samitolvanen, mingo, dyoung, x86, Thomas.Lendacky, hpa, brijesh.singh, okaya, jgross, linux-kernel, mingo, lijiang, rrichter, pasha.tatashin, peterz, bp, jroedel, bhe, tglx, thomas.lendacky Commit-ID: c603a309cc75f3dd018ddb20ee44c05047918cbf Gitweb: https://git.kernel.org/tip/c603a309cc75f3dd018ddb20ee44c05047918cbf Author: Thomas Lendacky <Thomas.Lendacky@amd.com> AuthorDate: Wed, 19 Jun 2019 18:40:57 +0000 Committer: Borislav Petkov <bp@suse.de> CommitDate: Thu, 20 Jun 2019 09:22:47 +0200 x86/mm: Identify the end of the kernel area to be reserved The memory occupied by the kernel is reserved using memblock_reserve() in setup_arch(). Currently, the area is from symbols _text to __bss_stop. Everything after __bss_stop must be specifically reserved otherwise it is discarded. This is not clearly documented. Add a new symbol, __end_of_kernel_reserve, that more readily identifies what is reserved, along with comments that indicate what is reserved, what is discarded and what needs to be done to prevent a section from being discarded. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Baoquan He <bhe@redhat.com> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Tested-by: Lianbo Jiang <lijiang@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Dave Young <dyoung@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Joerg Roedel <jroedel@suse.de> Cc: Juergen Gross <jgross@suse.com> Cc: Kees Cook <keescook@chromium.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Pavel Tatashin <pasha.tatashin@oracle.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Robert Richter <rrichter@marvell.com> Cc: Sami Tolvanen <samitolvanen@google.com> Cc: Sinan Kaya <okaya@codeaurora.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "x86@kernel.org" <x86@kernel.org> Link: https://lkml.kernel.org/r/7db7da45b435f8477f25e66f292631ff766a844c.1560969363.git.thomas.lendacky@amd.com --- arch/x86/include/asm/sections.h | 2 ++ arch/x86/kernel/setup.c | 8 +++++++- arch/x86/kernel/vmlinux.lds.S | 9 ++++++++- 3 files changed, 17 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/sections.h b/arch/x86/include/asm/sections.h index 8ea1cfdbeabc..71b32f2570ab 100644 --- a/arch/x86/include/asm/sections.h +++ b/arch/x86/include/asm/sections.h @@ -13,4 +13,6 @@ extern char __end_rodata_aligned[]; extern char __end_rodata_hpage_align[]; #endif +extern char __end_of_kernel_reserve[]; + #endif /* _ASM_X86_SECTIONS_H */ diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 08a5f4a131f5..dac60ad37e5e 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -827,8 +827,14 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p) void __init setup_arch(char **cmdline_p) { + /* + * Reserve the memory occupied by the kernel between _text and + * __end_of_kernel_reserve symbols. Any kernel sections after the + * __end_of_kernel_reserve symbol must be explicitly reserved with a + * separate memblock_reserve() or they will be discarded. + */ memblock_reserve(__pa_symbol(_text), - (unsigned long)__bss_stop - (unsigned long)_text); + (unsigned long)__end_of_kernel_reserve - (unsigned long)_text); /* * Make sure page 0 is always reserved because on systems with diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S index 0850b5149345..ca2252ca6ad7 100644 --- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -368,6 +368,14 @@ SECTIONS __bss_stop = .; } + /* + * The memory occupied from _text to here, __end_of_kernel_reserve, is + * automatically reserved in setup_arch(). Anything after here must be + * explicitly reserved using memblock_reserve() or it will be discarded + * and treated as available memory. + */ + __end_of_kernel_reserve = .; + . = ALIGN(PAGE_SIZE); .brk : AT(ADDR(.brk) - LOAD_OFFSET) { __brk_base = .; @@ -382,7 +390,6 @@ SECTIONS STABS_DEBUG DWARF_DEBUG - /* Sections to be discarded */ DISCARDS /DISCARD/ : { *(.eh_frame) ^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-06-19 18:40 ` [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved Lendacky, Thomas 2019-06-20 9:58 ` [tip:x86/kdump] " tip-bot for Thomas Lendacky @ 2019-07-13 14:59 ` Mike Lothian 2019-07-14 10:16 ` Thomas Gleixner 1 sibling, 1 reply; 32+ messages in thread From: Mike Lothian @ 2019-07-13 14:59 UTC (permalink / raw) To: thomas.lendacky Cc: bhe, bp, dave.hansen, lijiang, linux-kernel, luto, mingo, peterz, tglx, x86 Hi This appears to be causing issues with gold again: axion /usr/src/linux # make CALL scripts/checksyscalls.sh CALL scripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h VDSOCHK arch/x86/entry/vdso/vdso64.so.dbg VDSOCHK arch/x86/entry/vdso/vdso32.so.dbg CHK kernel/kheaders_data.tar.xz CC arch/x86/boot/compressed/misc.o RELOCS arch/x86/boot/compressed/vmlinux.relocs Invalid absolute R_X86_64_32S relocation: __end_of_kernel_reserve make[2]: *** [arch/x86/boot/compressed/Makefile:130: arch/x86/boot/compressed/vmlinux.relocs] Error 1 make[2]: *** Deleting file 'arch/x86/boot/compressed/vmlinux.relocs' make[1]: *** [arch/x86/boot/Makefile:112: arch/x86/boot/compressed/vmlinux] Error 2 make: *** [arch/x86/Makefile:316: bzImage] Error 2 Here's the version I'm running: sys-devel/gcc-9.1.0-r1 sys-libs/glibc-2.29-r2 sys-devel/binutils-2.32-r1 Cheers Mike ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-13 14:59 ` [PATCH v3 1/2] " Mike Lothian @ 2019-07-14 10:16 ` Thomas Gleixner 2019-07-14 10:27 ` Mike Lothian 0 siblings, 1 reply; 32+ messages in thread From: Thomas Gleixner @ 2019-07-14 10:16 UTC (permalink / raw) To: Mike Lothian Cc: thomas.lendacky, bhe, bp, dave.hansen, lijiang, linux-kernel, luto, mingo, peterz, x86 On Sat, 13 Jul 2019, Mike Lothian wrote: > This appears to be causing issues with gold again: > > axion /usr/src/linux # make > CALL scripts/checksyscalls.sh > CALL scripts/atomic/check-atomics.sh > DESCEND objtool > CHK include/generated/compile.h > VDSOCHK arch/x86/entry/vdso/vdso64.so.dbg > VDSOCHK arch/x86/entry/vdso/vdso32.so.dbg > CHK kernel/kheaders_data.tar.xz > CC arch/x86/boot/compressed/misc.o > RELOCS arch/x86/boot/compressed/vmlinux.relocs > Invalid absolute R_X86_64_32S relocation: __end_of_kernel_reserve > make[2]: *** [arch/x86/boot/compressed/Makefile:130: arch/x86/boot/compressed/vmlinux.relocs] Error 1 > make[2]: *** Deleting file 'arch/x86/boot/compressed/vmlinux.relocs' > make[1]: *** [arch/x86/boot/Makefile:112: arch/x86/boot/compressed/vmlinux] Error 2 > make: *** [arch/x86/Makefile:316: bzImage] Error 2 That's fixed upstream already. Thanks, tglx ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-14 10:16 ` Thomas Gleixner @ 2019-07-14 10:27 ` Mike Lothian 2019-07-15 8:12 ` Thomas Gleixner 0 siblings, 1 reply; 32+ messages in thread From: Mike Lothian @ 2019-07-14 10:27 UTC (permalink / raw) To: Thomas Gleixner Cc: thomas.lendacky, bhe, bp, dave.hansen, lijiang, Linux Kernel Mailing List, luto, mingo, Peter Zijlstra, x86 Will the fix be in the next RC? On Sun, 14 Jul 2019 at 11:16, Thomas Gleixner <tglx@linutronix.de> wrote: > > On Sat, 13 Jul 2019, Mike Lothian wrote: > > > This appears to be causing issues with gold again: > > > > axion /usr/src/linux # make > > CALL scripts/checksyscalls.sh > > CALL scripts/atomic/check-atomics.sh > > DESCEND objtool > > CHK include/generated/compile.h > > VDSOCHK arch/x86/entry/vdso/vdso64.so.dbg > > VDSOCHK arch/x86/entry/vdso/vdso32.so.dbg > > CHK kernel/kheaders_data.tar.xz > > CC arch/x86/boot/compressed/misc.o > > RELOCS arch/x86/boot/compressed/vmlinux.relocs > > Invalid absolute R_X86_64_32S relocation: __end_of_kernel_reserve > > make[2]: *** [arch/x86/boot/compressed/Makefile:130: arch/x86/boot/compressed/vmlinux.relocs] Error 1 > > make[2]: *** Deleting file 'arch/x86/boot/compressed/vmlinux.relocs' > > make[1]: *** [arch/x86/boot/Makefile:112: arch/x86/boot/compressed/vmlinux] Error 2 > > make: *** [arch/x86/Makefile:316: bzImage] Error 2 > > That's fixed upstream already. > > Thanks, > > tglx ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-14 10:27 ` Mike Lothian @ 2019-07-15 8:12 ` Thomas Gleixner [not found] ` <CAHbf0-F9yUDJ=DKug+MZqsjW+zPgwWaLUC40BLOsr5+t4kYOLQ@mail.gmail.com> 0 siblings, 1 reply; 32+ messages in thread From: Thomas Gleixner @ 2019-07-15 8:12 UTC (permalink / raw) To: Mike Lothian Cc: thomas.lendacky, bhe, bp, dave.hansen, lijiang, Linux Kernel Mailing List, luto, mingo, Peter Zijlstra, x86 On Sun, 14 Jul 2019, Mike Lothian wrote: > Will the fix be in the next RC? As I said, it's upstream already, so yes. ^ permalink raw reply [flat|nested] 32+ messages in thread
[parent not found: <CAHbf0-F9yUDJ=DKug+MZqsjW+zPgwWaLUC40BLOsr5+t4kYOLQ@mail.gmail.com>]
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved [not found] ` <CAHbf0-F9yUDJ=DKug+MZqsjW+zPgwWaLUC40BLOsr5+t4kYOLQ@mail.gmail.com> @ 2019-07-15 9:25 ` Thomas Gleixner 2019-07-15 10:35 ` Thomas Gleixner 0 siblings, 1 reply; 32+ messages in thread From: Thomas Gleixner @ 2019-07-15 9:25 UTC (permalink / raw) To: Mike Lothian Cc: thomas.lendacky, bhe, bp, dave.hansen, lijiang, Linux Kernel Mailing List, luto, mingo, Peter Zijlstra, x86 On Mon, 15 Jul 2019, Mike Lothian wrote: A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? > That build failure is from the current tip of Linus's tree > > If the fix is in, then it hasn't fixed the issue Sorry, my bad. There was a very similar issue and I confused the two: 013c66edf207 ("Revert "x86/build: Move _etext to actual end of .text"") The reverted commit caused a build fail with gold as well. Let me stare at your issue. Thanks, tglx ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-15 9:25 ` Thomas Gleixner @ 2019-07-15 10:35 ` Thomas Gleixner 2019-07-15 20:16 ` H.J. Lu 0 siblings, 1 reply; 32+ messages in thread From: Thomas Gleixner @ 2019-07-15 10:35 UTC (permalink / raw) To: Mike Lothian Cc: thomas.lendacky, bhe, Borislav Petkov, dave.hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, mingo, Peter Zijlstra, x86, H.J. Lu On Mon, 15 Jul 2019, Thomas Gleixner wrote: > On Mon, 15 Jul 2019, Mike Lothian wrote: > > That build failure is from the current tip of Linus's tree > > If the fix is in, then it hasn't fixed the issue > > The reverted commit caused a build fail with gold as well. Let me stare at > your issue. So with gold the build fails in the reloc tool complaining about that relocation: Invalid absolute R_X86_64_32S relocation: __end_of_kernel_reserve The commit does: +extern char __end_of_kernel_reserve[]; + void __init setup_arch(char **cmdline_p) { + /* + * Reserve the memory occupied by the kernel between _text and + * __end_of_kernel_reserve symbols. Any kernel sections after the + * __end_of_kernel_reserve symbol must be explicitly reserved with a + * separate memblock_reserve() or they will be discarded. + */ memblock_reserve(__pa_symbol(_text), - (unsigned long)__bss_stop - (unsigned long)_text); + (unsigned long)__end_of_kernel_reserve - (unsigned long)_text); So it replaces __bss_stop with __end_of_kernel_reserve here. --- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -368,6 +368,14 @@ SECTIONS __bss_stop = .; } + /* + * The memory occupied from _text to here, __end_of_kernel_reserve, is + * automatically reserved in setup_arch(). Anything after here must be + * explicitly reserved using memblock_reserve() or it will be discarded + * and treated as available memory. + */ + __end_of_kernel_reserve = .; And from the linker script __bss_stop and __end_of_kernel_reserve are exactly the same. From System.map (of a successful ld build): ffffffff82c00000 B __brk_base ffffffff82c00000 B __bss_stop ffffffff82c00000 B __end_bss_decrypted ffffffff82c00000 B __end_of_kernel_reserve ffffffff82c00000 B __start_bss_decrypted ffffffff82c00000 B __start_bss_decrypted_unused So how on earth can gold fail with that __end_of_kernel_reserve change? For some unknown reason it turns that relocation into an absolute one. That's clearly a gold bug^Wfeature and TBH, I'm more than concerned about that kind of behaviour. If we just revert that commit, then what do we achieve? We paper over the underlying problem, which is not really helping anything. Aside of that gold still fails to build the X32 VDSO and it does so for a very long time.... Until we really understand what the problem is, this stays as is. @H.J.: Any insight on that? Thanks, tglx ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-15 10:35 ` Thomas Gleixner @ 2019-07-15 20:16 ` H.J. Lu 2019-07-23 13:05 ` Greg KH 0 siblings, 1 reply; 32+ messages in thread From: H.J. Lu @ 2019-07-15 20:16 UTC (permalink / raw) To: Thomas Gleixner Cc: Mike Lothian, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Mon, Jul 15, 2019 at 3:35 AM Thomas Gleixner <tglx@linutronix.de> wrote: > > On Mon, 15 Jul 2019, Thomas Gleixner wrote: > > On Mon, 15 Jul 2019, Mike Lothian wrote: > > > That build failure is from the current tip of Linus's tree > > > If the fix is in, then it hasn't fixed the issue > > > > The reverted commit caused a build fail with gold as well. Let me stare at > > your issue. > > So with gold the build fails in the reloc tool complaining about that > relocation: > > Invalid absolute R_X86_64_32S relocation: __end_of_kernel_reserve > > The commit does: > > +extern char __end_of_kernel_reserve[]; > + > > void __init setup_arch(char **cmdline_p) > { > + /* > + * Reserve the memory occupied by the kernel between _text and > + * __end_of_kernel_reserve symbols. Any kernel sections after the > + * __end_of_kernel_reserve symbol must be explicitly reserved with a > + * separate memblock_reserve() or they will be discarded. > + */ > memblock_reserve(__pa_symbol(_text), > - (unsigned long)__bss_stop - (unsigned long)_text); > + (unsigned long)__end_of_kernel_reserve - (unsigned long)_text); > > So it replaces __bss_stop with __end_of_kernel_reserve here. > > --- a/arch/x86/kernel/vmlinux.lds.S > +++ b/arch/x86/kernel/vmlinux.lds.S > @@ -368,6 +368,14 @@ SECTIONS > __bss_stop = .; > } > > + /* > + * The memory occupied from _text to here, __end_of_kernel_reserve, is > + * automatically reserved in setup_arch(). Anything after here must be > + * explicitly reserved using memblock_reserve() or it will be discarded > + * and treated as available memory. > + */ > + __end_of_kernel_reserve = .; > > And from the linker script __bss_stop and __end_of_kernel_reserve are > exactly the same. From System.map (of a successful ld build): > > ffffffff82c00000 B __brk_base > ffffffff82c00000 B __bss_stop > ffffffff82c00000 B __end_bss_decrypted > ffffffff82c00000 B __end_of_kernel_reserve > ffffffff82c00000 B __start_bss_decrypted > ffffffff82c00000 B __start_bss_decrypted_unused > > So how on earth can gold fail with that __end_of_kernel_reserve change? > > For some unknown reason it turns that relocation into an absolute > one. That's clearly a gold bug^Wfeature and TBH, I'm more than concerned > about that kind of behaviour. > > If we just revert that commit, then what do we achieve? We paper over the > underlying problem, which is not really helping anything. > > Aside of that gold still fails to build the X32 VDSO and it does so for a > very long time.... > > Until we really understand what the problem is, this stays as is. > > @H.J.: Any insight on that? > Since building a workable kernel for different kernel configurations isn't a requirement for gold, I don't recommend gold for kernel. -- H.J. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-15 20:16 ` H.J. Lu @ 2019-07-23 13:05 ` Greg KH 2019-07-23 13:31 ` Thomas Gleixner 2019-07-23 13:43 ` Greg KH 0 siblings, 2 replies; 32+ messages in thread From: Greg KH @ 2019-07-23 13:05 UTC (permalink / raw) To: H.J. Lu Cc: Thomas Gleixner, Mike Lothian, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Mon, Jul 15, 2019 at 01:16:48PM -0700, H.J. Lu wrote: > On Mon, Jul 15, 2019 at 3:35 AM Thomas Gleixner <tglx@linutronix.de> wrote: > > > > On Mon, 15 Jul 2019, Thomas Gleixner wrote: > > > On Mon, 15 Jul 2019, Mike Lothian wrote: > > > > That build failure is from the current tip of Linus's tree > > > > If the fix is in, then it hasn't fixed the issue > > > > > > The reverted commit caused a build fail with gold as well. Let me stare at > > > your issue. > > > > So with gold the build fails in the reloc tool complaining about that > > relocation: > > > > Invalid absolute R_X86_64_32S relocation: __end_of_kernel_reserve > > > > The commit does: > > > > +extern char __end_of_kernel_reserve[]; > > + > > > > void __init setup_arch(char **cmdline_p) > > { > > + /* > > + * Reserve the memory occupied by the kernel between _text and > > + * __end_of_kernel_reserve symbols. Any kernel sections after the > > + * __end_of_kernel_reserve symbol must be explicitly reserved with a > > + * separate memblock_reserve() or they will be discarded. > > + */ > > memblock_reserve(__pa_symbol(_text), > > - (unsigned long)__bss_stop - (unsigned long)_text); > > + (unsigned long)__end_of_kernel_reserve - (unsigned long)_text); > > > > So it replaces __bss_stop with __end_of_kernel_reserve here. > > > > --- a/arch/x86/kernel/vmlinux.lds.S > > +++ b/arch/x86/kernel/vmlinux.lds.S > > @@ -368,6 +368,14 @@ SECTIONS > > __bss_stop = .; > > } > > > > + /* > > + * The memory occupied from _text to here, __end_of_kernel_reserve, is > > + * automatically reserved in setup_arch(). Anything after here must be > > + * explicitly reserved using memblock_reserve() or it will be discarded > > + * and treated as available memory. > > + */ > > + __end_of_kernel_reserve = .; > > > > And from the linker script __bss_stop and __end_of_kernel_reserve are > > exactly the same. From System.map (of a successful ld build): > > > > ffffffff82c00000 B __brk_base > > ffffffff82c00000 B __bss_stop > > ffffffff82c00000 B __end_bss_decrypted > > ffffffff82c00000 B __end_of_kernel_reserve > > ffffffff82c00000 B __start_bss_decrypted > > ffffffff82c00000 B __start_bss_decrypted_unused > > > > So how on earth can gold fail with that __end_of_kernel_reserve change? > > > > For some unknown reason it turns that relocation into an absolute > > one. That's clearly a gold bug^Wfeature and TBH, I'm more than concerned > > about that kind of behaviour. > > > > If we just revert that commit, then what do we achieve? We paper over the > > underlying problem, which is not really helping anything. > > > > Aside of that gold still fails to build the X32 VDSO and it does so for a > > very long time.... > > > > Until we really understand what the problem is, this stays as is. > > > > @H.J.: Any insight on that? > > > > Since building a workable kernel for different kernel configurations isn't a > requirement for gold, I don't recommend gold for kernel. Um, it worked before this commit, and now it doesn't. "Some" companies are using gold for linking the kernel today... thanks, greg k-h ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-23 13:05 ` Greg KH @ 2019-07-23 13:31 ` Thomas Gleixner 2019-07-23 13:44 ` Greg KH 2019-07-23 13:43 ` Greg KH 1 sibling, 1 reply; 32+ messages in thread From: Thomas Gleixner @ 2019-07-23 13:31 UTC (permalink / raw) To: Greg KH Cc: H.J. Lu, Mike Lothian, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Tue, 23 Jul 2019, Greg KH wrote: > On Mon, Jul 15, 2019 at 01:16:48PM -0700, H.J. Lu wrote: > > > > > > > Since building a workable kernel for different kernel configurations isn't a > > requirement for gold, I don't recommend gold for kernel. > > Um, it worked before this commit, and now it doesn't. "Some" companies > are using gold for linking the kernel today... gold is known to fail the kernel build. x32 vdso linking is not working since years and just because it 'works' for some configurations and breaks for no valid reasons even with those configurations is just not good enough. As there is obviously no priority for fixing gold to work proper with the kernel, I'm not at all interested in these 'regression' reports and in odd 'fixes' which just end up reverting or modifying perfectly valid changes without understanding the root cause, i.e. the most horrible engineering principle: duct-taping. TBH, I'm tired of it. We fail the build for clang if it does not support asm gotos and the clang people are actively working on fixing it and we're helping them as much as we can. The companies who used clang nevertheless have been on their own for years and if someone wants to use gold then nobody is preventing them from doing so. They can keep their duct-tape in their own trees. See this thread for further discussion: https://lkml.kernel.org/r/alpine.DEB.2.21.1907161434260.1767@nanos.tec.linutronix.de Thanks, tglx ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-23 13:31 ` Thomas Gleixner @ 2019-07-23 13:44 ` Greg KH 2019-07-24 15:34 ` Greg KH 0 siblings, 1 reply; 32+ messages in thread From: Greg KH @ 2019-07-23 13:44 UTC (permalink / raw) To: Thomas Gleixner Cc: H.J. Lu, Mike Lothian, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Tue, Jul 23, 2019 at 03:31:32PM +0200, Thomas Gleixner wrote: > On Tue, 23 Jul 2019, Greg KH wrote: > > On Mon, Jul 15, 2019 at 01:16:48PM -0700, H.J. Lu wrote: > > > > > > > > > > Since building a workable kernel for different kernel configurations isn't a > > > requirement for gold, I don't recommend gold for kernel. > > > > Um, it worked before this commit, and now it doesn't. "Some" companies > > are using gold for linking the kernel today... > > gold is known to fail the kernel build. x32 vdso linking is not working > since years and just because it 'works' for some configurations and breaks > for no valid reasons even with those configurations is just not good > enough. > > As there is obviously no priority for fixing gold to work proper with the > kernel, I'm not at all interested in these 'regression' reports and in odd > 'fixes' which just end up reverting or modifying perfectly valid changes > without understanding the root cause, i.e. the most horrible engineering > principle: duct-taping. > > TBH, I'm tired of it. We fail the build for clang if it does not support > asm gotos and the clang people are actively working on fixing it and we're > helping them as much as we can. The companies who used clang nevertheless > have been on their own for years and if someone wants to use gold then > nobody is preventing them from doing so. They can keep their duct-tape in > their own trees. > > See this thread for further discussion: > > https://lkml.kernel.org/r/alpine.DEB.2.21.1907161434260.1767@nanos.tec.linutronix.de Sorry, I saw that after writing that. You are right, if the others don't object, that's fine with me. I'll go poke the various build systems that are failing right now on 5.3-rc1 and try to get them fixed for this reason. thanks, greg k-h ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-23 13:44 ` Greg KH @ 2019-07-24 15:34 ` Greg KH 2019-07-24 15:49 ` Thomas Gleixner 0 siblings, 1 reply; 32+ messages in thread From: Greg KH @ 2019-07-24 15:34 UTC (permalink / raw) To: Thomas Gleixner Cc: H.J. Lu, Mike Lothian, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Tue, Jul 23, 2019 at 03:44:54PM +0200, Greg KH wrote: > On Tue, Jul 23, 2019 at 03:31:32PM +0200, Thomas Gleixner wrote: > > On Tue, 23 Jul 2019, Greg KH wrote: > > > On Mon, Jul 15, 2019 at 01:16:48PM -0700, H.J. Lu wrote: > > > > > > > > > > > > > Since building a workable kernel for different kernel configurations isn't a > > > > requirement for gold, I don't recommend gold for kernel. > > > > > > Um, it worked before this commit, and now it doesn't. "Some" companies > > > are using gold for linking the kernel today... > > > > gold is known to fail the kernel build. x32 vdso linking is not working > > since years and just because it 'works' for some configurations and breaks > > for no valid reasons even with those configurations is just not good > > enough. > > > > As there is obviously no priority for fixing gold to work proper with the > > kernel, I'm not at all interested in these 'regression' reports and in odd > > 'fixes' which just end up reverting or modifying perfectly valid changes > > without understanding the root cause, i.e. the most horrible engineering > > principle: duct-taping. > > > > TBH, I'm tired of it. We fail the build for clang if it does not support > > asm gotos and the clang people are actively working on fixing it and we're > > helping them as much as we can. The companies who used clang nevertheless > > have been on their own for years and if someone wants to use gold then > > nobody is preventing them from doing so. They can keep their duct-tape in > > their own trees. > > > > See this thread for further discussion: > > > > https://lkml.kernel.org/r/alpine.DEB.2.21.1907161434260.1767@nanos.tec.linutronix.de > > Sorry, I saw that after writing that. You are right, if the others > don't object, that's fine with me. I'll go poke the various build > systems that are failing right now on 5.3-rc1 and try to get them fixed > for this reason. Ok, I dug around and the gold linker is not being used here, only clang to build the source and GNU ld to link, and I am still seeing this error. Hm, clang 8 does not cause this error, but clang 9 does. Let me go poke the people who are providing this version of clang to see if there's something they can figure out. greg k-h ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-24 15:34 ` Greg KH @ 2019-07-24 15:49 ` Thomas Gleixner 2019-07-24 15:57 ` Greg KH 2019-07-24 16:01 ` Thomas Gleixner 0 siblings, 2 replies; 32+ messages in thread From: Thomas Gleixner @ 2019-07-24 15:49 UTC (permalink / raw) To: Greg KH Cc: H.J. Lu, Mike Lothian, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Wed, 24 Jul 2019, Greg KH wrote: > On Tue, Jul 23, 2019 at 03:44:54PM +0200, Greg KH wrote: > > Sorry, I saw that after writing that. You are right, if the others > > don't object, that's fine with me. I'll go poke the various build > > systems that are failing right now on 5.3-rc1 and try to get them fixed > > for this reason. > > Ok, I dug around and the gold linker is not being used here, only clang > to build the source and GNU ld to link, and I am still seeing this > error. Odd combo. > Hm, clang 8 does not cause this error, but clang 9 does. Let me go poke > the people who are providing this version of clang to see if there's > something they can figure out. Let me try that with my clang variant. Which version of GNU ld are you using? Thanks, tglx ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-24 15:49 ` Thomas Gleixner @ 2019-07-24 15:57 ` Greg KH 2019-07-24 16:03 ` Thomas Gleixner 2019-07-24 16:22 ` Peter Zijlstra 2019-07-24 16:01 ` Thomas Gleixner 1 sibling, 2 replies; 32+ messages in thread From: Greg KH @ 2019-07-24 15:57 UTC (permalink / raw) To: Thomas Gleixner Cc: H.J. Lu, Mike Lothian, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Wed, Jul 24, 2019 at 05:49:45PM +0200, Thomas Gleixner wrote: > On Wed, 24 Jul 2019, Greg KH wrote: > > On Tue, Jul 23, 2019 at 03:44:54PM +0200, Greg KH wrote: > > > Sorry, I saw that after writing that. You are right, if the others > > > don't object, that's fine with me. I'll go poke the various build > > > systems that are failing right now on 5.3-rc1 and try to get them fixed > > > for this reason. > > > > Ok, I dug around and the gold linker is not being used here, only clang > > to build the source and GNU ld to link, and I am still seeing this > > error. > > Odd combo. I'm not disagreeing :) Wait, does clang link things itself and not need ld? > > Hm, clang 8 does not cause this error, but clang 9 does. Let me go poke > > the people who are providing this version of clang to see if there's > > something they can figure out. > > Let me try that with my clang variant. Which version of GNU ld are you > using? I think it is 2.27: $ ./ld --version GNU ld (binutils-2.27-44492f8) 2.27.0.20170315 Which does feel old to me. I know 2.32 works fine. Gotta love old tool-chains :( greg k-h ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-24 15:57 ` Greg KH @ 2019-07-24 16:03 ` Thomas Gleixner 2019-07-24 16:16 ` Greg KH 2019-07-24 16:22 ` Peter Zijlstra 1 sibling, 1 reply; 32+ messages in thread From: Thomas Gleixner @ 2019-07-24 16:03 UTC (permalink / raw) To: Greg KH Cc: H.J. Lu, Mike Lothian, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Wed, 24 Jul 2019, Greg KH wrote: > On Wed, Jul 24, 2019 at 05:49:45PM +0200, Thomas Gleixner wrote: > > > Ok, I dug around and the gold linker is not being used here, only clang > > > to build the source and GNU ld to link, and I am still seeing this > > > error. > > > > Odd combo. > > I'm not disagreeing :) > > Wait, does clang link things itself and not need ld? Nah. > > > Hm, clang 8 does not cause this error, but clang 9 does. Let me go poke > > > the people who are providing this version of clang to see if there's > > > something they can figure out. > > > > Let me try that with my clang variant. Which version of GNU ld are you > > using? > > I think it is 2.27: > $ ./ld --version > GNU ld (binutils-2.27-44492f8) 2.27.0.20170315 > > Which does feel old to me. > > I know 2.32 works fine. 2.31 works fine as well. > Gotta love old tool-chains :( Oh yes. /me does archaeology to find a VM with old stuff ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-24 16:03 ` Thomas Gleixner @ 2019-07-24 16:16 ` Greg KH 2019-07-24 20:02 ` Thomas Gleixner 0 siblings, 1 reply; 32+ messages in thread From: Greg KH @ 2019-07-24 16:16 UTC (permalink / raw) To: Thomas Gleixner Cc: H.J. Lu, Mike Lothian, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Wed, Jul 24, 2019 at 06:03:41PM +0200, Thomas Gleixner wrote: > On Wed, 24 Jul 2019, Greg KH wrote: > > On Wed, Jul 24, 2019 at 05:49:45PM +0200, Thomas Gleixner wrote: > > > > Ok, I dug around and the gold linker is not being used here, only clang > > > > to build the source and GNU ld to link, and I am still seeing this > > > > error. > > > > > > Odd combo. > > > > I'm not disagreeing :) > > > > Wait, does clang link things itself and not need ld? > > Nah. > > > > > Hm, clang 8 does not cause this error, but clang 9 does. Let me go poke > > > > the people who are providing this version of clang to see if there's > > > > something they can figure out. > > > > > > Let me try that with my clang variant. Which version of GNU ld are you > > > using? > > > > I think it is 2.27: > > $ ./ld --version > > GNU ld (binutils-2.27-44492f8) 2.27.0.20170315 > > > > Which does feel old to me. > > > > I know 2.32 works fine. > > 2.31 works fine as well. > > > Gotta love old tool-chains :( > > Oh yes. /me does archaeology to find a VM with old stuff I can provide a binary if you can't find anything. thanks, greg k-h ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-24 16:16 ` Greg KH @ 2019-07-24 20:02 ` Thomas Gleixner 2019-07-24 20:20 ` Thomas Gleixner 0 siblings, 1 reply; 32+ messages in thread From: Thomas Gleixner @ 2019-07-24 20:02 UTC (permalink / raw) To: Greg KH Cc: H.J. Lu, Mike Lothian, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Wed, 24 Jul 2019, Greg KH wrote: > On Wed, Jul 24, 2019 at 06:03:41PM +0200, Thomas Gleixner wrote: > > > Gotta love old tool-chains :( > > > > Oh yes. /me does archaeology to find a VM with old stuff > > I can provide a binary if you can't find anything. Found GNU ld (GNU Binutils for Debian) 2.25 and after fiddling with LD_PRELOAD it builds without failure. ld.gold from that binutils version dies with a segfault on various files ... Thanks, tglx ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-24 20:02 ` Thomas Gleixner @ 2019-07-24 20:20 ` Thomas Gleixner 2019-07-25 6:24 ` Greg KH 0 siblings, 1 reply; 32+ messages in thread From: Thomas Gleixner @ 2019-07-24 20:20 UTC (permalink / raw) To: Greg KH Cc: H.J. Lu, Mike Lothian, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Wed, 24 Jul 2019, Thomas Gleixner wrote: > On Wed, 24 Jul 2019, Greg KH wrote: > > On Wed, Jul 24, 2019 at 06:03:41PM +0200, Thomas Gleixner wrote: > > > > Gotta love old tool-chains :( > > > > > > Oh yes. /me does archaeology to find a VM with old stuff > > > > I can provide a binary if you can't find anything. > > Found GNU ld (GNU Binutils for Debian) 2.25 and after fiddling with > LD_PRELOAD it builds without failure. > > ld.gold from that binutils version dies with a segfault on various files ... Then tried that old ld.bfd with GCC8 and that causes ld.bfd to segfault on every other file. Copied that config to the clang build directory and it causes the same explosions with ld.bfd. What a time waste... ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-24 20:20 ` Thomas Gleixner @ 2019-07-25 6:24 ` Greg KH 2019-08-14 11:09 ` Mike Lothian 0 siblings, 1 reply; 32+ messages in thread From: Greg KH @ 2019-07-25 6:24 UTC (permalink / raw) To: Thomas Gleixner Cc: H.J. Lu, Mike Lothian, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Wed, Jul 24, 2019 at 10:20:34PM +0200, Thomas Gleixner wrote: > On Wed, 24 Jul 2019, Thomas Gleixner wrote: > > > On Wed, 24 Jul 2019, Greg KH wrote: > > > On Wed, Jul 24, 2019 at 06:03:41PM +0200, Thomas Gleixner wrote: > > > > > Gotta love old tool-chains :( > > > > > > > > Oh yes. /me does archaeology to find a VM with old stuff > > > > > > I can provide a binary if you can't find anything. > > > > Found GNU ld (GNU Binutils for Debian) 2.25 and after fiddling with > > LD_PRELOAD it builds without failure. > > > > ld.gold from that binutils version dies with a segfault on various files ... > > Then tried that old ld.bfd with GCC8 and that causes ld.bfd to segfault on > every other file. > > Copied that config to the clang build directory and it causes the same > explosions with ld.bfd. > > What a time waste... > > > Ugh, sorry about this. I can't seem to track it down either, and at this point am just going to punt and let the Android build people try to figure it out as it is their custom build system that is failing at the moment, only for x86, and if this single patch is reverted, it starts working again. voodo... thanks, greg k-h ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-25 6:24 ` Greg KH @ 2019-08-14 11:09 ` Mike Lothian 2019-08-19 12:53 ` Mike Lothian 0 siblings, 1 reply; 32+ messages in thread From: Mike Lothian @ 2019-08-14 11:09 UTC (permalink / raw) To: Greg KH Cc: Thomas Gleixner, H.J. Lu, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Thu, 25 Jul 2019 at 07:59, Greg KH <gregkh@linuxfoundation.org> wrote: > > On Wed, Jul 24, 2019 at 10:20:34PM +0200, Thomas Gleixner wrote: > > On Wed, 24 Jul 2019, Thomas Gleixner wrote: > > > > > On Wed, 24 Jul 2019, Greg KH wrote: > > > > On Wed, Jul 24, 2019 at 06:03:41PM +0200, Thomas Gleixner wrote: > > > > > > Gotta love old tool-chains :( > > > > > > > > > > Oh yes. /me does archaeology to find a VM with old stuff > > > > > > > > I can provide a binary if you can't find anything. > > > > > > Found GNU ld (GNU Binutils for Debian) 2.25 and after fiddling with > > > LD_PRELOAD it builds without failure. > > > > > > ld.gold from that binutils version dies with a segfault on various files ... > > > > Then tried that old ld.bfd with GCC8 and that causes ld.bfd to segfault on > > every other file. > > > > Copied that config to the clang build directory and it causes the same > > explosions with ld.bfd. > > > > What a time waste... > > > > > > > > Ugh, sorry about this. I can't seem to track it down either, and at > this point am just going to punt and let the Android build people try to > figure it out as it is their custom build system that is failing at the > moment, only for x86, and if this single patch is reverted, it starts > working again. > > voodo... > > thanks, > > greg k-h As it's related. I've raised https://bugzilla.kernel.org/show_bug.cgi?id=204495 about the relocatition I'm seeing since switching back to ld.bfd - is this safe to ignore? I'm guessing this is why gold isn't working as it can't do them Cheers Mike ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-08-14 11:09 ` Mike Lothian @ 2019-08-19 12:53 ` Mike Lothian 2019-08-19 13:08 ` Thomas Gleixner 0 siblings, 1 reply; 32+ messages in thread From: Mike Lothian @ 2019-08-19 12:53 UTC (permalink / raw) To: Greg KH Cc: Thomas Gleixner, H.J. Lu, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Wed, 14 Aug 2019 at 12:09, Mike Lothian <mike@fireburn.co.uk> wrote: > > As it's related. I've raised > https://bugzilla.kernel.org/show_bug.cgi?id=204495 about the > relocatition I'm seeing since switching back to ld.bfd - is this safe > to ignore? I'm guessing this is why gold isn't working as it can't do > them > > Cheers > > Mike Sorry am I asking in the wrong place about this? ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-08-19 12:53 ` Mike Lothian @ 2019-08-19 13:08 ` Thomas Gleixner 2019-08-19 13:21 ` Mike Lothian 0 siblings, 1 reply; 32+ messages in thread From: Thomas Gleixner @ 2019-08-19 13:08 UTC (permalink / raw) To: Mike Lothian Cc: Greg KH, H.J. Lu, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Mon, 19 Aug 2019, Mike Lothian wrote: > On Wed, 14 Aug 2019 at 12:09, Mike Lothian <mike@fireburn.co.uk> wrote: > > > > As it's related. I've raised > > https://bugzilla.kernel.org/show_bug.cgi?id=204495 about the > > relocatition I'm seeing since switching back to ld.bfd - is this safe > > to ignore? I'm guessing this is why gold isn't working as it can't do > > them > > Sorry am I asking in the wrong place about this? No, but I haven't come around to look at it. As your mail above is not giving any useful information and requires to fire up a browser it got on the back burner. That bugzilla entry does not tell anything about the compiler involved, the binutils version and the .config file. I'm really bad at guesswork and my crystal ball got lost years ago :) Care to give that information here by mail? Thanks, tglx ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-08-19 13:08 ` Thomas Gleixner @ 2019-08-19 13:21 ` Mike Lothian 2019-08-19 13:31 ` Thomas Gleixner 0 siblings, 1 reply; 32+ messages in thread From: Mike Lothian @ 2019-08-19 13:21 UTC (permalink / raw) To: Thomas Gleixner Cc: Greg KH, H.J. Lu, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Mon, 19 Aug 2019 at 14:08, Thomas Gleixner <tglx@linutronix.de> wrote: > > On Mon, 19 Aug 2019, Mike Lothian wrote: > > On Wed, 14 Aug 2019 at 12:09, Mike Lothian <mike@fireburn.co.uk> wrote: > > > > > > As it's related. I've raised > > > https://bugzilla.kernel.org/show_bug.cgi?id=204495 about the > > > relocatition I'm seeing since switching back to ld.bfd - is this safe > > > to ignore? I'm guessing this is why gold isn't working as it can't do > > > them > > > > Sorry am I asking in the wrong place about this? > > No, but I haven't come around to look at it. As your mail above is not > giving any useful information and requires to fire up a browser it got on > the back burner. > > That bugzilla entry does not tell anything about the compiler involved, the > binutils version and the .config file. I'm really bad at guesswork and my > crystal ball got lost years ago :) > > Care to give that information here by mail? > > Thanks, > > tglx Hi I'm using GCC 9.2, binutils 2.32. I used to use the gold linker but I've just switched back to using ld.bfd based on this discussion My .config can be found at: https://raw.githubusercontent.com/FireBurn/KernelStuff/master/dot_config_tip Cheers Mike ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-08-19 13:21 ` Mike Lothian @ 2019-08-19 13:31 ` Thomas Gleixner 2019-08-20 12:46 ` Mike Lothian 0 siblings, 1 reply; 32+ messages in thread From: Thomas Gleixner @ 2019-08-19 13:31 UTC (permalink / raw) To: Mike Lothian Cc: Greg KH, H.J. Lu, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Mon, 19 Aug 2019, Mike Lothian wrote: > > I'm using GCC 9.2, binutils 2.32. I used to use the gold linker but > I've just switched back to using ld.bfd based on this discussion > > My .config can be found at: > https://raw.githubusercontent.com/FireBurn/KernelStuff/master/dot_config_tip Does this combo successfully build 5.2 or is this a general problem? Thanks, tglx ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-08-19 13:31 ` Thomas Gleixner @ 2019-08-20 12:46 ` Mike Lothian 0 siblings, 0 replies; 32+ messages in thread From: Mike Lothian @ 2019-08-20 12:46 UTC (permalink / raw) To: Thomas Gleixner Cc: Greg KH, H.J. Lu, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers I've updated the bug some more with more info I can't replicate this on RHEL7 with GCC 4.8.5 or GCC 7.3.1 My GCC is as follows: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-9.2.0/work/gcc-9.2.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/9.2.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/g++-v9 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 9.2.0 p1' --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libmudflap --disable-libssp --disable-systemtap --enable-vtable-verify --enable-lto --with-isl --disable-isl-version-check --enable-default-pie --enable-default-ssp Thread model: posix gcc version 9.2.0 (Gentoo 9.2.0 p1) Could this be related to the --enable-default-ssp or --enable-default-pie? On Mon, 19 Aug 2019 at 14:31, Thomas Gleixner <tglx@linutronix.de> wrote: > > On Mon, 19 Aug 2019, Mike Lothian wrote: > > > > I'm using GCC 9.2, binutils 2.32. I used to use the gold linker but > > I've just switched back to using ld.bfd based on this discussion > > > > My .config can be found at: > > https://raw.githubusercontent.com/FireBurn/KernelStuff/master/dot_config_tip > > Does this combo successfully build 5.2 or is this a general problem? > > Thanks, > > tglx ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-24 15:57 ` Greg KH 2019-07-24 16:03 ` Thomas Gleixner @ 2019-07-24 16:22 ` Peter Zijlstra 1 sibling, 0 replies; 32+ messages in thread From: Peter Zijlstra @ 2019-07-24 16:22 UTC (permalink / raw) To: Greg KH Cc: Thomas Gleixner, H.J. Lu, Mike Lothian, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, the arch/x86 maintainers On Wed, Jul 24, 2019 at 05:57:35PM +0200, Greg KH wrote: > Wait, does clang link things itself and not need ld? There's ld.lld; which might be used by your clang. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-24 15:49 ` Thomas Gleixner 2019-07-24 15:57 ` Greg KH @ 2019-07-24 16:01 ` Thomas Gleixner 1 sibling, 0 replies; 32+ messages in thread From: Thomas Gleixner @ 2019-07-24 16:01 UTC (permalink / raw) To: Greg KH Cc: H.J. Lu, Mike Lothian, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Wed, 24 Jul 2019, Thomas Gleixner wrote: > On Wed, 24 Jul 2019, Greg KH wrote: > > On Tue, Jul 23, 2019 at 03:44:54PM +0200, Greg KH wrote: > > > Sorry, I saw that after writing that. You are right, if the others > > > don't object, that's fine with me. I'll go poke the various build > > > systems that are failing right now on 5.3-rc1 and try to get them fixed > > > for this reason. > > > > Ok, I dug around and the gold linker is not being used here, only clang > > to build the source and GNU ld to link, and I am still seeing this > > error. > > Odd combo. Ha. Not really. I did not switch ld with LD=... so it's using the default GNU ld. > > Hm, clang 8 does not cause this error, but clang 9 does. Let me go poke > > the people who are providing this version of clang to see if there's > > something they can figure out. > > Let me try that with my clang variant. Which version of GNU ld are you > using? Works with a very recent build of the clang-9 branch and ld version 2.31.1 Thanks, tglx ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved 2019-07-23 13:05 ` Greg KH 2019-07-23 13:31 ` Thomas Gleixner @ 2019-07-23 13:43 ` Greg KH 1 sibling, 0 replies; 32+ messages in thread From: Greg KH @ 2019-07-23 13:43 UTC (permalink / raw) To: H.J. Lu Cc: Thomas Gleixner, Mike Lothian, Tom Lendacky, bhe, Borislav Petkov, Dave Hansen, lijiang, Linux Kernel Mailing List, Andy Lutomirski, Ingo Molnar, Peter Zijlstra, the arch/x86 maintainers On Tue, Jul 23, 2019 at 03:05:14PM +0200, Greg KH wrote: > On Mon, Jul 15, 2019 at 01:16:48PM -0700, H.J. Lu wrote: > > On Mon, Jul 15, 2019 at 3:35 AM Thomas Gleixner <tglx@linutronix.de> wrote: > > > > > > On Mon, 15 Jul 2019, Thomas Gleixner wrote: > > > > On Mon, 15 Jul 2019, Mike Lothian wrote: > > > > > That build failure is from the current tip of Linus's tree > > > > > If the fix is in, then it hasn't fixed the issue > > > > > > > > The reverted commit caused a build fail with gold as well. Let me stare at > > > > your issue. > > > > > > So with gold the build fails in the reloc tool complaining about that > > > relocation: > > > > > > Invalid absolute R_X86_64_32S relocation: __end_of_kernel_reserve > > > > > > The commit does: > > > > > > +extern char __end_of_kernel_reserve[]; > > > + > > > > > > void __init setup_arch(char **cmdline_p) > > > { > > > + /* > > > + * Reserve the memory occupied by the kernel between _text and > > > + * __end_of_kernel_reserve symbols. Any kernel sections after the > > > + * __end_of_kernel_reserve symbol must be explicitly reserved with a > > > + * separate memblock_reserve() or they will be discarded. > > > + */ > > > memblock_reserve(__pa_symbol(_text), > > > - (unsigned long)__bss_stop - (unsigned long)_text); > > > + (unsigned long)__end_of_kernel_reserve - (unsigned long)_text); > > > > > > So it replaces __bss_stop with __end_of_kernel_reserve here. > > > > > > --- a/arch/x86/kernel/vmlinux.lds.S > > > +++ b/arch/x86/kernel/vmlinux.lds.S > > > @@ -368,6 +368,14 @@ SECTIONS > > > __bss_stop = .; > > > } > > > > > > + /* > > > + * The memory occupied from _text to here, __end_of_kernel_reserve, is > > > + * automatically reserved in setup_arch(). Anything after here must be > > > + * explicitly reserved using memblock_reserve() or it will be discarded > > > + * and treated as available memory. > > > + */ > > > + __end_of_kernel_reserve = .; > > > > > > And from the linker script __bss_stop and __end_of_kernel_reserve are > > > exactly the same. From System.map (of a successful ld build): > > > > > > ffffffff82c00000 B __brk_base > > > ffffffff82c00000 B __bss_stop > > > ffffffff82c00000 B __end_bss_decrypted > > > ffffffff82c00000 B __end_of_kernel_reserve > > > ffffffff82c00000 B __start_bss_decrypted > > > ffffffff82c00000 B __start_bss_decrypted_unused > > > > > > So how on earth can gold fail with that __end_of_kernel_reserve change? > > > > > > For some unknown reason it turns that relocation into an absolute > > > one. That's clearly a gold bug^Wfeature and TBH, I'm more than concerned > > > about that kind of behaviour. > > > > > > If we just revert that commit, then what do we achieve? We paper over the > > > underlying problem, which is not really helping anything. > > > > > > Aside of that gold still fails to build the X32 VDSO and it does so for a > > > very long time.... > > > > > > Until we really understand what the problem is, this stays as is. > > > > > > @H.J.: Any insight on that? > > > > > > > Since building a workable kernel for different kernel configurations isn't a > > requirement for gold, I don't recommend gold for kernel. > > Um, it worked before this commit, and now it doesn't. "Some" companies > are using gold for linking the kernel today... Oh nevermind, I see the rest of the thread where it's now not being allowed, sorry for the noise. greg k-h ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v3 2/2] x86/mm: Create a workarea in the kernel for SME early encryption 2019-06-19 18:40 [PATCH v3 0/2] x86: SME: Kexec/kdump memory loading fix Lendacky, Thomas 2019-06-19 18:40 ` [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved Lendacky, Thomas @ 2019-06-19 18:40 ` Lendacky, Thomas 2019-06-20 9:58 ` [tip:x86/kdump] " tip-bot for Thomas Lendacky 1 sibling, 1 reply; 32+ messages in thread From: Lendacky, Thomas @ 2019-06-19 18:40 UTC (permalink / raw) To: linux-kernel, x86 Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, Andy Lutomirski, Peter Zijlstra, Lianbo Jiang, Baoquan He In order for the kernel to be encrypted "in place" during boot, a workarea outside of the kernel must be used. This SME workarea used during early encryption of the kernel is situated on a 2MB boundary after the end of the kernel text, data, etc. sections (_end). This works well during initial boot of a compressed kernel because of the relocation used for decompression of the kernel. But when performing a kexec boot, there's a chance that the SME workarea may not be mapped by the kexec pagetables or that some of the other data used by kexec could exist in this range. Create a section for SME in vmlinux.lds.S. Position it after "_end", which is after "__end_of_kernel_reserve", so that the memory will be reclaimed during boot and since this area is all zeroes, it compresses well. This new section will be part of the kernel image, so kexec will account for it in pagetable mappings and placement of data after the kernel. Here's an example of a kernel size without and with the SME section: without: vmlinux: 36,501,616 bzImage: 6,497,344 100000000-47f37ffff : System RAM 1e4000000-1e47677d4 : Kernel code (0x7677d4) 1e47677d5-1e4e2e0bf : Kernel data (0x6c68ea) 1e5074000-1e5372fff : Kernel bss (0x2fefff) with: vmlinux: 44,419,408 bzImage: 6,503,136 880000000-c7ff7ffff : System RAM 8cf000000-8cf7677d4 : Kernel code (0x7677d4) 8cf7677d5-8cfe2e0bf : Kernel data (0x6c68ea) 8d0074000-8d0372fff : Kernel bss (0x2fefff) Tested-by: Lianbo Jiang <lijiang@redhat.com> Reviewed-by: Baoquan He <bhe@redhat.com> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> --- arch/x86/kernel/vmlinux.lds.S | 25 +++++++++++++++++++++++++ arch/x86/mm/mem_encrypt_identity.c | 22 ++++++++++++++++++++-- 2 files changed, 45 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S index ca2252ca6ad7..147cd020516a 100644 --- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -387,6 +387,31 @@ SECTIONS . = ALIGN(PAGE_SIZE); /* keep VO_INIT_SIZE page aligned */ _end = .; +#ifdef CONFIG_AMD_MEM_ENCRYPT + /* + * Early scratch/workarea section: Lives outside of the kernel proper + * (_text - _end). + * + * Resides after _end because even though the .brk section is after + * __end_of_kernel_reserve, the .brk section is later reserved as a + * part of the kernel. Since it is located after __end_of_kernel_reserve + * it will be discarded and become part of the available memory. As + * such, it can only be used by very early boot code and must not be + * needed afterwards. + * + * Currently used by SME for performing in-place encryption of the + * kernel during boot. Resides on a 2MB boundary to simplify the + * pagetable setup used for SME in-place encryption. + */ + . = ALIGN(HPAGE_SIZE); + .init.scratch : AT(ADDR(.init.scratch) - LOAD_OFFSET) { + __init_scratch_begin = .; + *(.init.scratch) + . = ALIGN(HPAGE_SIZE); + __init_scratch_end = .; + } +#endif + STABS_DEBUG DWARF_DEBUG diff --git a/arch/x86/mm/mem_encrypt_identity.c b/arch/x86/mm/mem_encrypt_identity.c index 4aa9b1480866..6a8dd483f7d9 100644 --- a/arch/x86/mm/mem_encrypt_identity.c +++ b/arch/x86/mm/mem_encrypt_identity.c @@ -73,6 +73,19 @@ struct sme_populate_pgd_data { unsigned long vaddr_end; }; +/* + * This work area lives in the .init.scratch section, which lives outside of + * the kernel proper. It is sized to hold the intermediate copy buffer and + * more than enough pagetable pages. + * + * By using this section, the kernel can be encrypted in place and it + * avoids any possibility of boot parameters or initramfs images being + * placed such that the in-place encryption logic overwrites them. This + * section is 2MB aligned to allow for simple pagetable setup using only + * PMD entries (see vmlinux.lds.S). + */ +static char sme_workarea[2 * PMD_PAGE_SIZE] __section(.init.scratch); + static char sme_cmdline_arg[] __initdata = "mem_encrypt"; static char sme_cmdline_on[] __initdata = "on"; static char sme_cmdline_off[] __initdata = "off"; @@ -314,8 +327,13 @@ void __init sme_encrypt_kernel(struct boot_params *bp) } #endif - /* Set the encryption workarea to be immediately after the kernel */ - workarea_start = kernel_end; + /* + * We're running identity mapped, so we must obtain the address to the + * SME encryption workarea using rip-relative addressing. + */ + asm ("lea sme_workarea(%%rip), %0" + : "=r" (workarea_start) + : "p" (sme_workarea)); /* * Calculate required number of workarea bytes needed: -- 2.17.1 ^ permalink raw reply related [flat|nested] 32+ messages in thread
* [tip:x86/kdump] x86/mm: Create a workarea in the kernel for SME early encryption 2019-06-19 18:40 ` [PATCH v3 2/2] x86/mm: Create a workarea in the kernel for SME early encryption Lendacky, Thomas @ 2019-06-20 9:58 ` tip-bot for Thomas Lendacky 0 siblings, 0 replies; 32+ messages in thread From: tip-bot for Thomas Lendacky @ 2019-06-20 9:58 UTC (permalink / raw) To: linux-tip-commits Cc: luto, lijiang, dave.hansen, thomas.lendacky, keescook, x86, peterz, mingo, brijesh.singh, samitolvanen, tglx, mingo, linux-kernel, jroedel, hpa, ndesaulniers, bp, rafael, Thomas.Lendacky, bhe Commit-ID: e1bfa87399e372446454ecbaeba2800f0a385733 Gitweb: https://git.kernel.org/tip/e1bfa87399e372446454ecbaeba2800f0a385733 Author: Thomas Lendacky <Thomas.Lendacky@amd.com> AuthorDate: Wed, 19 Jun 2019 18:40:59 +0000 Committer: Borislav Petkov <bp@suse.de> CommitDate: Thu, 20 Jun 2019 09:44:26 +0200 x86/mm: Create a workarea in the kernel for SME early encryption In order for the kernel to be encrypted "in place" during boot, a workarea outside of the kernel must be used. This SME workarea used during early encryption of the kernel is situated on a 2MB boundary after the end of the kernel text, data, etc. sections (_end). This works well during initial boot of a compressed kernel because of the relocation used for decompression of the kernel. But when performing a kexec boot, there's a chance that the SME workarea may not be mapped by the kexec pagetables or that some of the other data used by kexec could exist in this range. Create a section for SME in vmlinux.lds.S. Position it after "_end", which is after "__end_of_kernel_reserve", so that the memory will be reclaimed during boot and since this area is all zeroes, it compresses well. This new section will be part of the kernel image, so kexec will account for it in pagetable mappings and placement of data after the kernel. Here's an example of a kernel size without and with the SME section: without: vmlinux: 36,501,616 bzImage: 6,497,344 100000000-47f37ffff : System RAM 1e4000000-1e47677d4 : Kernel code (0x7677d4) 1e47677d5-1e4e2e0bf : Kernel data (0x6c68ea) 1e5074000-1e5372fff : Kernel bss (0x2fefff) with: vmlinux: 44,419,408 bzImage: 6,503,136 880000000-c7ff7ffff : System RAM 8cf000000-8cf7677d4 : Kernel code (0x7677d4) 8cf7677d5-8cfe2e0bf : Kernel data (0x6c68ea) 8d0074000-8d0372fff : Kernel bss (0x2fefff) Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Baoquan He <bhe@redhat.com> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Tested-by: Lianbo Jiang <lijiang@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Joerg Roedel <jroedel@suse.de> Cc: Kees Cook <keescook@chromium.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: "Rafael Ávila de Espíndola" <rafael@espindo.la> Cc: Sami Tolvanen <samitolvanen@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "x86@kernel.org" <x86@kernel.org> Link: https://lkml.kernel.org/r/3c483262eb4077b1654b2052bd14a8d011bffde3.1560969363.git.thomas.lendacky@amd.com --- arch/x86/kernel/vmlinux.lds.S | 25 +++++++++++++++++++++++++ arch/x86/mm/mem_encrypt_identity.c | 22 ++++++++++++++++++++-- 2 files changed, 45 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S index ca2252ca6ad7..147cd020516a 100644 --- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -387,6 +387,31 @@ SECTIONS . = ALIGN(PAGE_SIZE); /* keep VO_INIT_SIZE page aligned */ _end = .; +#ifdef CONFIG_AMD_MEM_ENCRYPT + /* + * Early scratch/workarea section: Lives outside of the kernel proper + * (_text - _end). + * + * Resides after _end because even though the .brk section is after + * __end_of_kernel_reserve, the .brk section is later reserved as a + * part of the kernel. Since it is located after __end_of_kernel_reserve + * it will be discarded and become part of the available memory. As + * such, it can only be used by very early boot code and must not be + * needed afterwards. + * + * Currently used by SME for performing in-place encryption of the + * kernel during boot. Resides on a 2MB boundary to simplify the + * pagetable setup used for SME in-place encryption. + */ + . = ALIGN(HPAGE_SIZE); + .init.scratch : AT(ADDR(.init.scratch) - LOAD_OFFSET) { + __init_scratch_begin = .; + *(.init.scratch) + . = ALIGN(HPAGE_SIZE); + __init_scratch_end = .; + } +#endif + STABS_DEBUG DWARF_DEBUG diff --git a/arch/x86/mm/mem_encrypt_identity.c b/arch/x86/mm/mem_encrypt_identity.c index 4aa9b1480866..6a8dd483f7d9 100644 --- a/arch/x86/mm/mem_encrypt_identity.c +++ b/arch/x86/mm/mem_encrypt_identity.c @@ -73,6 +73,19 @@ struct sme_populate_pgd_data { unsigned long vaddr_end; }; +/* + * This work area lives in the .init.scratch section, which lives outside of + * the kernel proper. It is sized to hold the intermediate copy buffer and + * more than enough pagetable pages. + * + * By using this section, the kernel can be encrypted in place and it + * avoids any possibility of boot parameters or initramfs images being + * placed such that the in-place encryption logic overwrites them. This + * section is 2MB aligned to allow for simple pagetable setup using only + * PMD entries (see vmlinux.lds.S). + */ +static char sme_workarea[2 * PMD_PAGE_SIZE] __section(.init.scratch); + static char sme_cmdline_arg[] __initdata = "mem_encrypt"; static char sme_cmdline_on[] __initdata = "on"; static char sme_cmdline_off[] __initdata = "off"; @@ -314,8 +327,13 @@ void __init sme_encrypt_kernel(struct boot_params *bp) } #endif - /* Set the encryption workarea to be immediately after the kernel */ - workarea_start = kernel_end; + /* + * We're running identity mapped, so we must obtain the address to the + * SME encryption workarea using rip-relative addressing. + */ + asm ("lea sme_workarea(%%rip), %0" + : "=r" (workarea_start) + : "p" (sme_workarea)); /* * Calculate required number of workarea bytes needed: ^ permalink raw reply related [flat|nested] 32+ messages in thread
end of thread, other threads:[~2019-08-20 12:47 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-19 18:40 [PATCH v3 0/2] x86: SME: Kexec/kdump memory loading fix Lendacky, Thomas
2019-06-19 18:40 ` [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved Lendacky, Thomas
2019-06-20 9:58 ` [tip:x86/kdump] " tip-bot for Thomas Lendacky
2019-07-13 14:59 ` [PATCH v3 1/2] " Mike Lothian
2019-07-14 10:16 ` Thomas Gleixner
2019-07-14 10:27 ` Mike Lothian
2019-07-15 8:12 ` Thomas Gleixner
[not found] ` <CAHbf0-F9yUDJ=DKug+MZqsjW+zPgwWaLUC40BLOsr5+t4kYOLQ@mail.gmail.com>
2019-07-15 9:25 ` Thomas Gleixner
2019-07-15 10:35 ` Thomas Gleixner
2019-07-15 20:16 ` H.J. Lu
2019-07-23 13:05 ` Greg KH
2019-07-23 13:31 ` Thomas Gleixner
2019-07-23 13:44 ` Greg KH
2019-07-24 15:34 ` Greg KH
2019-07-24 15:49 ` Thomas Gleixner
2019-07-24 15:57 ` Greg KH
2019-07-24 16:03 ` Thomas Gleixner
2019-07-24 16:16 ` Greg KH
2019-07-24 20:02 ` Thomas Gleixner
2019-07-24 20:20 ` Thomas Gleixner
2019-07-25 6:24 ` Greg KH
2019-08-14 11:09 ` Mike Lothian
2019-08-19 12:53 ` Mike Lothian
2019-08-19 13:08 ` Thomas Gleixner
2019-08-19 13:21 ` Mike Lothian
2019-08-19 13:31 ` Thomas Gleixner
2019-08-20 12:46 ` Mike Lothian
2019-07-24 16:22 ` Peter Zijlstra
2019-07-24 16:01 ` Thomas Gleixner
2019-07-23 13:43 ` Greg KH
2019-06-19 18:40 ` [PATCH v3 2/2] x86/mm: Create a workarea in the kernel for SME early encryption Lendacky, Thomas
2019-06-20 9:58 ` [tip:x86/kdump] " tip-bot for Thomas Lendacky
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.