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 62E1C231A51; Wed, 2 Apr 2025 08:42:40 +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=1743583361; cv=none; b=VCLQt/YaUG1qffUstjZP1QSV2uoQ9peW6iTOb/9D7uZZbjOdL3qDW2m6+Hr0nPa54lZHjTqPZA9Bf1gAF6i+EQPd5ThZsnD8q/VkAIZ6yURE/aJQ418AL+b21mSMYQni+ZvwFyDzh8n0LRf0euMM2QHeWz/lNkeNc1VJjBmqpdU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743583361; c=relaxed/simple; bh=Uo5tWPaSgDRTx7F552j2kIj1bSvzWWjtFFj2KsZNdQQ=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=eMchmsMdRl+fsvdX9zxiEw+Qe5Co9Q9aIKq1W4mLMXG1mNCKfBdxvc2sfjqx2vOWuQkVQA57q+1aq8RDr2YSFyeXBmQx1fVwdBkkziMLLNZWlOl+BiYnoUSFJqvStD1F3ruyahDYyPxnLASuNPWmr5DR+18A/53q0HIVpbbebCw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Okmqtgzi; 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="Okmqtgzi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2C28C4CEE5; Wed, 2 Apr 2025 08:42:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1743583360; bh=Uo5tWPaSgDRTx7F552j2kIj1bSvzWWjtFFj2KsZNdQQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Okmqtgzi83HLdrxct+VcJpccdT6Krt73HA/mINKX9cBz65YZbsra0puVJVnlqQzZV d+67ToicWDUgdl1DGLPycge7Ok08zNVY+odxNBnPkmoLvWA2QBORJi53bTrjcxj1s1 I3tIeGlJ/qm08cJH9HRDqJUFOZPzuvkWh+TlZoskFyDwZPHyUHTjMJtyRzVDvBFueA WXiMOM7m9o7N25TGY2xataChsCwNwXdDfMkibGY8CoKIj3PvTdXzM9GwbPTjJ5/Bcn O4MZUuTxfKFtIvNott0YmIke5cc0stKWbfs8Nk+rWdlQIcPWhcOErHo9tqfU1ToKS+ Yhz1zlxbv8CDw== 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.95) (envelope-from ) id 1tztgE-001b9e-DJ; Wed, 02 Apr 2025 09:42:38 +0100 Date: Wed, 02 Apr 2025 09:42:39 +0100 Message-ID: <87jz83ymww.wl-maz@kernel.org> From: Marc Zyngier To: Yuvraj Sakshith Cc: oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, jens.wiklander@linaro.org, sumit.garg@kernel.org, mark.rutland@arm.com, lpieralisi@kernel.org, sudeep.holla@arm.com, pbonzini@redhat.com, kvmarm@lists.linux.dev, op-tee@lists.trustedfirmware.org, kvm@vger.kernel.org Subject: Re: [RFC PATCH 0/7] KVM: optee: Introduce OP-TEE Mediator for exposing secure world to KVM guests In-Reply-To: References: <20250401170527.344092-1-yuvraj.kernel@gmail.com> <87ldsjzr5l.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: kvm@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: yuvraj.kernel@gmail.com, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, jens.wiklander@linaro.org, sumit.garg@kernel.org, mark.rutland@arm.com, lpieralisi@kernel.org, sudeep.holla@arm.com, pbonzini@redhat.com, kvmarm@lists.linux.dev, op-tee@lists.trustedfirmware.org, kvm@vger.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 Wed, 02 Apr 2025 03:58:48 +0100, Yuvraj Sakshith wrote: > > On Tue, Apr 01, 2025 at 07:13:26PM +0100, Marc Zyngier wrote: > > On Tue, 01 Apr 2025 18:05:20 +0100, > > Yuvraj Sakshith wrote: > > > [...] > > > This implementation has been heavily inspired by Xen's OP-TEE > > > mediator. > > > > [...] > > > > And I think this inspiration is the source of most of the problems in > > this series. > > > > Routing Secure Calls from the guest to whatever is on the secure side > > should not be the kernel's job at all. It should be the VMM's job. All > > you need to do is to route the SMCs from the guest to userspace, and > > we already have all the required infrastructure for that. > > > Yes, this was an argument at the time of designing this solution. > > > It is the VMM that should: > > > > - signal the TEE of VM creation/teardown > > > > - translate between IPAs and host VAs without involving KVM > > > > - let the host TEE driver translate between VAs and PAs and deal with > > the pinning as required, just like it would do for any userspace > > (without ever using the KVM memslot interface) > > > > - proxy requests from the guest to the TEE > > > > - in general, bear the complexity of anything related to the TEE > > > > Major reason why I went with placing the implementation inside the kernel is, > - OP-TEE userspace lib (client) does not support sending SMCs for VM events > and needs modification. > - QEMU (or every other VMM) will have to be modified. Sure. And what? New feature, new API, new code. And what will happen once someone wants to use something other than OP-TEE? Or one of the many forks of OP-TEE that have a completely different ABI (cue the Android forks -- yes, plural)? > - OP-TEE driver is anyways in the kernel. A mediator will just be an addition > and not a completely new entity. Of course not. The TEE can be anywhere I want. On another machine if I decide so. Just because OP-TEE has a very simplistic model doesn't mean we have to be constrained by it. > - (Potential) issues if we would want to mediate requests from VM which has > private mem. Private memory means that not even the host has access to it, as it is the case with pKVM. How would that be an issue? > - Heavy VM exits if guest makes frequent TOS calls. Sorry, I have to completely dismiss the argument here. I'm not even remotely considering performance for something that is essentially a full context switch of the whole machine. By definition, calling into EL3, and then S-EL1/S-EL2 is going to be as fast as a dying snail, and an additional exit to userspace will hardly register for anything other than a pointless latency benchmark. > > Hence, the thought of making changes to too many entities (libteec, > VMM, etc.) was a strong reason, although arguable. It is a *terrible* reason. By this reasoning, we would have subsumed the whole VMM into the kernel (just like Xen), because "we don't want to change userspace". Furthermore, you are not even considering basic things such as permissions. Your approach completely circumvents any form of access control, meaning that if any user that can create a VM can talk to the TEE, even if they don't have access to the TEE driver. Yes, you could replicate access permission, SE-Linux, seccomp (and the rest of the security theater) at the KVM/TEE boundary, making the whole thing even more of a twisted mess. Or you could simply do the right thing and let the kernel do its job the way it was intended by using the syscall interface from userspace. > > > In short, the VMM is just another piece of userspace using the TEE to > > do whatever it wants. The TEE driver on the host must obviously know > > about VMs, but that's about it. > > > > Crucially, KVM should: > > > > - be completely TEE agnostic and never call into something that is > > TEE-specific > > > > - allow a TEE implementation entirely in userspace, specially for the > > machines that do not have EL3 > > > > Yes, you're right. Although I believe there still are some changes > that need to be made to KVM for facilitating this. For example, > kvm_smccc_get_action() would deny TOS call. If something is missing in KVM to allow routing of SMCs to userspace, I'm more than happy to entertain the change. > So, having an implementation completely in VMM without any change in > KVM might be challenging, any potential solutions are welcome. I've said what I have to say already, and pointed you in a direction that I see as both correct and maintainable. Thanks, M. -- Jazz isn't dead. It just smells funny.