On Mon, Feb 06, 2023 at 01:49:37PM +0100, Ard Biesheuvel wrote:
> UEFI v2.10 extends the EFI memory attributes table with a flag that
> indicates whether or not all RuntimeServicesCode regions were
> constructed with BTI landing pads, permitting the OS to map these
> regions with BTI restrictions enabled.
>
> So let's take this into account on arm64.
>
> Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx>
> Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx>
> ---
> arch/arm64/kernel/efi.c | 14 ++++++++++++--
> arch/arm64/kernel/traps.c | 6 ++++++
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index 78ffd5aaddcbbaee..99971cd349f36310 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
> @@ -96,15 +96,23 @@ int __init efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md)
> return 0;
> }
>
> +struct set_perm_data {
> + const efi_memory_desc_t *md;
> + bool has_bti;
> +};
> +
> static int __init set_permissions(pte_t *ptep, unsigned long addr, void *data)
> {
> - efi_memory_desc_t *md = data;
> + struct set_perm_data *spd = data;
> + const efi_memory_desc_t *md = spd->md;
> pte_t pte = READ_ONCE(*ptep);
>
> if (md->attribute & EFI_MEMORY_RO)
> pte = set_pte_bit(pte, __pgprot(PTE_RDONLY));
> if (md->attribute & EFI_MEMORY_XP)
> pte = set_pte_bit(pte, __pgprot(PTE_PXN));
> + else if (system_supports_bti() && spd->has_bti)
system_supports_bti() seems to check CONFIG_ARM64_BTI rather than
CONFIG_ARM64_BTI_KERNEL. In theory, I think this means we could have
mismatched BTI support, so it might be slightly more robust to use the
latter option here even thought the runtime services aren't kernel code.
What do you think?
Will
