Linux KVM/arm64 development list
 help / color / mirror / Atom feed
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,
> +					  &reg_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

  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