All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	catalin.marinas-5wv7dgnIgG8@public.gmane.org,
	mark.rutland-5wv7dgnIgG8@public.gmane.org,
	marc.zyngier-5wv7dgnIgG8@public.gmane.org,
	joakim.bech-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	graeme.gregory-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
Subject: Re: [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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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

WARNING: multiple messages have this Message-ID (diff)
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

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

Thread overview: 28+ 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 ` Ard Biesheuvel
     [not found] ` <20180125103131.19168-1-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2018-01-25 10:31   ` [PATCH 1/4] efi: arm64: Check whether x18 is preserved by runtime services calls Ard Biesheuvel
2018-01-25 10:31     ` Ard Biesheuvel
     [not found]     ` <20180125103131.19168-2-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2018-01-26 15:05       ` Will Deacon
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-25 10:31     ` Ard Biesheuvel
     [not found]     ` <20180125103131.19168-3-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2018-01-26 16:57       ` Will Deacon [this message]
2018-01-26 16:57         ` Will Deacon
     [not found]         ` <20180126165744.GD16008-5wv7dgnIgG8@public.gmane.org>
2018-01-26 17:03           ` Ard Biesheuvel
2018-01-26 17:03             ` Ard Biesheuvel
     [not found]             ` <CAKv+Gu8CvZXZvxp75x5JL0dNMvEau5XuXxAObsJURs6ALU+nFg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-26 17:09               ` Will Deacon
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     ` Ard Biesheuvel
2018-01-25 10:31   ` [PATCH 4/4] efi/arm64: unmap the kernel while executing UEFI services Ard Biesheuvel
2018-01-25 10:31     ` Ard Biesheuvel
     [not found]     ` <20180125103131.19168-5-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2018-01-26 17:05       ` Will Deacon
2018-01-26 17:05         ` Will Deacon
     [not found]         ` <20180126170505.GE16008-5wv7dgnIgG8@public.gmane.org>
2018-01-26 17:06           ` Ard Biesheuvel
2018-01-26 17:06             ` Ard Biesheuvel
     [not found]             ` <CAKv+Gu84Dk1ZRicHNWr2SLn1GEpaj1YmekzgjvK4aC5t05TgSw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-26 17:10               ` Will Deacon
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:51     ` Jeffrey Hugo
     [not found]     ` <bdba264b-6619-6e9f-2849-d9d82a820ab0-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-01-29 14:55       ` Ard Biesheuvel
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-5wv7dgnigg8@public.gmane.org \
    --cc=ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
    --cc=graeme.gregory-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=joakim.bech-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.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.