| Message ID | 20170603071843.11966-6-bsingharora@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Sat, 3 Jun 2017 17:18:39 +1000 Balbir Singh <bsingharora@gmail.com> wrote: > For CONFIG_STRICT_KERNEL_RWX align __init_begin to 16M. > We use 16M since its the larger of 2M on radix and 16M > on hash for our linear mapping. The plan is to have > .text, .rodata and everything upto __init_begin marked > as RX. Note we still have executable read only data. > We could further align read only data to another 16M > boundary, but then the linker starts using stubs and > that breaks our assembler code in head_64.S Is this still the case with powerpc next? Thanks, Nick
On Sun, Jun 4, 2017 at 2:22 PM, Nicholas Piggin <npiggin@gmail.com> wrote: > On Sat, 3 Jun 2017 17:18:39 +1000 > Balbir Singh <bsingharora@gmail.com> wrote: > >> For CONFIG_STRICT_KERNEL_RWX align __init_begin to 16M. >> We use 16M since its the larger of 2M on radix and 16M >> on hash for our linear mapping. The plan is to have >> .text, .rodata and everything upto __init_begin marked >> as RX. Note we still have executable read only data. >> We could further align read only data to another 16M >> boundary, but then the linker starts using stubs and >> that breaks our assembler code in head_64.S > > Is this still the case with powerpc next? > Sorry, no, I was on linux-next for testing, but I think your linker stub patches went in very recently. I'll rebase on top and test, but I am not sure if I want two 16M alignments and bloat the size of vmlinux. But I'll double check what happens Balbir Singh.
On Mon, 5 Jun 2017 08:42:40 +1000 Balbir Singh <bsingharora@gmail.com> wrote: > On Sun, Jun 4, 2017 at 2:22 PM, Nicholas Piggin <npiggin@gmail.com> wrote: > > On Sat, 3 Jun 2017 17:18:39 +1000 > > Balbir Singh <bsingharora@gmail.com> wrote: > > > >> For CONFIG_STRICT_KERNEL_RWX align __init_begin to 16M. > >> We use 16M since its the larger of 2M on radix and 16M > >> on hash for our linear mapping. The plan is to have > >> .text, .rodata and everything upto __init_begin marked > >> as RX. Note we still have executable read only data. > >> We could further align read only data to another 16M > >> boundary, but then the linker starts using stubs and > >> that breaks our assembler code in head_64.S > > > > Is this still the case with powerpc next? > > > > Sorry, no, I was on linux-next for testing, but I think your linker > stub patches went in very recently. I'll rebase on top and test, That would be good. I'd like to make sure the linker stub workaround does work for your case. > but I am not sure if I want two 16M alignments and bloat the size > of vmlinux. But I'll double check what happens Maybe it could be an option. Thanks, Nick
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S index ace6b65..b1a2505 100644 --- a/arch/powerpc/kernel/vmlinux.lds.S +++ b/arch/powerpc/kernel/vmlinux.lds.S @@ -8,6 +8,12 @@ #include <asm/cache.h> #include <asm/thread_info.h> +#ifdef CONFIG_STRICT_KERNEL_RWX +#define STRICT_ALIGN_SIZE (1 << 24) +#else +#define STRICT_ALIGN_SIZE PAGE_SIZE +#endif + ENTRY(_stext) PHDRS { @@ -123,7 +129,7 @@ SECTIONS PROVIDE32 (etext = .); /* Read-only data */ - RODATA + RO_DATA(PAGE_SIZE) EXCEPTION_TABLE(0) @@ -140,7 +146,7 @@ SECTIONS /* * Init sections discarded at runtime */ - . = ALIGN(PAGE_SIZE); + . = ALIGN(STRICT_ALIGN_SIZE); __init_begin = .; INIT_TEXT_SECTION(PAGE_SIZE) :kernel
For CONFIG_STRICT_KERNEL_RWX align __init_begin to 16M. We use 16M since its the larger of 2M on radix and 16M on hash for our linear mapping. The plan is to have .text, .rodata and everything upto __init_begin marked as RX. Note we still have executable read only data. We could further align read only data to another 16M boundary, but then the linker starts using stubs and that breaks our assembler code in head_64.S We don't use multi PT_LOAD in PHDRS because we are not sure if all bootloaders support them Signed-off-by: Balbir Singh <bsingharora@gmail.com> --- arch/powerpc/kernel/vmlinux.lds.S | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)