linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/4] efi/arm64: map the stack and entry wrapper into the UEFI page tables
Date: Fri, 26 Jan 2018 16:57:45 +0000	[thread overview]
Message-ID: <20180126165744.GD16008@arm.com> (raw)
In-Reply-To: <20180125103131.19168-3-ard.biesheuvel@linaro.org>

Hi Ard,

On Thu, Jan 25, 2018 at 10:31:29AM +0000, Ard Biesheuvel wrote:
> As a preparatory step towards unmapping the kernel entirely while
> executing UEFI runtime services, move the stack and the entry
> wrapper routine mappings into the EFI page tables. Also, create a
> vector table that overrides the main one while executing in the
> firmware so we will be able to remap/unmap the kernel while taking
> interrupts.

[...]

> +	.macro	ventry
> +	.align	7
> +.Lv\@ :	stp	x29, x30, [sp, #-16]!		// preserve x29 and x30
> +	mrs	x29, elr_el1			// preserve ELR
> +	adr	x30, .Lret			// take return address
> +	msr	elr_el1, x30			// set ELR to return address

Oh man, are you really doing two ERETs for a single exception, or am I
missing something?

> +	ldr	x30, 2b				// take address of 'vectors'
> +	msr	vbar_el1, x30			// set VBAR to 'vectors'
> +	isb
> +	add	x30, x30, #.Lv\@ - __efi_rt_vectors
> +	br	x30
> +	.endm
> +
> +.Lret:	msr	elr_el1, x29

If you take an IRQ here, aren't you toast?

> +	adr	x30, __efi_rt_vectors
> +	msr	vbar_el1, x30
> +	isb
> +	ldp	x29, x30, [sp], #16
> +	eret
> +
> +	.align	11
> +__efi_rt_vectors:
> +	.rept	8
> +	ventry
> +	.endr

Have you thought about SDEI at all? I can't see any code here to handle
that.

> +	/*
> +	 * EFI runtime services never drop to EL0, so the
> +	 * remaining vector table entries are not needed.
> +	 */
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index af4f943cffac..68c920b2f4f0 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
> @@ -130,3 +130,27 @@ asmlinkage efi_status_t efi_handle_corrupted_x18(efi_status_t s, const char *f)
>  	pr_err_ratelimited(FW_BUG "register x18 corrupted by EFI %s\n", f);
>  	return s;
>  }
> +
> +bool on_efi_stack(unsigned long sp)
> +{
> +	return sp >= EFI_STACK_BASE && sp < (EFI_STACK_BASE + EFI_STACK_SIZE);
> +}
> +
> +int __init efi_allocate_runtime_regions(struct mm_struct *mm)
> +{
> +	static u8 stack[EFI_STACK_SIZE] __page_aligned_bss;

Probably just me, but the use of a function static variable in a function
annotated with __init just makes me feel uneasy. Could we move it out into
wider scope?

> +
> +	/* map the stack */
> +	create_pgd_mapping(mm, __pa_symbol(stack),
> +			   EFI_STACK_BASE, EFI_STACK_SIZE,
> +			   __pgprot(pgprot_val(PAGE_KERNEL) | PTE_NG),
> +			   false);
> +
> +	/* map the runtime wrapper pivot function */
> +	create_pgd_mapping(mm, __pa_symbol(__efi_rt_asm_wrapper),
> +			   EFI_CODE_BASE, EFI_CODE_SIZE,
> +			   __pgprot(pgprot_val(PAGE_KERNEL_ROX) | PTE_NG),
> +			   false);
> +
> +	return 0;
> +}
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index b34e717d7597..3bab6c60a12b 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -204,6 +204,7 @@ alternative_if ARM64_HAS_PAN
>  alternative_else_nop_endif
>  
>  	.if	\el != 0
> +	tbz	x21, #63, 1f			// skip if TTBR0 covers the stack

So this is really a "detect EFI" check, right? Maybe comment it as such.
Also, probably want to check bit 55 just in case tagging ever takes off.

Will

  reply	other threads:[~2018-01-26 16:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-25 10:31 [PATCH 0/4] efi/arm64: unmap the kernel during runtime service calls Ard Biesheuvel
2018-01-25 10:31 ` [PATCH 1/4] efi: arm64: Check whether x18 is preserved by runtime services calls Ard Biesheuvel
2018-01-26 15:05   ` Will Deacon
2018-01-25 10:31 ` [PATCH 2/4] efi/arm64: map the stack and entry wrapper into the UEFI page tables Ard Biesheuvel
2018-01-26 16:57   ` Will Deacon [this message]
2018-01-26 17:03     ` Ard Biesheuvel
2018-01-26 17:09       ` Will Deacon
2018-01-25 10:31 ` [PATCH 3/4] efi/arm64: marshall runtime services arguments via buffer in TTBR0 Ard Biesheuvel
2018-01-25 10:31 ` [PATCH 4/4] efi/arm64: unmap the kernel while executing UEFI services Ard Biesheuvel
2018-01-26 17:05   ` Will Deacon
2018-01-26 17:06     ` Ard Biesheuvel
2018-01-26 17:10       ` Will Deacon
2018-01-29 14:51 ` [PATCH 0/4] efi/arm64: unmap the kernel during runtime service calls Jeffrey Hugo
2018-01-29 14:55   ` 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=20180126165744.GD16008@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).