From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv6 7/8] arm64: efi: Use ioremap_exec for code sections
Date: Tue, 25 Nov 2014 17:26:44 +0000 [thread overview]
Message-ID: <20141125172644.GC21525@leverpostej> (raw)
In-Reply-To: <1416606645-25633-8-git-send-email-lauraa@codeaurora.org>
Hi Laura,
On Fri, Nov 21, 2014 at 09:50:44PM +0000, Laura Abbott wrote:
> ioremap is not guaranteed to return memory with proper
> execution permissions. Introduce ioremap_exec which will
> ensure that permission bits are set as expected for EFI
> code sections.
>
> Tested-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
> ---
> arch/arm64/include/asm/io.h | 1 +
> arch/arm64/include/asm/pgtable.h | 1 +
> arch/arm64/kernel/efi.c | 12 +++++++++++-
> arch/arm64/mm/ioremap.c | 11 +++++++++++
> 4 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 79f1d519..7dd8465 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -230,6 +230,7 @@ extern void __memset_io(volatile void __iomem *, int, size_t);
> extern void __iomem *__ioremap(phys_addr_t phys_addr, size_t size, pgprot_t prot);
> extern void __iounmap(volatile void __iomem *addr);
> extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
> +extern void __iomem *ioremap_exec(phys_addr_t phys_addr, size_t size);
>
> #define ioremap(addr, size) __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))
> #define ioremap_nocache(addr, size) __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 41a43bf..9b1d9d0 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -65,6 +65,7 @@ extern void __pgd_error(const char *file, int line, unsigned long val);
> #define PROT_DEVICE_nGnRE (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_ATTRINDX(MT_DEVICE_nGnRE))
> #define PROT_NORMAL_NC (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_ATTRINDX(MT_NORMAL_NC))
> #define PROT_NORMAL (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_ATTRINDX(MT_NORMAL))
> +#define PROT_NORMAL_EXEC (PROT_DEFAULT | PTE_UXN | PTE_ATTRINDX(MT_NORMAL))
>
> #define PROT_SECT_DEVICE_nGnRE (PROT_SECT_DEFAULT | PMD_SECT_PXN | PMD_SECT_UXN | PMD_ATTRINDX(MT_DEVICE_nGnRE))
> #define PROT_SECT_NORMAL (PROT_SECT_DEFAULT | PMD_SECT_PXN | PMD_SECT_UXN | PMD_ATTRINDX(MT_NORMAL))
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index 95c49eb..9e41f95 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
> @@ -47,6 +47,14 @@ static int __init is_normal_ram(efi_memory_desc_t *md)
> return 0;
> }
>
> +static int __init is_code(efi_memory_desc_t *md)
> +{
> + if (md->attribute & EFI_RUNTIME_SERVICES_CODE)
> + return 1;
> + return 0;
> +}
> +
> +
> static void __init efi_setup_idmap(void)
> {
> struct memblock_region *r;
> @@ -338,7 +346,9 @@ static int __init remap_region(efi_memory_desc_t *md, void **new)
> memrange_efi_to_native(&paddr, &npages);
> size = npages << PAGE_SHIFT;
>
> - if (is_normal_ram(md))
> + if (is_code(md))
> + vaddr = (__force u64)ioremap_exec(paddr, size);
> + else if (is_normal_ram(md))
> vaddr = (__force u64)ioremap_cache(paddr, size);
> else
> vaddr = (__force u64)ioremap(paddr, size);
All of the above looks fine to me.
> diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
> index cbb99c8..b998441 100644
> --- a/arch/arm64/mm/ioremap.c
> +++ b/arch/arm64/mm/ioremap.c
> @@ -103,6 +103,17 @@ void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
> }
> EXPORT_SYMBOL(ioremap_cache);
>
> +void __iomem *ioremap_exec(phys_addr_t phys_addr, size_t size)
> +{
> + /* For normal memory we already have a cacheable mapping. */
> + if (pfn_valid(__phys_to_pfn(phys_addr)))
> + return (void __iomem *)__phys_to_virt(phys_addr);
Is this guaranteed to be executable in all cases once the stricter page
permissions are in force?
Thanks,
Mark.
> +
> + return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL_EXEC),
> + __builtin_return_address(0));
> +}
> +EXPORT_SYMBOL(ioremap_exec);
> +
> /*
> * Must be called after early_fixmap_init
> */
> --
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>
>
next prev parent reply other threads:[~2014-11-25 17:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-21 21:50 [PATCHv6 0/8] Better page protections for arm64 Laura Abbott
2014-11-21 21:50 ` [PATCHv6 1/8] arm64: Treat handle_arch_irq as a function pointer Laura Abbott
2014-11-21 21:50 ` [PATCHv6 2/8] arm64: Switch to adrp for loading the stub vectors Laura Abbott
2014-11-21 21:50 ` [PATCHv6 3/8] arm64: Move cpu_resume into the text section Laura Abbott
2014-11-21 21:50 ` [PATCHv6 4/8] arm64: Move some head.text functions to executable section Laura Abbott
2014-11-26 16:30 ` Mark Rutland
2014-11-26 17:11 ` Will Deacon
2014-11-21 21:50 ` [PATCHv6 5/8] arm64: Factor out fixmap initialiation from ioremap Laura Abbott
2014-11-21 21:50 ` [PATCHv6 6/8] arm64: use fixmap for text patching when text is RO Laura Abbott
2014-11-25 17:04 ` Mark Rutland
2014-11-25 18:54 ` Laura Abbott
2014-11-26 16:18 ` Mark Rutland
2014-12-02 15:59 ` Catalin Marinas
2014-11-21 21:50 ` [PATCHv6 7/8] arm64: efi: Use ioremap_exec for code sections Laura Abbott
2014-11-25 17:26 ` Mark Rutland [this message]
2014-11-25 18:57 ` Laura Abbott
2014-12-02 17:15 ` Catalin Marinas
2014-12-02 17:20 ` Ard Biesheuvel
2014-11-21 21:50 ` [PATCHv6] arm64: add better page protections to arm64 Laura Abbott
2014-12-02 18:28 ` Catalin Marinas
2015-01-14 19:26 ` Laura Abbott
2014-11-25 15:33 ` [PATCHv6 0/8] Better page protections for arm64 Will Deacon
2014-11-25 16:32 ` Kees Cook
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=20141125172644.GC21525@leverpostej \
--to=mark.rutland@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 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.