From: Jason Yan <yanaijie@huawei.com> To: Scott Wood <oss@buserror.net>, <mpe@ellerman.id.au>, <linuxppc-dev@lists.ozlabs.org>, <diana.craciun@nxp.com>, <christophe.leroy@c-s.fr>, <benh@kernel.crashing.org>, <paulus@samba.org>, <npiggin@gmail.com>, <keescook@chromium.org>, <kernel-hardening@lists.openwall.com> Cc: <linux-kernel@vger.kernel.org>, <zhaohongjiang@huawei.com> Subject: Re: [PATCH v3 3/6] powerpc/fsl_booke/64: implement KASLR for fsl_booke64 Date: Thu, 5 Mar 2020 10:32:25 +0800 [thread overview] Message-ID: <a4fb67df-b7e3-0e42-0bb3-1d92dc487b98@huawei.com> (raw) In-Reply-To: <10913e48efea24c1d217bc5a723d6cd827945de7.camel@buserror.net> 在 2020/3/5 5:44, Scott Wood 写道: > On Thu, 2020-02-06 at 10:58 +0800, Jason Yan wrote: >> The implementation for Freescale BookE64 is similar as BookE32. One >> difference is that Freescale BookE64 set up a TLB mapping of 1G during >> booting. Another difference is that ppc64 needs the kernel to be >> 64K-aligned. So we can randomize the kernel in this 1G mapping and make >> it 64K-aligned. This can save some code to creat another TLB map at >> early boot. The disadvantage is that we only have about 1G/64K = 16384 >> slots to put the kernel in. >> >> To support secondary cpu boot up, a variable __kaslr_offset was added in >> first_256B section. This can help secondary cpu get the kaslr offset >> before the 1:1 mapping has been setup. > > What specifically requires __kaslr_offset instead of using kernstart_virt_addr > like 32-bit does? > kernstart_virt_addr is in the data section. At the early boot we only have a 64M tlb mapping. For the 32-bit I limited the kernel in a 64M-aligned region so that we can always get kernstart_virt_addr. But for the 64-bit the kernel is bigger and not suitable to limit it in a 64M-aligned region. So if we use kernstart_virt_addr and the kernel is randomized like below , the secondary cpus will not boot up: +------------+------------+ | 64M | 64M | +------------+------------+ ^ ^ | kernel | ^ kernstart_virt_addr So I have to put the kernel offset in the first 64K along with the init text. >> >> diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S >> index ad79fddb974d..744624140fb8 100644 >> --- a/arch/powerpc/kernel/head_64.S >> +++ b/arch/powerpc/kernel/head_64.S >> @@ -104,6 +104,13 @@ __secondary_hold_acknowledge: >> .8byte 0x0 >> >> #ifdef CONFIG_RELOCATABLE >> +#ifdef CONFIG_RANDOMIZE_BASE >> + . = 0x58 >> + .globl __kaslr_offset >> +__kaslr_offset: >> +DEFINE_FIXED_SYMBOL(__kaslr_offset) >> + .long 0 >> +#endif >> /* This flag is set to 1 by a loader if the kernel should run >> * at the loaded address instead of the linked address. This >> * is used by kexec-tools to keep the the kdump kernel in the > > Why does it need to go here at a fixed address? > It does not need to be at a fixed address. I just want to keep consistent and stay along with __run_at_load. > >> >> /* check for a reserved-memory node and record its cell sizes */ >> regions.reserved_mem = fdt_path_offset(dt_ptr, "/reserved-memory"); >> @@ -363,6 +374,17 @@ notrace void __init kaslr_early_init(void *dt_ptr, >> phys_addr_t size) >> unsigned long offset; >> unsigned long kernel_sz; >> >> +#ifdef CONFIG_PPC64 >> + unsigned int *__kaslr_offset = (unsigned int *)(KERNELBASE + 0x58); >> + unsigned int *__run_at_load = (unsigned int *)(KERNELBASE + 0x5c); > > Why are you referencing these by magic offset rather than by symbol? > I'm not sure if relocat works for fixed symbols. I will have a test and swith to reference them by symbols if it works fine. > >> + /* Setup flat device-tree pointer */ >> + initial_boot_params = dt_ptr; >> +#endif > > Why does 64-bit need this but 32-bit doesn't? 32-bit called early_get_first_memblock_info() very early which implicitly setup the device-tree pointer. > > -Scott > > > > . >
WARNING: multiple messages have this Message-ID (diff)
From: Jason Yan <yanaijie@huawei.com> To: Scott Wood <oss@buserror.net>, <mpe@ellerman.id.au>, <linuxppc-dev@lists.ozlabs.org>, <diana.craciun@nxp.com>, <christophe.leroy@c-s.fr>, <benh@kernel.crashing.org>, <paulus@samba.org>, <npiggin@gmail.com>, <keescook@chromium.org>, <kernel-hardening@lists.openwall.com> Cc: linux-kernel@vger.kernel.org, zhaohongjiang@huawei.com Subject: Re: [PATCH v3 3/6] powerpc/fsl_booke/64: implement KASLR for fsl_booke64 Date: Thu, 5 Mar 2020 10:32:25 +0800 [thread overview] Message-ID: <a4fb67df-b7e3-0e42-0bb3-1d92dc487b98@huawei.com> (raw) In-Reply-To: <10913e48efea24c1d217bc5a723d6cd827945de7.camel@buserror.net> 在 2020/3/5 5:44, Scott Wood 写道: > On Thu, 2020-02-06 at 10:58 +0800, Jason Yan wrote: >> The implementation for Freescale BookE64 is similar as BookE32. One >> difference is that Freescale BookE64 set up a TLB mapping of 1G during >> booting. Another difference is that ppc64 needs the kernel to be >> 64K-aligned. So we can randomize the kernel in this 1G mapping and make >> it 64K-aligned. This can save some code to creat another TLB map at >> early boot. The disadvantage is that we only have about 1G/64K = 16384 >> slots to put the kernel in. >> >> To support secondary cpu boot up, a variable __kaslr_offset was added in >> first_256B section. This can help secondary cpu get the kaslr offset >> before the 1:1 mapping has been setup. > > What specifically requires __kaslr_offset instead of using kernstart_virt_addr > like 32-bit does? > kernstart_virt_addr is in the data section. At the early boot we only have a 64M tlb mapping. For the 32-bit I limited the kernel in a 64M-aligned region so that we can always get kernstart_virt_addr. But for the 64-bit the kernel is bigger and not suitable to limit it in a 64M-aligned region. So if we use kernstart_virt_addr and the kernel is randomized like below , the secondary cpus will not boot up: +------------+------------+ | 64M | 64M | +------------+------------+ ^ ^ | kernel | ^ kernstart_virt_addr So I have to put the kernel offset in the first 64K along with the init text. >> >> diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S >> index ad79fddb974d..744624140fb8 100644 >> --- a/arch/powerpc/kernel/head_64.S >> +++ b/arch/powerpc/kernel/head_64.S >> @@ -104,6 +104,13 @@ __secondary_hold_acknowledge: >> .8byte 0x0 >> >> #ifdef CONFIG_RELOCATABLE >> +#ifdef CONFIG_RANDOMIZE_BASE >> + . = 0x58 >> + .globl __kaslr_offset >> +__kaslr_offset: >> +DEFINE_FIXED_SYMBOL(__kaslr_offset) >> + .long 0 >> +#endif >> /* This flag is set to 1 by a loader if the kernel should run >> * at the loaded address instead of the linked address. This >> * is used by kexec-tools to keep the the kdump kernel in the > > Why does it need to go here at a fixed address? > It does not need to be at a fixed address. I just want to keep consistent and stay along with __run_at_load. > >> >> /* check for a reserved-memory node and record its cell sizes */ >> regions.reserved_mem = fdt_path_offset(dt_ptr, "/reserved-memory"); >> @@ -363,6 +374,17 @@ notrace void __init kaslr_early_init(void *dt_ptr, >> phys_addr_t size) >> unsigned long offset; >> unsigned long kernel_sz; >> >> +#ifdef CONFIG_PPC64 >> + unsigned int *__kaslr_offset = (unsigned int *)(KERNELBASE + 0x58); >> + unsigned int *__run_at_load = (unsigned int *)(KERNELBASE + 0x5c); > > Why are you referencing these by magic offset rather than by symbol? > I'm not sure if relocat works for fixed symbols. I will have a test and swith to reference them by symbols if it works fine. > >> + /* Setup flat device-tree pointer */ >> + initial_boot_params = dt_ptr; >> +#endif > > Why does 64-bit need this but 32-bit doesn't? 32-bit called early_get_first_memblock_info() very early which implicitly setup the device-tree pointer. > > -Scott > > > > . >
next prev parent reply other threads:[~2020-03-05 2:32 UTC|newest] Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-06 2:58 [PATCH v3 0/6] implement KASLR for powerpc/fsl_booke/64 Jason Yan 2020-02-06 2:58 ` Jason Yan 2020-02-06 2:58 ` [PATCH v3 1/6] powerpc/fsl_booke/kaslr: refactor kaslr_legal_offset() and kaslr_early_init() Jason Yan 2020-02-06 2:58 ` Jason Yan 2020-02-20 13:40 ` Christophe Leroy 2020-02-26 2:11 ` Jason Yan 2020-02-26 2:11 ` Jason Yan 2020-02-06 2:58 ` [PATCH v3 2/6] powerpc/fsl_booke/64: introduce reloc_kernel_entry() helper Jason Yan 2020-02-06 2:58 ` Jason Yan 2020-02-20 13:41 ` Christophe Leroy 2020-02-06 2:58 ` [PATCH v3 3/6] powerpc/fsl_booke/64: implement KASLR for fsl_booke64 Jason Yan 2020-02-06 2:58 ` Jason Yan 2020-02-20 13:48 ` Christophe Leroy 2020-02-26 2:40 ` Jason Yan 2020-02-26 2:40 ` Jason Yan 2020-02-26 3:33 ` Jason Yan 2020-02-26 3:33 ` Jason Yan 2020-02-26 5:04 ` [RFC PATCH] Use IS_ENABLED() instead of #ifdefs Christophe Leroy 2020-02-26 5:04 ` Christophe Leroy 2020-02-26 6:26 ` Jason Yan 2020-02-26 6:26 ` Jason Yan 2020-02-26 5:10 ` [PATCH v3 3/6] powerpc/fsl_booke/64: implement KASLR for fsl_booke64 Christophe Leroy 2020-02-26 5:08 ` Christophe Leroy 2020-03-04 21:44 ` Scott Wood 2020-03-04 21:44 ` Scott Wood 2020-03-05 2:32 ` Jason Yan [this message] 2020-03-05 2:32 ` Jason Yan 2020-02-06 2:58 ` [PATCH v3 4/6] powerpc/fsl_booke/64: do not clear the BSS for the second pass Jason Yan 2020-02-06 2:58 ` Jason Yan 2020-03-04 21:49 ` Scott Wood 2020-03-04 21:49 ` Scott Wood 2020-03-05 3:14 ` Jason Yan 2020-03-05 3:14 ` Jason Yan 2020-02-06 2:58 ` [PATCH v3 5/6] powerpc/fsl_booke/64: clear the original kernel if randomized Jason Yan 2020-02-06 2:58 ` Jason Yan 2020-02-20 13:49 ` Christophe Leroy 2020-02-26 2:44 ` Jason Yan 2020-02-26 2:44 ` Jason Yan 2020-03-04 21:53 ` Scott Wood 2020-03-04 21:53 ` Scott Wood 2020-03-05 3:20 ` Jason Yan 2020-03-05 3:20 ` Jason Yan 2020-02-06 2:58 ` [PATCH v3 6/6] powerpc/fsl_booke/kaslr: rename kaslr-booke32.rst to kaslr-booke.rst and add 64bit part Jason Yan 2020-02-06 2:58 ` Jason Yan 2020-02-20 13:50 ` Christophe Leroy 2020-02-26 2:46 ` Jason Yan 2020-02-26 2:46 ` Jason Yan 2020-02-13 3:00 ` [PATCH v3 0/6] implement KASLR for powerpc/fsl_booke/64 Jason Yan 2020-02-13 3:00 ` Jason Yan 2020-02-20 3:33 ` Jason Yan 2020-02-20 3:33 ` Jason Yan 2020-02-26 7:16 ` Daniel Axtens 2020-02-26 7:16 ` Daniel Axtens 2020-02-26 8:18 ` Jason Yan 2020-02-26 8:18 ` Jason Yan 2020-02-26 11:41 ` Daniel Axtens 2020-02-27 1:55 ` Jason Yan 2020-02-27 1:55 ` Jason Yan 2020-02-28 5:53 ` Scott Wood 2020-02-28 5:53 ` Scott Wood 2020-02-28 6:47 ` Jason Yan 2020-02-28 6:47 ` Jason Yan 2020-02-29 4:28 ` Scott Wood 2020-02-29 4:28 ` Scott Wood 2020-02-29 7:27 ` Jason Yan 2020-02-29 7:27 ` Jason Yan 2020-02-29 22:54 ` Scott Wood 2020-02-29 22:54 ` Scott Wood 2020-03-02 2:17 ` Jason Yan 2020-03-02 2:17 ` Jason Yan 2020-03-02 3:24 ` Scott Wood 2020-03-02 3:24 ` Scott Wood 2020-03-02 7:12 ` Jason Yan 2020-03-02 7:12 ` Jason Yan 2020-03-02 8:47 ` Scott Wood 2020-03-02 8:47 ` Scott Wood 2020-03-02 9:37 ` Jason Yan 2020-03-02 9:37 ` Jason Yan 2020-03-04 21:21 ` Scott Wood 2020-03-04 21:21 ` Scott Wood 2020-03-05 3:22 ` Jason Yan 2020-03-05 3:22 ` Jason Yan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=a4fb67df-b7e3-0e42-0bb3-1d92dc487b98@huawei.com \ --to=yanaijie@huawei.com \ --cc=benh@kernel.crashing.org \ --cc=christophe.leroy@c-s.fr \ --cc=diana.craciun@nxp.com \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=mpe@ellerman.id.au \ --cc=npiggin@gmail.com \ --cc=oss@buserror.net \ --cc=paulus@samba.org \ --cc=zhaohongjiang@huawei.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.