From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794670226; b=rV0btiZ1r4RxKjhO4yaBprVz0lTk7ZR8+nro/q41ioGvgZ+fk4m6i9tjmHt6TqMgeQ8G B3wO1LfFMrZxWTVV+Sv5l05EwlXJ1HyBL4v8v4B/ZLAqDy2bbKAYESQv9TfpKS1zUj0bI BIXLr8daCIaX+x5d8qS/G6OEssdh00HOFtJHi/DsJj92iZI+ydMQMuM8V9XlUmqhy3xiC o4D1OZI/XN1aovKbxERNIlfQYzqstfUdlE7d+veLdP1MlKOEjDe/fadUyu+hlmgZTWVEN Pw1uZ4gwp+VHPUnWQ8LZ4wdO/+tLiU/PqXwr76Vjlw9rw5Y4m4Oc9pIGcAszWb5h0Vw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794670226; h=Received:DKIM-Signature:Received:Date:Message-ID:From:To:Cc:Subject: In-Reply-To:References:User-Agent:MIME-Version:Content-Type: X-SA-Exim-Connect-IP:X-SA-Exim-Rcpt-To:X-SA-Exim-Mail-From: X-SA-Exim-Scanned; bh=icGyiR0uE2382AnPCFPae3R/fkT1DCY3Eri8AeWkibw=; b=Rea/7XwOpJakJhf7AwnyNqsL1WAmzG9wA0jmPQLs6rz4xkM3MNV5cwpo5VMBfvZiFAq4 IhWdXApUQXqMfMZknQxFJEZczoNvKVryy/f0dUwrhmN+HInxT0X05Kwo1pBrTl2UFpmOP bvFgMmvGfD0GvGDHyNEdE9X8AREq7+c1CM8qKsIYGqhViuQNfjv7Y4XHVMseUAO0asV3u frPaEYYUnIYL/IqJkMZN54Iv4aOmOUmvd7jMuQ4Ui6or9ky0444Gdj/Bno1SkqoyY09JE fXkEVEx3vPakelOa+kwEgJ27Nrz/AJDaR//StOKJiTcQ9U+cZgH1w3YSf7OC6zRLXHw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=cP5RmpnH; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 62AE3606A327; Sat, 14 Nov 2026 15:30:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=cP5RmpnH Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE90D1F000C7; Sat, 14 Nov 2026 15:30:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794670226; bh=icGyiR0uE2382AnPCFPae3R/fkT1DCY3Eri8AeWkibw=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=cP5RmpnHHgTGfDQytX/wV6G7iqKv/yFkZ9OArq3Mvs43GA+vZJy2Aa3valFNwKSTW 1UbCoW0F8WmQCp6s22RO0h9ieyXbJo+6h3ls7oL4fd5PcnL7YNPopKyTQQ5AFt0d9b IZKPA3ySIW4DzEbmspecu6jd0sBUPY2vs8ZlenwMopuTOdJ/sRtbH6xQSr+F8mPh0o l7m/tcYg8uDxRLlBfcdubJ9JlwTAtJZcUp3B4Py6HHL4CMy57bKi3UQH2ydB26lsQ1 XrNsjFrg/apSPVGF0xibQ2Te8IfHSga4Akb86jcwI/RfzE3dHB1lr6hdZW12lNoFgO hnu0D8Xukr+ng== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xSFhu-0000000Fo7y-3uda; Sat, 14 Nov 2026 15:30:23 +0000 Date: Sat, 14 Nov 2026 15:33:44 +0000 Message-ID: <87jymf8m1z.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: oupton@kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, vdonnefort@google.com, ryan.roberts@arm.com, qperret@google.com, steven.price@arm.com, tabba@google.com Subject: Re: [PATCH] KVM: arm64: Keep firmware Spectre-v4 mitigation on for protected guests In-Reply-To: <20261113081934.1715497-1-fuad.tabba@linux.dev> References: <20261113081934.1715497-1-fuad.tabba@linux.dev> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: fuad.tabba@linux.dev, oupton@kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, vdonnefort@google.com, ryan.roberts@arm.com, qperret@google.com, steven.price@arm.com, tabba@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Fri, 13 Nov 2026 08:19:34 +0000, Fuad Tabba wrote: > > EL2 handles a protected guest's ARM_SMCCC_ARCH_WORKAROUND_2 discovery > query from the host's Spectre-v4 state at init. If the system is > mitigated and the guest doesn't have SSBS, it returns NOT_REQUIRED, > which means that firmware mitigation is permanently enabled. However, > the host can disable the mitigation before running a protected vCPU, > with an ARM_SMCCC_ARCH_WORKAROUND_2 call that EL2 forwards to the > firmware. > > The host makes that call for its own userspace, so keep forwarding it, > without hints so that the firmware decodes it as EL2 does. Track it per > CPU, and on a mitigated system enable the mitigation again before > running a protected vCPU on a CPU where the host has disabled it. > Firmware enables it when a CPU powers up, so the tracked state isn't > reset on CPU_ON or resume. > > Fixes: fe40ff87ead5c ("KVM: arm64: Implement HVC handling for protected guests at EL2") > Reported-by: Ryan Roberts > Closes: https://lore.kernel.org/all/5fa8a1fb-4e2c-4746-8a70-a47f387ef0d6@arm.com/ > Signed-off-by: Fuad Tabba > --- > > Notes: > Tested on QEMU with TF-A. Upstream TF-A implements the dynamic > workaround only for Cortex-A76, so I patched it to advertise the > workaround on the Cortex-A57 that QEMU models. With a host that > disables the mitigation before running a protected vCPU, TF-A gets the > call to enable it again from EL2 with this patch, and doesn't without > it. TF-A's handler for the call does nothing there and QEMU doesn't > model the mitigation, so this tests the calls and not their effect. > > Calling the firmware before every protected vCPU run would do without > the tracking, at the cost of an SMC per run. > > Based on Linux 7.4-rc2 (7475ea8b58616). > > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c > index 179d7c8277b88..081a8780fa3b7 100644 > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c > @@ -21,6 +21,7 @@ > #include > > #include > +#include > #include > #include > #include > @@ -30,6 +31,8 @@ > > DEFINE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params); > > +static DEFINE_PER_CPU(bool, host_ssbd_disabled); > + Why do we need yet another set of per-CPU booleans to track the host state that is supposed to be stored in kvm_host_data? We already have a metric bazillion of flags for any odd state tracking, and I really can't see why this should be an exception. > /* > * Define a hypercall handler: handle_ unmarshals the arguments from > * the host context and hands them, correctly typed, to the body that > @@ -940,6 +943,17 @@ DEFINE_KVM_HOST_HCALL(int, __kvm_vcpu_run, struct kvm_vcpu __kern *, vcpu) > return ret; > } > > + /* > + * Firmware Spectre-v4 mitigation can be advertised to a > + * protected guest as permanent. The host kernel runs with it > + * enabled, so nothing is restored on exit. I don't understand this. If the host is supposed to run with the mitigation enabled, how did we get here with the mitigation disabled? It's not like we can get here directly from userspace... So either the reasoning in the comment is wrong (and therefore needs fixing), or this is a buggy (malicious?) host that tries to trick the hypervisor (and then I question whether we should even try to continue running the guest). > + */ > + if (pkvm_hyp_vcpu_is_protected(hyp_vcpu) && spectre_v4_state == SPECTRE_MITIGATED && > + __this_cpu_read(host_ssbd_disabled)) { > + hyp_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2, true, NULL); > + __this_cpu_write(host_ssbd_disabled, false); > + } > + > flush_hyp_vcpu(hyp_vcpu); > > ret = __kvm_vcpu_run(&hyp_vcpu->vcpu); > @@ -1671,6 +1685,12 @@ static void handle_host_smc(struct kvm_cpu_context *host_ctxt) > goto exit_skip_instr; > } > > + if (func_id == ARM_SMCCC_ARCH_WORKAROUND_2) { > + /* Drop the hints, so that the firmware decodes the ID as EL2 did. */ > + cpu_reg(host_ctxt, 0) = func_id; > + __this_cpu_write(host_ssbd_disabled, !lower_32_bits(cpu_reg(host_ctxt, 1))); > + } > + This should be pushed into default_host_smc_handler() rather than left dangling here (it is pretty obvious that it has nothing to do with PSCI or FFA). > handled = kvm_host_psci_handler(host_ctxt, func_id); > if (!handled) > handled = kvm_host_ffa_handler(host_ctxt, func_id); > Thanks, M. -- Jazz isn't dead. It just smells funny.