[0/4] efi/arm64: unmap the kernel during runtime service calls

UEFI doesn't keep any secrets, so it is mostly unaffected by Meltdown and
Spectre. At boot time, when UEFI is in charge of everything, there is
simply no point in inferring things from the cache state if you can simply
read the data. At runtime, when UEFI runs in the execution context of the
OS, it is really up to the OS to ensure that lower privilege levels cannot
access OS data structures unpermitted.

This applies equally to Spectre variant 2: UEFI runtime services are not
entered directly from userland but always via the kernel, which carries
out any required branch predictor maintenance when switching between the
various tasks (and the UEFI runtime execution context may be considered
a separate task in this sense)

Spectre variant 1 is a different matter though. It requires code changes
and software rebuilds with updated compilers to be fully hardened against
it, although nobody seems to know exactly what that means at the moment.
Given the poor track record of vendors when it comes to keeping UEFI
firmware up to date, it is highly likely that vulnerable versions will
still be in circulation long after we fixed the OS.

Since UEFI interacts with data structures that the OS may consider opaque
(capsule images, authenticated variable updates), it is not really up to
the OS to reason about which invocation is safe and which one isn't. The
only solution really is to simply unmap the entire kernel during UEFI
runtime services invocations, so that there are no secrets to steal to
begin with.

Patch #1 is included for completeness. I sent it out before, and it is a
dependency for this series, but it is otherwise unrelated.

Patch #2 creates a separate stack for UEFI and puts it in the EFI page
tables, along with the asm wrapper that invokes the UEFI runtime services
and a vector table that is activated before and deactivated after the
service is called.

Patch #3 implements marshalling of all byref arguments taken by UEFI
runtime services. This is necessary because they will refer to memory
that is going to be unmapped.

Patch #4 implements the actual unmap/remap sequences, by setting/clearing
the EPD1 bit in TCR_EL1, and doing a local TLB flush.

Note that capsule update has been omitted. This is a bit involved, and
I'd rather get some feedback before burning too many cycles on that. All
other services should be functional, with the caveat that EFI variable
names are now limited to 1024 [wide] characters, and UEFI variables
themselves to 64 KB.

Ard Biesheuvel (4):
  efi: arm64: Check whether x18 is preserved by runtime services calls
  efi/arm64: map the stack and entry wrapper into the UEFI page tables
  efi/arm64: marshall runtime services arguments via buffer in TTBR0
  efi/arm64: unmap the kernel while executing UEFI services

 arch/arm/include/asm/efi.h          |   5 +
 arch/arm64/Kconfig                  |   1 -
 arch/arm64/include/asm/efi.h        |  30 +-
 arch/arm64/include/asm/stacktrace.h |   4 +
 arch/arm64/kernel/Makefile          |   3 +-
 arch/arm64/kernel/efi-rt-wrapper.S  | 112 +++++
 arch/arm64/kernel/efi.c             | 505 +++++++++++++++++++-
 arch/arm64/kernel/entry.S           |   1 +
 drivers/firmware/efi/arm-runtime.c  |   2 +
 9 files changed, 658 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm64/kernel/efi-rt-wrapper.S

-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 1/25/2018 3:31 AM, Ard Biesheuvel wrote:

> Note that capsule update has been omitted. This is a bit involved, and

> I'd rather get some feedback before burning too many cycles on that. All

> other services should be functional, with the caveat that EFI variable

> names are now limited to 1024 [wide] characters, and UEFI variables

> themselves to 64 KB.

> 


I'm curious, why these limitations?

We don't have any concern about the name length limitation at this time, 
but the variable size one is concerning.

We have a feature which creates a variable greater than 64KB that we 
want to utilize from Linux.  The size limitation would seem to prevent that.

-- 
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 29 January 2018 at 14:51, Jeffrey Hugo <jhugo@codeaurora.org> wrote:
> On 1/25/2018 3:31 AM, Ard Biesheuvel wrote:

>

>> Note that capsule update has been omitted. This is a bit involved, and

>> I'd rather get some feedback before burning too many cycles on that. All

>> other services should be functional, with the caveat that EFI variable

>> names are now limited to 1024 [wide] characters, and UEFI variables

>> themselves to 64 KB.

>>

>

> I'm curious, why these limitations?

>


Because mapping and unmapping things on the fly in the UEFI page
tables is a bit complicated, although I need to do something of the
kind for capsules anyway, so once I solve that, we can use the same
approach for variables.

> We don't have any concern about the name length limitation at this time, but

> the variable size one is concerning.

>

> We have a feature which creates a variable greater than 64KB that we want to

> utilize from Linux.  The size limitation would seem to prevent that.

>


Well, the limit itself is rather arbitrary, and putting >64 KB into
the fault tolerant, write ahead logging NOR flash seems mildly
inappropriate to me. But you are right, the spec currently has no such
limitations, so ideally, nor should the OS.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html