From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B0EBDC63793 for ; Thu, 22 Jul 2021 10:05:30 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 718DB61241 for ; Thu, 22 Jul 2021 10:05:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 718DB61241 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fgD7/4wXjuf289Vp2/vxaEXxU7uWokXiIFdVps7+1pE=; b=kG/emj2TP/TZAd neog8RnnS72RSHCovvhYFjXUo69kHjp8GjW8MoDhU3lbW0MsB6C+2ZMp8RTERzyxP5X2BGemIvgXZ UFg+Bkb2uLeEEPGv/4a3a26steVyglJORq7OJLLETcRH/QIjkp4AwiHJLuxvbC9425ImgFVOKSC7Q hoqK2A5mGuqJQAG5uOeuGKIYYFHy1KjPnVmQNE9fGA8Bf8BhcmcVBU5hhIVOk9zT3xg8810c4T1EN zIWspyppjHCV03TsJlbU8C6HjcJYuv21jKbIpkkiWb9b3o67ZYXu4NyGJfcOGFm6OD+JFIX4nBk41 ypgb6+g2TeVEONjtYdyg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m6VY5-00166q-A1; Thu, 22 Jul 2021 10:03:25 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m6VVF-0014wZ-8S for linux-arm-kernel@lists.infradead.org; Thu, 22 Jul 2021 10:00:30 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E1D2361241; Thu, 22 Jul 2021 10:00:28 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1m6VVC-000F18-PY; Thu, 22 Jul 2021 11:00:26 +0100 Date: Thu, 22 Jul 2021 11:00:26 +0100 Message-ID: <874kcm3byd.wl-maz@kernel.org> From: Marc Zyngier To: Andrew Jones Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com, Srivatsa Vaddagiri , Shanker R Donthineni , will@kernel.org Subject: Re: [PATCH 00/16] KVM: arm64: MMIO guard PV services In-Reply-To: <20210721214243.dy6d644yznuopuqx@gator> References: <20210715163159.1480168-1-maz@kernel.org> <20210721214243.dy6d644yznuopuqx@gator> 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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: drjones@redhat.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com, vatsa@codeaurora.org, sdonthineni@nvidia.com, will@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210722_030029_388058_C54A2DED X-CRM114-Status: GOOD ( 25.79 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 21 Jul 2021 22:42:43 +0100, Andrew Jones wrote: > > On Thu, Jul 15, 2021 at 05:31:43PM +0100, Marc Zyngier wrote: > > KVM/arm64 currently considers that any memory access outside of a > > memslot is a MMIO access. This so far has served us very well, but > > obviously relies on the guest trusting the host, and especially > > userspace to do the right thing. > > > > As we keep on hacking away at pKVM, it becomes obvious that this trust > > model is not really fit for a confidential computing environment, and > > that the guest would require some guarantees that emulation only > > occurs on portions of the address space that have clearly been > > identified for this purpose. > > This trust model is hard for me to reason about. userspace is trusted to > control the life cycle of the VM, to prepare the memslots for the VM, > and [presumably] identify what MMIO ranges are valid, yet it's not > trusted to handle invalid MMIO accesses. I'd like to learn more about > this model and the userspace involved. Imagine the following scenario: On top of the normal memory described as memslots (which pKVM will ensure that userspace cannot access), a malicious userspace describes to the guest another memory region in a firmware table and does not back it with a memslot. The hypervisor cannot validate this firmware description (imagine doing ACPI and DT parsing at EL2...), so the guest starts using this "memory" for something, and data slowly trickles all the way to EL0. Not what you wanted. To ensure that this doesn't happen, we reverse the problem: userspace (and ultimately the EL1 kernel) doesn't get involved on a translation fault outside of a memslot *unless* the guest has explicitly asked for that page to be handled as a MMIO. With that, we have a full description of the IPA space contained in the S2 page tables: - memory described via a memslot, - directly mapped device (GICv2, for exmaple), - MMIO exposed for emulation and anything else is an invalid access that results in an abort. Does this make sense to you? Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel