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
next prev 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.