|
Message-ID: <CAMj1kXGYYGRMXAa+k+ysDmfbW2XsTF56yEr8=3Q__mw_Jt4j8Q@mail.gmail.com> Date: Mon, 30 Mar 2020 14:36:25 +0200 From: Ard Biesheuvel <ardb@...nel.org> To: Mark Rutland <mark.rutland@....com> Cc: Linux ARM <linux-arm-kernel@...ts.infradead.org>, kernel-hardening@...ts.openwall.com, Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org> Subject: Re: [RFC PATCH] arm64: remove CONFIG_DEBUG_ALIGN_RODATA feature On Mon, 30 Mar 2020 at 13:29, Mark Rutland <mark.rutland@....com> wrote: > > On Sun, Mar 29, 2020 at 04:12:58PM +0200, Ard Biesheuvel wrote: > > When CONFIG_DEBUG_ALIGN_RODATA is enabled, kernel segments mapped with > > different permissions (r-x for .text, r-- for .rodata, rw- for .data, > > etc) are rounded up to 2 MiB so they can be mapped more efficiently. > > In particular, it permits the segments to be mapped using level 2 > > block entries when using 4k pages, which is expected to result in less > > TLB pressure. > > > > However, the mappings for the bulk of the kernel will use level 2 > > entries anyway, and the misaligned fringes are organized such that they > > can take advantage of the contiguous bit, and use far fewer level 3 > > entries than would be needed otherwise. > > > > This makes the value of this feature dubious at best, and since it is not > > enabled in defconfig or in the distro configs, it does not appear to be > > in wide use either. So let's just remove it. > > > > Signed-off-by: Ard Biesheuvel <ardb@...nel.org> > > No strong feelings either way, but getting rid of code is usually good, > so: > > Acked-by: Mark Rutland <mark.rutland@....com> > Thanks Mark. This is related to [0], which increases the PE/COFF section alignment to 64k so that a KASLR enabled kernel always lands at an address at which it can execute without being moved around first. This is an improvement in itself, but also provides 5 bits (log2(2M / 64k)) of wiggle room for the virtual as well as the physical placement of the kernel. CONFIG_DEBUG_ALIGN_RODATA kind of interferes with that, so I'd like to get rid of it. Catalin, Will: if you have no objections, I can include this in my series for v5.8 and take it via the EFI tree. Thanks, Ard. [0] https://lore.kernel.org/linux-efi/20200326165905.2240-1-ardb@kernel.org/
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.