patches.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>,
	Sami Mujawar <sami.mujawar@arm.com>,
	Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
	Steven Price <steven.price@arm.com>,
	Gavin Shan <gshan@redhat.com>, Sasha Levin <sashal@kernel.org>
Subject: [PATCH AUTOSEL 6.17-6.16] arm64: realm: ioremap: Allow mapping memory as encrypted
Date: Thu,  2 Oct 2025 11:29:55 -0400	[thread overview]
Message-ID: <20251002153025.2209281-8-sashal@kernel.org> (raw)
In-Reply-To: <20251002153025.2209281-1-sashal@kernel.org>

From: Suzuki K Poulose <suzuki.poulose@arm.com>

[ Upstream commit fa84e534c3ec2904d8718a83180294f7b5afecc7 ]

For ioremap(), so far we only checked if it was a device (RIPAS_DEV) to choose
an encrypted vs decrypted mapping. However, we may have firmware reserved memory
regions exposed to the OS (e.g., EFI Coco Secret Securityfs, ACPI CCEL).
We need to make sure that anything that is RIPAS_RAM (i.e., Guest
protected memory with RMM guarantees) are also mapped as encrypted.

Rephrasing the above, anything that is not RIPAS_EMPTY is guaranteed to be
protected by the RMM. Thus we choose encrypted mapping for anything that is not
RIPAS_EMPTY. While at it, rename the helper function

  __arm64_is_protected_mmio => arm64_rsi_is_protected

to clearly indicate that this not an arm64 generic helper, but something to do
with Realms.

Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
Cc: Steven Price <steven.price@arm.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Tested-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Based on my comprehensive analysis of this commit, I can now provide my
determination.

## Analysis Summary

### Code Change Analysis

The commit makes a **critical logic change** in
`arch/arm64/kernel/rsi.c:104`:

**Before**: `if (ripas != RSI_RIPAS_DEV) break;`
- Only returns true if **all** regions are RIPAS_DEV (device memory)
- Other states (RIPAS_RAM, RIPAS_DESTROYED) cause early exit → mapped as
  **decrypted**

**After**: `if (ripas == RSI_RIPAS_EMPTY) break;`
- Returns true for RIPAS_RAM, RIPAS_DESTROYED, and RIPAS_DEV
- Only RIPAS_EMPTY (unprotected/shared) regions are mapped as
  **decrypted**

### Problem Being Fixed

The original implementation from commit 371589437616f (Oct 2024) only
encrypted RIPAS_DEV regions. However, **firmware-reserved memory
regions** use RIPAS_RAM state:

- **EFI Coco Secret Securityfs** areas
- **ACPI CCEL** (Confidential Computing Event Log) tables

Without this fix, these RIPAS_RAM regions are incorrectly mapped with
`pgprot_decrypted()`, which sets `PROT_NS_SHARED`, making them
**accessible to the untrusted hypervisor**.

### Security Impact

This is a **security and data integrity bug**:
1. **Confidential data leakage**: Hypervisor can read protected firmware
   secrets
2. **Data corruption**: Hypervisor can modify what should be protected
   memory
3. **Violation of ARM CCA guarantees**: Breaks confidential computing
   promises

### Dependencies

Two related commits were **already backported** (based on "Upstream
commit" tags):
- `bda90416d53f`: "arm64: Enable EFI secret area Securityfs support"
- `09b8e2bf3bf1`: "arm64: acpi: Enable ACPI CCEL support"

Both depend on this fix to function correctly.

### Risk Assessment

**LOW RISK**:
- Isolated to ARM64 Realm subsystem (v6.13+)
- Only affects ARM CCA Realm guests
- Simple, well-understood logic inversion
- Multiple reviewers (Gavin Shan, Steven Price) and testers (Sami
  Mujawar)
- No follow-up fixes or reverts found
- Function rename improves code clarity

### Stable Tree Rules

✅ Fixes important security/correctness bug
✅ Small and contained (3 files, ~30 lines)
✅ No new features or architectural changes
✅ Minimal regression risk
✅ Well-tested and reviewed

---

## **Answer: YES**

**This commit should be backported to stable kernel trees that include
ARM64 Realm support (v6.13+).**

**Rationale**: This fixes a security vulnerability where firmware-
reserved protected memory (RIPAS_RAM) is incorrectly mapped as decrypted
instead of encrypted, violating ARM CCA confidential computing
guarantees. The bug allows the untrusted hypervisor to access or corrupt
protected firmware data (EFI secrets, ACPI CCEL tables). The fix is
small, contained, well-tested, and has minimal regression risk.
Additionally, two dependent features (EFI Secret and ACPI CCEL support)
were already backported and require this fix to work correctly.

 arch/arm64/include/asm/io.h  |  2 +-
 arch/arm64/include/asm/rsi.h |  2 +-
 arch/arm64/kernel/rsi.c      | 26 ++++++++++++++++++++++----
 3 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 9b96840fb979b..82276282a3c72 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -311,7 +311,7 @@ extern bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
 static inline bool arm64_is_protected_mmio(phys_addr_t phys_addr, size_t size)
 {
 	if (unlikely(is_realm_world()))
-		return __arm64_is_protected_mmio(phys_addr, size);
+		return arm64_rsi_is_protected(phys_addr, size);
 	return false;
 }
 
diff --git a/arch/arm64/include/asm/rsi.h b/arch/arm64/include/asm/rsi.h
index b42aeac05340e..88b50d660e85a 100644
--- a/arch/arm64/include/asm/rsi.h
+++ b/arch/arm64/include/asm/rsi.h
@@ -16,7 +16,7 @@ DECLARE_STATIC_KEY_FALSE(rsi_present);
 
 void __init arm64_rsi_init(void);
 
-bool __arm64_is_protected_mmio(phys_addr_t base, size_t size);
+bool arm64_rsi_is_protected(phys_addr_t base, size_t size);
 
 static inline bool is_realm_world(void)
 {
diff --git a/arch/arm64/kernel/rsi.c b/arch/arm64/kernel/rsi.c
index ce4778141ec7b..c64a06f58c0bc 100644
--- a/arch/arm64/kernel/rsi.c
+++ b/arch/arm64/kernel/rsi.c
@@ -84,7 +84,25 @@ static void __init arm64_rsi_setup_memory(void)
 	}
 }
 
-bool __arm64_is_protected_mmio(phys_addr_t base, size_t size)
+/*
+ * Check if a given PA range is Trusted (e.g., Protected memory, a Trusted Device
+ * mapping, or an MMIO emulated in the Realm world).
+ *
+ * We can rely on the RIPAS value of the region to detect if a given region is
+ * protected.
+ *
+ *  RIPAS_DEV - A trusted device memory or a trusted emulated MMIO (in the Realm
+ *		world
+ *  RIPAS_RAM - Memory (RAM), protected by the RMM guarantees. (e.g., Firmware
+ *		reserved regions for data sharing).
+ *
+ *  RIPAS_DESTROYED is a special case of one of the above, where the host did
+ *  something without our permission and as such we can't do anything about it.
+ *
+ * The only case where something is emulated by the untrusted hypervisor or is
+ * backed by shared memory is indicated by RSI_RIPAS_EMPTY.
+ */
+bool arm64_rsi_is_protected(phys_addr_t base, size_t size)
 {
 	enum ripas ripas;
 	phys_addr_t end, top;
@@ -101,18 +119,18 @@ bool __arm64_is_protected_mmio(phys_addr_t base, size_t size)
 			break;
 		if (WARN_ON(top <= base))
 			break;
-		if (ripas != RSI_RIPAS_DEV)
+		if (ripas == RSI_RIPAS_EMPTY)
 			break;
 		base = top;
 	}
 
 	return base >= end;
 }
-EXPORT_SYMBOL(__arm64_is_protected_mmio);
+EXPORT_SYMBOL(arm64_rsi_is_protected);
 
 static int realm_ioremap_hook(phys_addr_t phys, size_t size, pgprot_t *prot)
 {
-	if (__arm64_is_protected_mmio(phys, size))
+	if (arm64_rsi_is_protected(phys, size))
 		*prot = pgprot_encrypted(*prot);
 	else
 		*prot = pgprot_decrypted(*prot);
-- 
2.51.0


  parent reply	other threads:[~2025-10-02 15:30 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-02 15:29 [PATCH AUTOSEL 6.17-5.4] hfs: fix KMSAN uninit-value issue in hfs_find_set_zero_bits() Sasha Levin
2025-10-02 15:29 ` [PATCH AUTOSEL 6.17-6.12] arm64: sysreg: Correct sign definitions for EIESB and DoubleLock Sasha Levin
2025-10-02 15:29 ` [PATCH AUTOSEL 6.17-5.4] hfs: clear offset and space out of valid records in b-tree node Sasha Levin
2025-10-02 15:29 ` [PATCH AUTOSEL 6.17-5.4] hfsplus: return EIO when type of hidden directory mismatch in hfsplus_fill_super() Sasha Levin
2025-10-02 15:29 ` [PATCH AUTOSEL 6.17-6.1] powerpc/32: Remove PAGE_KERNEL_TEXT to fix startup failure Sasha Levin
2025-10-02 15:29 ` [PATCH AUTOSEL 6.17-5.4] m68k: bitops: Fix find_*_bit() signatures Sasha Levin
2025-10-02 15:29 ` [PATCH AUTOSEL 6.17] smb: client: make use of ib_wc_status_msg() and skip IB_WC_WR_FLUSH_ERR logging Sasha Levin
2025-10-02 15:29 ` Sasha Levin [this message]
2025-10-02 16:43   ` [PATCH AUTOSEL 6.17-6.16] arm64: realm: ioremap: Allow mapping memory as encrypted Suzuki K Poulose
2025-10-21 15:38     ` Sasha Levin
2025-10-02 15:29 ` [PATCH AUTOSEL 6.17-6.12] gfs2: Fix unlikely race in gdlm_put_lock Sasha Levin
2025-10-02 15:29 ` [PATCH AUTOSEL 6.17-6.1] smb: server: let smb_direct_flush_send_list() invalidate a remote key first Sasha Levin
2025-10-02 15:29 ` [PATCH AUTOSEL 6.17-5.15] nios2: ensure that memblock.current_limit is set when setting pfn limits Sasha Levin
2025-10-02 15:29 ` [PATCH AUTOSEL 6.17-6.12] s390/mm: Use __GFP_ACCOUNT for user page table allocations Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-6.16] riscv: mm: Return intended SATP mode for noXlvl options Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-6.16] gfs2: Fix LM_FLAG_TRY* logic in add_to_queue Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-6.16] dlm: move to rinfo for all middle conversion cases Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-5.4] hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat() Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-5.4] exec: Fix incorrect type for ret Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-5.4] hfsplus: fix KMSAN uninit-value issue in __hfsplus_ext_cache_extent() Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-6.1] lkdtm: fortify: Fix potential NULL dereference on kmalloc failure Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-6.16] riscv: mm: Use mmu-type from FDT to limit SATP mode Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-6.6] Unbreak 'make tools/*' for user-space targets Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-5.4] hfs: make proper initalization of struct hfs_find_data Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-5.4] hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp() Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-6.16] riscv: cpufeature: add validation for zfa, zfh and zfhmin Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-6.12] PCI: Test for bit underflow in pcie_set_readrq() Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-6.16] s390/pkey: Forward keygenflags to ep11_unwrapkey Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-6.6] drivers/perf: hisi: Relax the event ID check in the framework Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-5.4] hfs: validate record offset in hfsplus_bmap_alloc Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17] smb: client: limit the range of info->receive_credit_target Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-5.4] dlm: check for defined force value in dlm_lockspace_release Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-6.12] binfmt_elf: preserve original ELF e_flags for core dumps Sasha Levin
2025-10-02 15:58   ` Kees Cook
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-6.16] arm64: errata: Apply workarounds for Neoverse-V3AE Sasha Levin
2025-10-02 15:30 ` [PATCH AUTOSEL 6.17-6.16] smb: client: queue post_recv_credits_work also if the peer raises the credit target Sasha Levin

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=20251002153025.2209281-8-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=aneesh.kumar@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=gshan@redhat.com \
    --cc=patches@lists.linux.dev \
    --cc=sami.mujawar@arm.com \
    --cc=stable@vger.kernel.org \
    --cc=steven.price@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).