From: jeremy.linton@arm•com (Jeremy Linton)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] arm64/efi: remove spurious WARN_ON for !4K kernels
Date: Wed, 25 May 2016 10:38:19 -0500 [thread overview]
Message-ID: <5745C6EB.8090004@arm.com> (raw)
In-Reply-To: <1464189116-30898-1-git-send-email-mark.rutland@arm.com>
On 05/25/2016 10:11 AM, Mark Rutland wrote:
> Since commit 1fd55a9a09b0293a ("arm64/efi: Apply strict permissions to
> UEFI Runtime Services regions"), booting a !4K page kernel results in a
> boot-time splat on some systems, due to to a WARN_ONCE added in that
> commit which fires if the base address of an EFI memory descriptor is
> not aligned to the kernel page size (which might be 4K, 16K, or 64K).
>
> On page 38 of the UEFI 2.6 specification it is stated:
>
> If a 64KiB physical page contains any 4KiB page with any of the
> following types listed below, then all 4KiB pages in the 64KiB
> page must use identical ARM Memory Page Attributes (as described
> in Table 8):
> ? EfiRuntimeServicesCode
> ? EfiRuntimeServicesData
> ? EfiReserved
> ? EfiACPIMemoryNVS
> Mixed attribute mappings within a larger page are not allowed.
>
> On page 158 of the UEFI 2.6 specification, in the description of a
> memory descriptor, the PhysicalStart and VirtualStart fields are
> mandated as being 4K aligned, with NumberOfPages describing the number
> of 4K pages in the region.
>
> No further restriction on alignment is provided in the UEFI
> specification, neither generically nor in a rule specific to AArch64.
>
> So while attributes within a naturally-aligned 64K region must be
> consistent across memory descriptors, the regions described by those
> descriptors are not mandated to be 64K aligned.
>
> Not being able to apply strict permissions is sub-optimal, and worthy of
> some notice, but it is not helpful to erroneously suggest that firmware
> is buggy, nor is it beneficial to have a noisy backtrace at boot time.
>
> This patch downgrades the WARN_ONCE to a pr_warn_once, and re-words the
> message to also describe the implication of the insufficient alignment.
I've been seeing this a lot, and this should help to lower the noise level.
Reviewed-by: Jeremy Linton <jeremy.linton@arm•com>
Thanks,
>
> Signed-off-by: Mark Rutland <mark.rutland@arm•com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro•org>
> Cc: Catalin Marinas <catalin.marinas@arm•com>
> Cc: Jeremy Linton <jeremy.linton@arm•com>
> Cc: Leif Lindholm <leif.lindholm@linaro•org>
> Cc: Matt Fleming <matt@codeblueprint•co.uk>
> Cc: Will Deacon <will.deacon@arm•com>
> Cc: linux-efi at vger.kernel.org
> ---
> arch/arm64/kernel/efi.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index 78f5248..95e748e 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
> @@ -30,14 +30,15 @@ static __init pteval_t create_mapping_protection(efi_memory_desc_t *md)
> if (type == EFI_MEMORY_MAPPED_IO)
> return PROT_DEVICE_nGnRE;
>
> - if (WARN_ONCE(!PAGE_ALIGNED(md->phys_addr),
> - "UEFI Runtime regions are not aligned to 64 KB -- buggy firmware?"))
> + if (!PAGE_ALIGNED(md->phys_addr)) {
> + pr_warn_once("UEFI Runtime regions insufficiently aligned for strict permissions\n");
> /*
> * If the region is not aligned to the page size of the OS, we
> * can not use strict permissions, since that would also affect
> * the mapping attributes of the adjacent regions.
> */
> return pgprot_val(PAGE_KERNEL_EXEC);
> + }
>
> /* R-- */
> if ((attr & (EFI_MEMORY_XP | EFI_MEMORY_RO)) ==
>
next prev parent reply other threads:[~2016-05-25 15:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-25 15:11 [PATCH] arm64/efi: remove spurious WARN_ON for !4K kernels Mark Rutland
2016-05-25 15:23 ` Ard Biesheuvel
2016-05-25 16:12 ` Mark Rutland
2016-05-25 18:23 ` Ard Biesheuvel
2016-05-26 10:56 ` Mark Rutland
2016-06-03 15:50 ` Ard Biesheuvel
2016-05-25 15:31 ` Catalin Marinas
2016-05-25 15:38 ` Jeremy Linton [this message]
2016-05-30 21:12 ` Matt Fleming
2016-06-03 10:00 ` Will Deacon
2016-06-17 21:16 ` Matt Fleming
2016-06-23 13:17 ` Mark Rutland
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=5745C6EB.8090004@arm.com \
--to=jeremy.linton@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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