From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B36C73A9D8F; Thu, 7 May 2026 13:36:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778161009; cv=none; b=fBOTOiGsxWCbwQKFv9yCkfOWogK/YA0wgni5jrl2JberPxSog0sBNWfTwC9iZOsID7aujCvZyLR/P7l2WiG7vZIcAbDOwA2AC35pJQhsrG1o1Aq8vCc7G0R6BB1amabcpViNCgl1dvKf/NxRokEv+gP3tEQnK4Pb+Qq4mURxHVY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778161009; c=relaxed/simple; bh=swhnCX4GiPiWbOLZwXEXT66bu8Nfxrf73Z5yu5LKyFk=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=jLzXtY2am7Z5ReYkRmRxZmbv5iWiE75yq4fr/6Q4p4Uy6Tuz9MrlWQjo0/W0PcsR/78Au+gu7hJ+W26scBLGHjZhdW7/vLEZbthGgOF+x5iLbBx4uogGwzWqLnTdZXnoOKUJZXheHnu8WW9hJuIcflDrhjeHjq6Vw0TKdaSBIPA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lVkX5AbG; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lVkX5AbG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C50DC2BCB2; Thu, 7 May 2026 13:36:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778161008; bh=swhnCX4GiPiWbOLZwXEXT66bu8Nfxrf73Z5yu5LKyFk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=lVkX5AbGoxy30ZDoT1jcNTFgQizQg3K3gX8hgIjib6w/RRAbItwlJGP3Gj9Gg7W7j a4aNd5PvDOqQpS3ZrTVNTWEu7xaYZ7uJPm0flbirclC4rY/YKylBUzW8aqbd2IjEbW DR+Y08VlBW+9J1KiTeNDBD5Fr40cWrGtLJtXOoAse2vNVc4pZ4JDx0JGXZrsv0mnxu 4vskrAwsJpJvgTX6BfWPQwe4XqqDcfrCohWnvCZ5JF42Ic3PKIXnK5l3KA8BUJZVM7 EY+Zkmkg0KD9f+1IFEAG+LqbBz+2lru5Ge2aM0NhybJLuOypPym9Xj9vhc/BFIfBjs OU8a2MgsnqCyg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-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 1wKyuE-00000000eBg-2hUx; Thu, 07 May 2026 13:36:46 +0000 Date: Thu, 07 May 2026 14:36:46 +0100 Message-ID: <86se83xrwx.wl-maz@kernel.org> From: Marc Zyngier To: Sebastian Ene Cc: catalin.marinas@arm.com, oupton@kernel.org, will@kernel.org, joey.gouly@arm.com, korneld@google.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, android-kvm@google.com, mrigendra.chaubey@gmail.com, perlarsen@google.com, suzuki.poulose@arm.com, vdonnefort@google.com, yuzenghui@huawei.com, Sudeep Holla Subject: Re: [PATCH] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone In-Reply-To: References: <20260501114447.2389222-2-sebastianene@google.com> <86wlxgy00t.wl-maz@kernel.org> 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) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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: sebastianene@google.com, catalin.marinas@arm.com, oupton@kernel.org, will@kernel.org, joey.gouly@arm.com, korneld@google.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, android-kvm@google.com, mrigendra.chaubey@gmail.com, perlarsen@google.com, suzuki.poulose@arm.com, vdonnefort@google.com, yuzenghui@huawei.com, sudeep.holla@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 07 May 2026 11:48:46 +0100, Sebastian Ene wrote: > > On Wed, May 06, 2026 at 05:29:22PM +0100, Marc Zyngier wrote: > > Hello Marc, > > > [+ Sudeep] > > > > On Fri, 01 May 2026 12:44:48 +0100, > > Sebastian Ene wrote: > > > > > > Remove the FFA_NOTIFICATION* calls from the blocklist used by the pKVM > > > FF-A proxy. This restriction was preventing the use of asynchronous > > > signaling mechanisms defined by the Arm FF-A specification to > > > communicate with the secure services. > > > While these calls are markes as optional, there is no reason why the > > > hypervisor proxy would block them because: > > > > > > 1. Host is the Sole Non-Secure Endpoint: The Host operates as the > > > only Non-Secure VM ID (VM ID 0) recognized by the Secure World. > > > > Where is this enforced? > > > > There is no enforcement in place in the hypervisor since we don't proxy > FF-A from guest VMs, there is only one non-secure user of this which is the host. And again: what makes that VM ID 0? Why can't the host pick VM ID 32 and use that? > > > Because all forwarded notifications are inherently attributed to > > > the Host by the SPMC, there is no risk of VM ID spoofing > > > originating from the Normal World. > > > > I don't understand: either the host is always using VM ID 0, and we > > have ways to check and enforce this (how?), or the simple fact that > > the request comes from NS is a guarantee that the SPMC will treat the > > VM ID as 0. > > > > Which one is it? > > My understanding is that when the hypervisor doesn't handle the allocation of > the non-secure IDs (through FFA_ID_GET), everything that comes from non-secure > is treated as having the VM ID 0 by the SPMC. This looks terribly fragile. I'd rather you *enforce* these things rather than allowing any random stuff from the host and relying on the EL3 firmware to get it right (odds are that it won't). This also ties into this: > > > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c > > > index 1af722771178..a82d0cd22a17 100644 > > > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c > > > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c > > > @@ -675,14 +675,6 @@ static bool ffa_call_supported(u64 func_id) > > > case FFA_RXTX_MAP: > > > case FFA_MEM_DONATE: > > > case FFA_MEM_RETRIEVE_REQ: > > > - /* Optional notification interfaces added in FF-A 1.1 */ > > > - case FFA_NOTIFICATION_BITMAP_CREATE: > > > - case FFA_NOTIFICATION_BITMAP_DESTROY: > > > - case FFA_NOTIFICATION_BIND: > > > - case FFA_NOTIFICATION_UNBIND: > > > - case FFA_NOTIFICATION_SET: > > > - case FFA_NOTIFICATION_GET: > > > - case FFA_NOTIFICATION_INFO_GET: > > > /* Optional interfaces added in FF-A 1.2 */ > > > case FFA_MSG_SEND_DIRECT_REQ2: /* Optional per 7.5.1 */ > > > case FFA_MSG_SEND_DIRECT_RESP2: /* Optional per 7.5.1 */ > > > > Shouldn't these be sanitised in a way? A bunch of registers are SBZ in > > the spec, and I'd expect this to be enforced. which still remains unanswered. M. -- Without deviation from the norm, progress is not possible.