[4/4] efi/arm64: unmap the kernel while executing UEFI services

Message ID 20180125103131.19168-5-ard.biesheuvel@linaro.org
State New
Headers show
Series
  • efi/arm64: unmap the kernel during runtime service calls
Related show

Commit Message

Ard Biesheuvel Jan. 25, 2018, 10:31 a.m.
Now that all UEFI runtime service wrappers ensure that byref
arguments are moved into the UEFI marshalling buffer (which
is not part of the kernel mapping), we can proceed and unmap
the kernel while UEFI runtime service calls are in progress.

This is done by setting the EPD1 bit and flushing the TLB of
the local CPU. This makes it independent of KPTI or whether
non-global mappings are being used.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

---
 arch/arm64/kernel/efi-rt-wrapper.S | 22 ++++++++++++++++++++
 1 file changed, 22 insertions(+)

-- 
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

Comments

Will Deacon Jan. 26, 2018, 5:05 p.m. | #1
On Thu, Jan 25, 2018 at 10:31:31AM +0000, Ard Biesheuvel wrote:
> Now that all UEFI runtime service wrappers ensure that byref

> arguments are moved into the UEFI marshalling buffer (which

> is not part of the kernel mapping), we can proceed and unmap

> the kernel while UEFI runtime service calls are in progress.

> 

> This is done by setting the EPD1 bit and flushing the TLB of

> the local CPU. This makes it independent of KPTI or whether

> non-global mappings are being used.


One snag with this is that it will break SPE, so I'd prefer this behaviour
to be predicated on kpti so that the arm64_kernel_unmapped_at_el0() check
in drivers/perf/arm_spe_pmu.c remains valid.

Will
--
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
Ard Biesheuvel Jan. 26, 2018, 5:06 p.m. | #2
On 26 January 2018 at 17:05, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Jan 25, 2018 at 10:31:31AM +0000, Ard Biesheuvel wrote:

>> Now that all UEFI runtime service wrappers ensure that byref

>> arguments are moved into the UEFI marshalling buffer (which

>> is not part of the kernel mapping), we can proceed and unmap

>> the kernel while UEFI runtime service calls are in progress.

>>

>> This is done by setting the EPD1 bit and flushing the TLB of

>> the local CPU. This makes it independent of KPTI or whether

>> non-global mappings are being used.

>

> One snag with this is that it will break SPE, so I'd prefer this behaviour

> to be predicated on kpti so that the arm64_kernel_unmapped_at_el0() check

> in drivers/perf/arm_spe_pmu.c remains valid.

>


The problem with that is that they serve two different purposes: kpti
protects against meltdown, this protects against Spectre variant 1.
--
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
Will Deacon Jan. 26, 2018, 5:10 p.m. | #3
On Fri, Jan 26, 2018 at 05:06:42PM +0000, Ard Biesheuvel wrote:
> On 26 January 2018 at 17:05, Will Deacon <will.deacon@arm.com> wrote:

> > On Thu, Jan 25, 2018 at 10:31:31AM +0000, Ard Biesheuvel wrote:

> >> Now that all UEFI runtime service wrappers ensure that byref

> >> arguments are moved into the UEFI marshalling buffer (which

> >> is not part of the kernel mapping), we can proceed and unmap

> >> the kernel while UEFI runtime service calls are in progress.

> >>

> >> This is done by setting the EPD1 bit and flushing the TLB of

> >> the local CPU. This makes it independent of KPTI or whether

> >> non-global mappings are being used.

> >

> > One snag with this is that it will break SPE, so I'd prefer this behaviour

> > to be predicated on kpti so that the arm64_kernel_unmapped_at_el0() check

> > in drivers/perf/arm_spe_pmu.c remains valid.

> >

> 

> The problem with that is that they serve two different purposes: kpti

> protects against meltdown, this protects against Spectre variant 1.


Fair enough, but we should do something because it renders SPE unusable
and it can be a really handy profiling feature. Having the new EFI behaviour
optional in some way would be my preference.

Will
--
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

Patch

diff --git a/arch/arm64/kernel/efi-rt-wrapper.S b/arch/arm64/kernel/efi-rt-wrapper.S
index 09e77e5edd94..70af90ef914c 100644
--- a/arch/arm64/kernel/efi-rt-wrapper.S
+++ b/arch/arm64/kernel/efi-rt-wrapper.S
@@ -9,6 +9,24 @@ 
 #include <linux/linkage.h>
 #include <asm/efi.h>
 
+	.macro	sepd1, reg
+	mrs	\reg, tcr_el1			// read Translation Control Reg
+	orr	\reg, \reg, #1 << 23		// set EPD1 bit
+	msr	tcr_el1, \reg			// write back TCR
+	isb
+	tlbi	vmalle1
+	dsb	nsh
+	.endm
+
+	.macro	cepd1, reg
+	mrs	\reg, tcr_el1			// read Translation Control Reg
+	bic	\reg, \reg, #1 << 23		// clear EPD1 bit
+	msr	tcr_el1, \reg			// write back TCR
+	isb
+	tlbi	vmalle1
+	dsb	nsh
+	.endm
+
 	.section	".rodata", "a"
 	.align		PAGE_SHIFT
 ENTRY(__efi_rt_asm_wrapper)
@@ -27,6 +45,7 @@  ENTRY(__efi_rt_asm_wrapper)
 	adr	x1, __efi_rt_vectors
 	msr	vbar_el1, x1
 	isb
+	sepd1	x1
 
 	/*
 	 * We are lucky enough that no EFI runtime services take more than
@@ -46,6 +65,7 @@  ENTRY(__efi_rt_asm_wrapper)
 	ldr	x1, 2f
 	msr	vbar_el1, x1
 	isb
+	cepd1	x1
 
 	ldp	x1, x2, [sp, #16]
 	cmp	x2, x18
@@ -63,6 +83,7 @@  ENDPROC(__efi_rt_asm_wrapper)
 	.align	7
 .Lv\@ :	stp	x29, x30, [sp, #-16]!		// preserve x29 and x30
 	mrs	x29, elr_el1			// preserve ELR
+	cepd1	x30
 	adr	x30, .Lret			// take return address
 	msr	elr_el1, x30			// set ELR to return address
 	ldr	x30, 2b				// take address of 'vectors'
@@ -76,6 +97,7 @@  ENDPROC(__efi_rt_asm_wrapper)
 	adr	x30, __efi_rt_vectors
 	msr	vbar_el1, x30
 	isb
+	sepd1	x30
 	ldp	x29, x30, [sp], #16
 	eret