linux-kernel - Re: [PATCH v8 16/43] arm64: RME: Handle realm enter/exit

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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <673853c4-b7b0-4a7f-915e-37646ae8cf6f@arm.com>
Date: Mon, 2 Jun 2025 16:14:45 +0100
From: Steven Price <steven.price@....com>
To: "Emi Kisanuki (Fujitsu)" <fj0570is@...itsu.com>,
 "'kvm@...r.kernel.org'" <kvm@...r.kernel.org>,
 "'kvmarm@...ts.linux.dev'" <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-arm-kernel@...ts.infradead.org>,
 "'linux-kernel@...r.kernel.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'" <linux-coco@...ts.linux.dev>,
 'Ganapatrao Kulkarni' <gankulkarni@...amperecomputing.com>,
 'Gavin Shan' <gshan@...hat.com>,
 'Shanker Donthineni' <sdonthineni@...dia.com>,
 'Alper Gun' <alpergun@...gle.com>,
 "'Aneesh Kumar K . V'" <aneesh.kumar@...nel.org>
Subject: Re: [PATCH v8 16/43] arm64: RME: Handle realm enter/exit

On 29/05/2025 05:52, Emi Kisanuki (Fujitsu) wrote:
> Hello, I comment below.

Hi Emi,

>> Subject: [PATCH v8 16/43] arm64: RME: Handle realm enter/exit
>>
>> Entering a realm is done using a SMC call to the RMM. On exit the exit-codes
>> need to be handled slightly differently to the normal KVM path so define our own
>> functions for realm enter/exit and hook them in if the guest is a realm guest.
>>
>> Signed-off-by: Steven Price <steven.price@....com>
>> ---

[..]

>> +/*
>> + * Return > 0 to return to guest, < 0 on error, 0 (and set exit_reason)
>> +on
>> + * proper exit to userspace.
>> + */
>> +int handle_rec_exit(struct kvm_vcpu *vcpu, int rec_run_ret) {
>> +	struct realm_rec *rec = &vcpu->arch.rec;
>> +	u8 esr_ec = ESR_ELx_EC(rec->run->exit.esr);
>> +	unsigned long status, index;
>> +
>> +	status = RMI_RETURN_STATUS(rec_run_ret);
>> +	index = RMI_RETURN_INDEX(rec_run_ret);
>> +
>> +	/*
>> +	 * If a PSCI_SYSTEM_OFF request raced with a vcpu executing, we
>> might
>> +	 * see the following status code and index indicating an attempt to run
>> +	 * a REC when the RD state is SYSTEM_OFF.  In this case, we just need
>> to
>> +	 * return to user space which can deal with the system event or will try
>> +	 * to run the KVM VCPU again, at which point we will no longer attempt
>> +	 * to enter the Realm because we will have a sleep request pending on
>> +	 * the VCPU as a result of KVM's PSCI handling.
>> +	 */
>> +	if (status == RMI_ERROR_REALM && index == 1) {
>> +		vcpu->run->exit_reason = KVM_EXIT_UNKNOWN;
>> +		return 0;
>> +	}
> Running kvm-unit-tests-cca selftest(smp) test in quick succession may trigger these conditions, resulting in the following error logs.
>  Error: KVM exit reason: 0 ("KVM_EXIT_UNKNOWN")
> 
> Since KVM_EXIT_UNKNOWN is used when no specific exit reason applies, I think it would be better to make it identifiable as an error.
> How about adding and setting a new ARM64 exit_reason value to indicate that the PSCI_SYSTEM_OFF request is conflicting with a running vcpu?

Aneesh pointed this out to me off-list. We agreed that KVM_EXIT_SHUTDOWN
was more appropriate here. I'll make the change for v9.

Thanks,
Steve

> Best Regards,
> Emi Kisanuki
>> +
>> +	if (rec_run_ret)
>> +		return -ENXIO;
>> +
>> +	vcpu->arch.fault.esr_el2 = rec->run->exit.esr;
>> +	vcpu->arch.fault.far_el2 = rec->run->exit.far;
>> +	vcpu->arch.fault.hpfar_el2 = rec->run->exit.hpfar;
>> +
>> +	update_arch_timer_irq_lines(vcpu);
>> +
>> +	/* Reset the emulation flags for the next run of the REC */
>> +	rec->run->enter.flags = 0;
>> +
>> +	switch (rec->run->exit.exit_reason) {
>> +	case RMI_EXIT_SYNC:
>> +		return rec_exit_handlers[esr_ec](vcpu);
>> +	case RMI_EXIT_IRQ:
>> +	case RMI_EXIT_FIQ:
>> +		return 1;
>> +	case RMI_EXIT_PSCI:
>> +		return rec_exit_psci(vcpu);
>> +	case RMI_EXIT_RIPAS_CHANGE:
>> +		return rec_exit_ripas_change(vcpu);
>> +	}
>> +
>> +	kvm_pr_unimpl("Unsupported exit reason: %u\n",
>> +		      rec->run->exit.exit_reason);
>> +	vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
>> +	return 0;
>> +}
>> diff --git a/arch/arm64/kvm/rme.c b/arch/arm64/kvm/rme.c index
>> 33eb793d8bdb..bee9dfe12e03 100644
>> --- a/arch/arm64/kvm/rme.c
>> +++ b/arch/arm64/kvm/rme.c
>> @@ -863,6 +863,25 @@ void kvm_destroy_realm(struct kvm *kvm)
>>  	kvm_free_stage2_pgd(&kvm->arch.mmu);
>>  }
>>
>> +int kvm_rec_enter(struct kvm_vcpu *vcpu) {
>> +	struct realm_rec *rec = &vcpu->arch.rec;
>> +
>> +	switch (rec->run->exit.exit_reason) {
>> +	case RMI_EXIT_HOST_CALL:
>> +	case RMI_EXIT_PSCI:
>> +		for (int i = 0; i < REC_RUN_GPRS; i++)
>> +			rec->run->enter.gprs[i] = vcpu_get_reg(vcpu, i);
>> +		break;
>> +	}
>> +
>> +	if (kvm_realm_state(vcpu->kvm) != REALM_STATE_ACTIVE)
>> +		return -EINVAL;
>> +
>> +	return rmi_rec_enter(virt_to_phys(rec->rec_page),
>> +			     virt_to_phys(rec->run));
>> +}
>> +
>>  static void free_rec_aux(struct page **aux_pages,
>>  			 unsigned int num_aux)
>>  {
>> --
>> 2.43.0
>>
>