From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 02981288C22; Mon, 19 May 2025 17:56:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747677397; cv=none; b=M3oAzh1a+ariCwZu99riD7zGiJCDinMRKw3sy3Svtjt5P8+x3yipwcfI0gjuaJGCgBBT186ea/TtBtpMm60WWOjRtWrThf4sO+bVpslV3ayIHoxkrLjObGUTYx8cpK7z72VASF5bVjCtFXM1hfLbUZAj6+HRiClDXrhKyXMa2pc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747677397; c=relaxed/simple; bh=Zs/nbbQkpFkK2+5T4O2nV9SlVAVPhYOtOGVPwHibqgo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=e7UeTtZakRqX75EQGBR1mn9FCAkW1FUSqRMj+xjSNKudHtW8/dHKEFGy5Sq4BwQlcV6ajzJMM++U2VeRuwkIUhFNV40WmMEvFR/7o+59HU5CExqdTH9/RZMEel9yfu+8xgliFoMWLPeMJwwb0X5SvSSNhALJMtGQyjQ2V0ceLHs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 22C5015A1; Mon, 19 May 2025 10:56:22 -0700 (PDT) Received: from [10.57.50.157] (unknown [10.57.50.157]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 2FFCA3F5A1; Mon, 19 May 2025 10:56:32 -0700 (PDT) Message-ID: <624d1add-c421-4782-9cbc-5cc8f1c0ce51@arm.com> Date: Mon, 19 May 2025 18:56:31 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 22/43] KVM: arm64: Validate register access for a Realm VM Content-Language: en-GB To: Steven Price , kvm@vger.kernel.org, kvmarm@lists.linux.dev Cc: Catalin Marinas , Marc Zyngier , Will Deacon , James Morse , Oliver Upton , Zenghui Yu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joey Gouly , Alexandru Elisei , Christoffer Dall , Fuad Tabba , linux-coco@lists.linux.dev, Ganapatrao Kulkarni , Gavin Shan , Shanker Donthineni , Alper Gun , "Aneesh Kumar K . V" References: <20250416134208.383984-1-steven.price@arm.com> <20250416134208.383984-23-steven.price@arm.com> From: Suzuki K Poulose In-Reply-To: <20250416134208.383984-23-steven.price@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 16/04/2025 14:41, Steven Price wrote: > The RMM only allows setting the GPRS (x0-x30) and PC for a realm > guest. Check this in kvm_arm_set_reg() so that the VMM can receive a > suitable error return if other registers are written to. > > The RMM makes similar restrictions for reading of the guest's registers > (this is *confidential* compute after all), however we don't impose the > restriction here. This allows the VMM to read (stale) values from the > registers which might be useful to read back the initial values even if > the RMM doesn't provide the latest version. For migration of a realm VM, > a new interface will be needed so that the VMM can receive an > (encrypted) blob of the VM's state. > > Signed-off-by: Steven Price > --- > Changes since v5: > * Upper GPRS can be set as part of a HOST_CALL return, so fix up the > test to allow them. > --- > arch/arm64/kvm/guest.c | 40 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 40 insertions(+) > > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c > index 2196979a24a3..ff0306650b39 100644 > --- a/arch/arm64/kvm/guest.c > +++ b/arch/arm64/kvm/guest.c > @@ -73,6 +73,24 @@ static u64 core_reg_offset_from_id(u64 id) > return id & ~(KVM_REG_ARCH_MASK | KVM_REG_SIZE_MASK | KVM_REG_ARM_CORE); > } > > +static bool kvm_realm_validate_core_reg(u64 off) > +{ > + /* > + * Note that GPRs can only sometimes be controlled by the VMM. > + * For PSCI only X0-X6 are used, higher registers are ignored (restored > + * from the REC). > + * For HOST_CALL all of X0-X30 are copied to the RsiHostCall structure. > + * For emulated MMIO X0 is always used. > + */ > + switch (off) { > + case KVM_REG_ARM_CORE_REG(regs.regs[0]) ... > + KVM_REG_ARM_CORE_REG(regs.regs[30]): May be add : /* PC can only be set before the Realm is ACTIVATED */ Either ways: Reviewed-by: Suzuki K Poulose > + case KVM_REG_ARM_CORE_REG(regs.pc): > + return true; > + } > + return false; > +} > + > static int core_reg_size_from_offset(const struct kvm_vcpu *vcpu, u64 off) > { > int size; > @@ -783,12 +801,34 @@ int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg) > return kvm_arm_sys_reg_get_reg(vcpu, reg); > } > > +/* > + * The RMI ABI only enables setting some GPRs and PC. The selection of GPRs > + * that are available depends on the Realm state and the reason for the last > + * exit. All other registers are reset to architectural or otherwise defined > + * reset values by the RMM, except for a few configuration fields that > + * correspond to Realm parameters. > + */ > +static bool validate_realm_set_reg(struct kvm_vcpu *vcpu, > + const struct kvm_one_reg *reg) > +{ > + if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_CORE) { > + u64 off = core_reg_offset_from_id(reg->id); > + > + return kvm_realm_validate_core_reg(off); > + } > + > + return false; > +} > + > int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg) > { > /* We currently use nothing arch-specific in upper 32 bits */ > if ((reg->id & ~KVM_REG_SIZE_MASK) >> 32 != KVM_REG_ARM64 >> 32) > return -EINVAL; > > + if (kvm_is_realm(vcpu->kvm) && !validate_realm_set_reg(vcpu, reg)) > + return -EINVAL; > + > switch (reg->id & KVM_REG_ARM_COPROC_MASK) { > case KVM_REG_ARM_CORE: return set_core_reg(vcpu, reg); > case KVM_REG_ARM_FW: