| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <abec92a5-0158-4d97-bfdc-03e805a4c96b@redhat.com>
Date: Tue, 4 Mar 2025 14:52:51 +1000
From: Gavin Shan <gshan@...hat.com>
To: Steven Price <steven.price@....com>, kvm@...r.kernel.org,
kvmarm@...ts.linux.dev
Cc: Catalin Marinas <catalin.marinas@....com>, Marc Zyngier <maz@...nel.org>,
Will Deacon <will@...nel.org>, James Morse <james.morse@....com>,
Oliver Upton <oliver.upton@...ux.dev>,
Suzuki K Poulose <suzuki.poulose@....com>, Zenghui Yu
<yuzenghui@...wei.com>, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, Joey Gouly <joey.gouly@....com>,
Alexandru Elisei <alexandru.elisei@....com>,
Christoffer Dall <christoffer.dall@....com>, Fuad Tabba <tabba@...gle.com>,
linux-coco@...ts.linux.dev,
Ganapatrao Kulkarni <gankulkarni@...amperecomputing.com>,
Shanker Donthineni <sdonthineni@...dia.com>, Alper Gun
<alpergun@...gle.com>, "Aneesh Kumar K . V" <aneesh.kumar@...nel.org>
Subject: Re: [PATCH v7 19/45] KVM: arm64: Handle realm MMIO emulation
On 2/14/25 2:13 AM, Steven Price wrote:
> MMIO emulation for a realm cannot be done directly with the VM's
> registers as they are protected from the host. However, for emulatable
> data aborts, the RMM uses GPRS[0] to provide the read/written value.
> We can transfer this from/to the equivalent VCPU's register entry and
> then depend on the generic MMIO handling code in KVM.
>
> For a MMIO read, the value is placed in the shared RecExit structure
> during kvm_handle_mmio_return() rather than in the VCPU's register
> entry.
>
> Signed-off-by: Steven Price <steven.price@....com>
> ---
> Changes since v5:
> * Inject SEA to the guest is an emulatable MMIO access triggers a data
> abort.
> * kvm_handle_mmio_return() - disable kvm_incr_pc() for a REC (as the PC
> isn't under the host's control) and move the REC_ENTER_EMULATED_MMIO
> flag setting to this location (as that tells the RMM to skip the
> instruction).
> ---
> arch/arm64/kvm/inject_fault.c | 4 +++-
> arch/arm64/kvm/mmio.c | 16 ++++++++++++----
> arch/arm64/kvm/rme-exit.c | 6 ++++++
> 3 files changed, 21 insertions(+), 5 deletions(-)
>
One nitpick below, with it addressed:
Reviewed-by: Gavin Shan <gshan@...hat.com>
> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> index a640e839848e..2a9682b9834f 100644
> --- a/arch/arm64/kvm/inject_fault.c
> +++ b/arch/arm64/kvm/inject_fault.c
> @@ -165,7 +165,9 @@ static void inject_abt32(struct kvm_vcpu *vcpu, bool is_pabt, u32 addr)
> */
> void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr)
> {
> - if (vcpu_el1_is_32bit(vcpu))
> + if (unlikely(vcpu_is_rec(vcpu)))
> + vcpu->arch.rec.run->enter.flags |= REC_ENTER_FLAG_INJECT_SEA;
> + else if (vcpu_el1_is_32bit(vcpu))
> inject_abt32(vcpu, false, addr);
> else
> inject_abt64(vcpu, false, addr);
> diff --git a/arch/arm64/kvm/mmio.c b/arch/arm64/kvm/mmio.c
> index ab365e839874..bff89d47a4d5 100644
> --- a/arch/arm64/kvm/mmio.c
> +++ b/arch/arm64/kvm/mmio.c
> @@ -6,6 +6,7 @@
>
> #include <linux/kvm_host.h>
> #include <asm/kvm_emulate.h>
> +#include <asm/rmi_smc.h>
> #include <trace/events/kvm.h>
>
> #include "trace.h"
> @@ -136,14 +137,21 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu)
> trace_kvm_mmio(KVM_TRACE_MMIO_READ, len, run->mmio.phys_addr,
> &data);
> data = vcpu_data_host_to_guest(vcpu, data, len);
> - vcpu_set_reg(vcpu, kvm_vcpu_dabt_get_rd(vcpu), data);
> +
> + if (vcpu_is_rec(vcpu))
> + vcpu->arch.rec.run->enter.gprs[0] = data;
> + else
> + vcpu_set_reg(vcpu, kvm_vcpu_dabt_get_rd(vcpu), data);
> }
>
> /*
> * The MMIO instruction is emulated and should not be re-executed
> * in the guest.
> */
> - kvm_incr_pc(vcpu);
> + if (vcpu_is_rec(vcpu))
> + vcpu->arch.rec.run->enter.flags |= REC_ENTER_FLAG_EMULATED_MMIO;
> + else
> + kvm_incr_pc(vcpu);
>
> return 1;
> }
> @@ -162,14 +170,14 @@ int io_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa)
> * No valid syndrome? Ask userspace for help if it has
> * volunteered to do so, and bail out otherwise.
> *
> - * In the protected VM case, there isn't much userspace can do
> + * In the protected/realm VM case, there isn't much userspace can do
> * though, so directly deliver an exception to the guest.
> */
> if (!kvm_vcpu_dabt_isvalid(vcpu)) {
> trace_kvm_mmio_nisv(*vcpu_pc(vcpu), kvm_vcpu_get_esr(vcpu),
> kvm_vcpu_get_hfar(vcpu), fault_ipa);
>
> - if (vcpu_is_protected(vcpu)) {
> + if (vcpu_is_protected(vcpu) || vcpu_is_rec(vcpu)) {
> kvm_inject_dabt(vcpu, kvm_vcpu_get_hfar(vcpu));
> return 1;
> }
> diff --git a/arch/arm64/kvm/rme-exit.c b/arch/arm64/kvm/rme-exit.c
> index aae1adefe1a3..c785005f821f 100644
> --- a/arch/arm64/kvm/rme-exit.c
> +++ b/arch/arm64/kvm/rme-exit.c
> @@ -25,6 +25,12 @@ static int rec_exit_reason_notimpl(struct kvm_vcpu *vcpu)
>
> static int rec_exit_sync_dabt(struct kvm_vcpu *vcpu)
> {
> + struct realm_rec *rec = &vcpu->arch.rec;
> +
> + if (kvm_vcpu_dabt_iswrite(vcpu) && kvm_vcpu_dabt_isvalid(vcpu))
> + vcpu_set_reg(vcpu, kvm_vcpu_dabt_get_rd(vcpu),
> + rec->run->exit.gprs[0]);
> +
A comment may be needed to explain why GPR[0] has to be copied over. The contexnt
in GPR[0] isn't needed by all cases, being handled by kvm_handle_guest_abort().
Something like below.
/*
* Copy over GPR[0] to the target GPR, preparing to handle MMIO write
* fault. The content to be written has been saved to GPR[0] by RMM.
* It's overhead to other cases like fault due to MMIO read, shared
* or private space access.
*/
> return kvm_handle_guest_abort(vcpu);
> }
>
Thanks,
Gavin
Powered by blists - more mailing lists