From: sashiko-bot@kernel.org
To: "Sven Peter" <sven@kernel.org>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH RFC 4/6] arm64/efi: Honor EFI_MEMORY_ISA_MASK for Device-nGnRnE vs -nGnRE
Date: Wed, 08 Jul 2026 07:33:09 +0000 [thread overview]
Message-ID: <20260708073310.10E191F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260708-efi-psci-v1-4-9efb3abf0e4c@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Silent truncation of the 16-bit EFI_MEMORY_ISA_MASK field into a u8 variable, bypassing validation and printing misleading warnings.
--
--- Patch [4]: [PATCH RFC 4/6] arm64/efi: Honor EFI_MEMORY_ISA_MASK for Device-nGnRnE vs -nGnRE ---
commit 6b01988498665d7f9d353c79435cf09a3768a624
Author: Sven Peter <sven@kernel.org>
arm64/efi: Honor EFI_MEMORY_ISA_MASK for Device-nGnRnE vs -nGnRE
This patch updates the mapping protection for EFI MMIO regions to honor the
MAIR attributes provided in EFI_MEMORY_ISA_MASK if EFI_MEMORY_ISA_VALID is
set. It defaults to Device-nGnRE for unsupported values or when the valid bit
is absent.
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index e40885567f9e9..50ba8e9112fc8 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
[ ... ]
> @@ -38,7 +40,27 @@ static __init ptval_t create_mapping_protection(efi_memory_desc_t *md)
> u32 type = md->type;
>
> if (type == EFI_MEMORY_MAPPED_IO) {
> - pgprot_t prot = __pgprot(PROT_DEVICE_nGnRE);
> + pgprot_t prot;
> +
> + if (attr & EFI_MEMORY_ISA_VALID) {
> + u8 mair = FIELD_GET(EFI_MEMORY_ISA_MASK, attr);
[Severity: Medium]
Will this silently truncate the extracted field?
EFI_MEMORY_ISA_MASK covers 16 bits (bits 44-59). If the firmware provides an
attribute with non-zero bits in the upper 8 bits of this mask (like 0x0100),
assigning the result of FIELD_GET to a u8 will truncate it to 0x00.
This would cause the switch statement below to incorrectly match
MAIR_ATTR_DEVICE_nGnRnE (0x00) instead of falling through to the default
case. Should mair be a u16 or u32 instead?
> +
> + switch (mair) {
> + case MAIR_ATTR_DEVICE_nGnRnE:
> + prot = __pgprot(PROT_DEVICE_nGnRnE);
> + break;
> + case MAIR_ATTR_DEVICE_nGnRE:
> + prot = __pgprot(PROT_DEVICE_nGnRE);
> + break;
> + default:
> + prot = __pgprot(PROT_DEVICE_nGnRE);
> + pr_warn("unsupported MAIR attribute %#x for EFI MMIO region at 0x%llx, using Device-nGnRE\n",
> + mair, md->phys_addr);
[Severity: Medium]
If truncation occurs above, will this warning print a misleading value?
Because mair is a u8, any unsupported attributes in the upper 8 bits of the
ISA mask will be stripped out before being printed here, obscuring the actual
unsupported bits provided by the firmware.
> + break;
> + }
> + } else {
> + prot = __pgprot(PROT_DEVICE_nGnRE);
> + }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-efi-psci-v1-0-9efb3abf0e4c@kernel.org?part=4
next prev parent reply other threads:[~2026-07-08 7:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 7:15 [PATCH RFC 0/6] PSCI-via-EFI to support firmware and kernel sharing EL2 for Apple Silicon Sven Peter
2026-07-08 7:15 ` [PATCH RFC 1/6] dt-bindings: arm: psci: Add EFI conduit Sven Peter
2026-07-08 7:15 ` [PATCH RFC 2/6] arm64/efi: Add and parse custom PSCI EFI configuration table Sven Peter
2026-07-08 7:39 ` sashiko-bot
2026-07-08 7:15 ` [PATCH RFC 3/6] efi: Add EFI_MEMORY_ISA_{MASK,VALID} Sven Peter
2026-07-08 7:25 ` sashiko-bot
2026-07-08 7:15 ` [PATCH RFC 4/6] arm64/efi: Honor EFI_MEMORY_ISA_MASK for Device-nGnRnE vs -nGnRE Sven Peter
2026-07-08 7:33 ` sashiko-bot [this message]
2026-07-08 7:15 ` [PATCH RFC 5/6] firmware/psci: Add EFI runtime conduit Sven Peter
2026-07-08 7:46 ` sashiko-bot
2026-07-08 7:15 ` [PATCH RFC 6/6] arm64: dts: apple: t8103: Add PSCI and CPU idle states Sven Peter
2026-07-08 7:48 ` sashiko-bot
2026-09-03 11:34 ` [PATCH RFC 0/6] PSCI-via-EFI to support firmware and kernel sharing EL2 for Apple Silicon Ard Biesheuvel
2026-09-03 11:42 ` Mark Rutland
2026-09-03 12:15 ` Will Deacon
2026-09-03 13:25 ` Ard Biesheuvel
2026-09-03 16:26 ` Sven Peter
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=20260708073310.10E191F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sven@kernel.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.