lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 24 Jun 2022 15:17:14 +0200 From: Ard Biesheuvel <ardb@...nel.org> To: Will Deacon <will@...nel.org> Cc: Linux ARM <linux-arm-kernel@...ts.infradead.org>, linux-hardening@...r.kernel.org, Marc Zyngier <maz@...nel.org>, Mark Rutland <mark.rutland@....com>, Kees Cook <keescook@...omium.org>, Catalin Marinas <catalin.marinas@....com>, Mark Brown <broonie@...nel.org>, Anshuman Khandual <anshuman.khandual@....com> Subject: Re: [PATCH v4 20/26] arm64: head: avoid relocating the kernel twice for KASLR On Fri, 24 Jun 2022 at 15:16, Will Deacon <will@...nel.org> wrote: > > On Mon, Jun 13, 2022 at 04:45:44PM +0200, Ard Biesheuvel wrote: > > Currently, when KASLR is in effect, we set up the kernel virtual address > > space twice: the first time, the KASLR seed is looked up in the device > > tree, and the kernel virtual mapping is torn down and recreated again, > > after which the relocations are applied a second time. The latter step > > means that statically initialized global pointer variables will be reset > > to their initial values, and to ensure that BSS variables are not set to > > values based on the initial translation, they are cleared again as well. > > > > All of this is needed because we need the command line (taken from the > > DT) to tell us whether or not to randomize the virtual address space > > before entering the kernel proper. However, this code has expanded > > little by little and now creates global state unrelated to the virtual > > randomization of the kernel before the mapping is torn down and set up > > again, and the BSS cleared for a second time. This has created some > > issues in the past, and it would be better to avoid this little dance if > > possible. > > > > So instead, let's use the temporary mapping of the device tree, and > > execute the bare minimum of code to decide whether or not KASLR should > > be enabled, and what the seed is. Only then, create the virtual kernel > > mapping, clear BSS, etc and proceed as normal. This avoids the issues > > around inconsistent global state due to BSS being cleared twice, and is > > generally more maintainable, as it permits us to defer all the remaining > > DT parsing and KASLR initialization to a later time. > > > > This means the relocation fixup code runs only a single time as well, > > allowing us to simplify the RELR handling code too, which is not > > idempotent and was therefore required to keep track of the offset that > > was applied the first time around. > > > > Note that this means we have to clone a pair of FDT library objects, so > > that we can control how they are built - we need the stack protector > > and other instrumentation disabled so that the code can tolerate being > > called this early. Note that only the kernel page tables and the > > temporary stack are mapped read-write at this point, which ensures that > > the early code does not modify any global state inadvertently. > > > > Signed-off-by: Ard Biesheuvel <ardb@...nel.org> > > --- > > arch/arm64/kernel/Makefile | 2 +- > > arch/arm64/kernel/head.S | 73 ++++--------- > > arch/arm64/kernel/image-vars.h | 4 + > > arch/arm64/kernel/kaslr.c | 87 --------------- > > arch/arm64/kernel/pi/Makefile | 33 ++++++ > > arch/arm64/kernel/pi/kaslr_early.c | 112 ++++++++++++++++++++ > > Heh, how long before we get a decompressor in here too? > Right after BPF support :-)
Powered by blists - more mailing lists