All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: linux-arm-kernel@lists.infradead.org
Cc: mark.rutland@arm.com, android-kvm@google.com,
	Ard Biesheuvel <ardb@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Will Deacon <will@kernel.org>
Subject: [RFC PATCH 0/8] arm64: efi: leave MMU and caches on at boot
Date: Fri,  4 Mar 2022 18:56:49 +0100	[thread overview]
Message-ID: <20220304175657.2744400-1-ardb@kernel.org> (raw)

Currently, booting via the EFI stub involves a fair amount of cache
maintenance, as well as two attempts at setting up the page tables when
KASLR is enabled, which runs with the MMU and caches off. This may be
problematic for virtualization payloads, which sometimes have very tight
boot time budgets, and run in a context where uncached accesses to
memory are problematic, as they are incoherent with the accesses of the
host VMM or the hypervisor.

While it makes sense for the boot protocol to be pedantic in this
respect, EFI boot is tightly coupled with the core kernel, given that
the EFI stub is the de facto bootloader, which is part of the same
kernel image. It is therefore justified to cut some corners and simplify
things substantially.

As UEFI guarantees that all memory is 1:1 mapped with inner/outer
writeback cacheable attributes, there is really no need to clean the
entire kernel image to the PoC, or do all the cache invalidation that is
required to ensure that page tables and other state held in memory is
not corrupted by inadvertent writeback of stale dirty cache lines.

Since we setup and teardown page tables redundantly for KASLR, fix this
first, by permitting the KASLR seed to be passed via register X1 as well
as the /chosen/kaslr-seed property. This permits us the run the page
table setup code with the firmware's cached 1:1 mapping active, removing
the need for any cache invalidation.

Then, ensure that the only piece of code we do execute with the MMU off
in this case is cleaned to the PoC, which is all held in a single page.
(the ID map)

Finally, drop all the cache maintenance from the EFI entry code when
booting at EL1, and just branch to the kernel with the firmware's 1:1
cached mapping live.

Cc: Marc Zyngier <maz@kernel.org>
Cc: Will Deacon <will@kernel.org>

Ard Biesheuvel (8):
  arm64: kaslr: deal with init called with VA randomization enabled
  arm64: head: record the MMU state at primary entry
  arm64: head: take KASLR seed passed via x1 into account
  arm64: head: avoid cache invalidation when entering with the MMU on
  arm64: head: populate page tables before disabling the MMU
  arm64: head: clean the ID map page to the PoC
  arm64: lds: move idmap_pg_dir out of .rodata
  arm64: efi: leave MMU and caches on when handing over to the core
    kernel

 arch/arm64/kernel/efi-entry.S      | 20 ++---
 arch/arm64/kernel/head.S           | 82 +++++++++++++++++---
 arch/arm64/kernel/kaslr.c          |  8 +-
 arch/arm64/kernel/vmlinux.lds.S    |  8 +-
 drivers/firmware/efi/libstub/fdt.c |  6 +-
 5 files changed, 95 insertions(+), 29 deletions(-)

-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2022-03-04 17:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-04 17:56 Ard Biesheuvel [this message]
2022-03-04 17:56 ` [RFC PATCH 1/8] arm64: kaslr: deal with init called with VA randomization enabled Ard Biesheuvel
2022-03-04 17:56 ` [RFC PATCH 2/8] arm64: head: record the MMU state at primary entry Ard Biesheuvel
2022-03-04 17:56 ` [RFC PATCH 3/8] arm64: head: take KASLR seed passed via x1 into account Ard Biesheuvel
2022-03-04 17:56 ` [RFC PATCH 4/8] arm64: head: avoid cache invalidation when entering with the MMU on Ard Biesheuvel
2022-03-04 17:56 ` [RFC PATCH 5/8] arm64: head: populate page tables before disabling the MMU Ard Biesheuvel
2022-03-04 17:56 ` [RFC PATCH 6/8] arm64: head: clean the ID map page to the PoC Ard Biesheuvel
2022-03-04 17:56 ` [RFC PATCH 7/8] arm64: lds: move idmap_pg_dir out of .rodata Ard Biesheuvel
2022-03-04 17:56 ` [RFC PATCH 8/8] arm64: efi: leave MMU and caches on when handing over to the core kernel Ard Biesheuvel

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=20220304175657.2744400-1-ardb@kernel.org \
    --to=ardb@kernel.org \
    --cc=android-kvm@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=will@kernel.org \
    /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: link
Be 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.