From: sashiko-bot@kernel.org
To: "Sebastian Ene" <sebastianene@google.com>
Cc: "Oliver Upton" <oupton@kernel.org>,
"Marc Zyngier" <maz@kernel.org>,
kvmarm@lists.linux.dev
Subject: Re: [PATCH v2 03/13] KVM: arm64: Support host MMIO trap handlers for unmapped devices
Date: Fri, 07 Aug 2026 17:03:16 +0000 [thread overview]
Message-ID: <20260807170316.7474C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260807164322.2970811-5-sebastianene@google.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Host MMIO trap handler fails to properly mask, sign-extend, and truncate register values during emulation.
- [Medium] Unconditional 4-byte instruction skip breaks AArch32 EL0 Thumb execution.
--
--- Patch [3]: [PATCH v2 03/13] KVM: arm64: Support host MMIO trap handlers for unmapped devices ---
commit 4f82f551a35a497988ae3208761d26c15c28de61
Author: Sebastian Ene <sebastianene@google.com>
KVM: arm64: Support host MMIO trap handlers for unmapped devices
This commit introduces a stage-2 fault handler in the hypervisor to intercept
and emulate host memory accesses to unmapped or protected MMIO regions. It
hooks into handle_host_mem_abort() to check if a registered callback can handle
the access.
> diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> index 500c18c2fd48b..7e978e0c44b9e 100644
> --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
[ ... ]
> @@ -752,6 +753,50 @@ static void host_inject_mem_abort(struct kvm_cpu_context *host_ctxt)
> inject_host_exception(esr);
> }
>
> +static bool handle_host_mmio_trap(struct kvm_cpu_context *host_ctxt, u64 esr, u64 addr)
> +{
> + u64 offset, reg_value = 0, start, end;
> + u8 reg_size, reg_index;
> + bool write;
> + int i;
> +
> + for (i = 0; i < num_protected_reg; i++) {
> + if (!pkvm_protected_regs[i].pfn || !pkvm_protected_regs[i].nr_pages ||
> + !pkvm_protected_regs[i].cb)
> + continue;
> +
> + start = PFN_PHYS(pkvm_protected_regs[i].pfn);
> + end = start + PFN_PHYS(pkvm_protected_regs[i].nr_pages);
> + reg_size = BIT((esr & ESR_ELx_SAS) >> ESR_ELx_SAS_SHIFT);
> +
> + if (start > addr || addr + reg_size > end)
> + continue;
> +
> + reg_index = (esr & ESR_ELx_SRT_MASK) >> ESR_ELx_SRT_SHIFT;
> + write = (esr & ESR_ELx_WNR) == ESR_ELx_WNR;
> + offset = addr - start;
> +
> + if (write && reg_index != 31)
> + reg_value = host_ctxt->regs.regs[reg_index];
> +
> + pkvm_protected_regs[i].cb(&pkvm_protected_regs[i], offset, write,
> + ®_value, reg_size);
> +
> + if (!write && reg_index != 31)
> + host_ctxt->regs.regs[reg_index] = reg_value;
[Severity: High]
Does this emulation handle sign extension and register width properly?
When the host executes an instruction like LDRSB, shouldn't the handler inspect
the ESR_ELx_SSE (Sign Extend) bit to properly sign-extend the value? Also, for
32-bit register destinations (ESR_ELx_SF == 0), the architecture requires the
upper 32 bits to be zeroed, but it looks like this assigns the value directly.
> +
> + kvm_skip_host_instr();
[Severity: Medium]
Can this break AArch32 EL0 Thumb execution?
kvm_skip_host_instr() unconditionally adds 4 to the ELR. If the stage-2 data
abort originates from a host userspace process executing a 2-byte Thumb
instruction, shouldn't it inspect the ESR_ELx_IL bit to advance the PC by 2
bytes instead?
> + return true;
> + }
> +
> + return false;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260807164322.2970811-2-sebastianene@google.com?part=3
next prev parent reply other threads:[~2026-08-07 17:03 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 16:43 [PATCH v2 00/13] KVM: ITS hardening for pKVM Sebastian Ene
2026-08-07 16:43 ` [PATCH v2 01/13] KVM: arm64: Donate MMIO to the hypervisor Sebastian Ene
2026-08-07 16:58 ` sashiko-bot
2026-08-07 16:43 ` [PATCH v2 02/13] KVM: arm64: Track host-unmapped MMIO regions in a static array Sebastian Ene
2026-08-07 17:00 ` sashiko-bot
2026-08-07 16:43 ` [PATCH v2 03/13] KVM: arm64: Support host MMIO trap handlers for unmapped devices Sebastian Ene
2026-08-07 17:03 ` sashiko-bot [this message]
2026-08-07 16:43 ` [PATCH v2 04/13] KVM: Parse the device tree and register the ITS region with pKVM Sebastian Ene
2026-08-07 17:09 ` sashiko-bot
2026-08-07 16:43 ` [PATCH v2 05/13] irqchip/gic-v3-its: Add support for the ITS emulation setup Sebastian Ene
2026-08-07 17:00 ` sashiko-bot
2026-08-07 16:43 ` [PATCH v2 06/13] KVM: arm64: Shadow the ITS command queue and setup emulation Sebastian Ene
2026-08-07 16:57 ` sashiko-bot
2026-08-07 16:43 ` [PATCH v2 07/13] KVM: arm64: Restrict host access to the private ITS tables Sebastian Ene
2026-08-07 17:02 ` sashiko-bot
2026-08-07 16:43 ` [PATCH v2 08/13] KVM: arm64: Trap & emulate the ITS MAPD command Sebastian Ene
2026-08-07 16:57 ` sashiko-bot
2026-08-07 16:43 ` [PATCH v2 09/13] KVM: arm64: Trap & emulate the ITS MAPC command Sebastian Ene
2026-08-07 17:04 ` sashiko-bot
2026-08-07 16:43 ` [PATCH v2 10/13] KVM: arm64: Restrict host updates to GITS_CTLR Sebastian Ene
2026-08-07 17:02 ` sashiko-bot
2026-08-07 16:43 ` [PATCH v2 11/13] KVM: arm64: Prevent the host from specifying a different command queue Sebastian Ene
2026-08-07 17:28 ` sashiko-bot
2026-08-07 16:43 ` [PATCH v2 12/13] KVM: arm64: Prevent the host from programming new GITS_BASER tables Sebastian Ene
2026-08-07 17:11 ` sashiko-bot
2026-08-07 16:43 ` [PATCH v2 13/13] KVM: arm64: Implement HVC interface for ITS emulation setup Sebastian Ene
2026-08-07 17:17 ` sashiko-bot
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=20260807170316.7474C1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sebastianene@google.com \
/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