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=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 4C020C433DF for ; Thu, 4 Jun 2020 16:35:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0DE8220772 for ; Thu, 4 Jun 2020 16:35:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="oz64bk3+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0DE8220772 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8FBCF80007; Thu, 4 Jun 2020 12:35:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8ABC98E0006; Thu, 4 Jun 2020 12:35:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 79A1D80007; Thu, 4 Jun 2020 12:35:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0068.hostedemail.com [216.40.44.68]) by kanga.kvack.org (Postfix) with ESMTP id 5FA9B8E0006 for ; Thu, 4 Jun 2020 12:35:42 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 155FA80AB796 for ; Thu, 4 Jun 2020 16:35:42 +0000 (UTC) X-FDA: 76892080524.17.trip64_4ebdc7018b202 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id E08221857AB0B for ; Thu, 4 Jun 2020 16:35:41 +0000 (UTC) X-HE-Tag: trip64_4ebdc7018b202 X-Filterd-Recvd-Size: 5951 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Thu, 4 Jun 2020 16:35:40 +0000 (UTC) Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (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 81E772063A; Thu, 4 Jun 2020 16:35:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591288540; bh=yh0pW6AQ26Q8fHNyEsW/NqFcwh9UdeeuT0YVHMhwgkA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oz64bk3++bmjKdBSuwstw05YML612cdirg9gx/8mR6XeIO74cg1yCESj90ohJnnSv cDjuZ3NgvkxFiF6nuUmo0AN81ew532R2PhQsVHA85/U4gwsC8tsoSN0c9Q6Q6TEmnE pYa3JVNL1KSaYea21V1Ssgc3vDVvVHvl91cck04A= Date: Thu, 4 Jun 2020 17:35:33 +0100 From: Will Deacon To: Sean Christopherson Cc: Marc Zyngier , "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , David Rientjes , Andrea Arcangeli , Kees Cook , Will Drewry , "Edgecombe, Rick P" , "Kleen, Andi" , x86@kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" , kernel-team@android.com, Jun Nakajima Subject: Re: [RFC 00/16] KVM protected memory extension Message-ID: <20200604163532.GE3650@willie-the-truck> References: <20200522125214.31348-1-kirill.shutemov@linux.intel.com> <20200604161523.39962919@why> <20200604154835.GE30223@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200604154835.GE30223@linux.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: E08221857AB0B X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Sean, On Thu, Jun 04, 2020 at 08:48:35AM -0700, Sean Christopherson wrote: > On Thu, Jun 04, 2020 at 04:15:23PM +0100, Marc Zyngier wrote: > > On Fri, 22 May 2020 15:51:58 +0300 > > "Kirill A. Shutemov" wrote: > >=20 > > > =3D=3D Background / Problem =3D=3D > > >=20 > > > There are a number of hardware features (MKTME, SEV) which protect = guest > > > memory from some unauthorized host access. The patchset proposes a = purely > > > software feature that mitigates some of the same host-side read-onl= y > > > attacks. > > >=20 > > >=20 > > > =3D=3D What does this set mitigate? =3D=3D > > >=20 > > > - Host kernel =E2=80=9Daccidental=E2=80=9D access to guest data (t= hink speculation) > > >=20 > > > - Host kernel induced access to guest data (write(fd, &guest_data_= ptr, len)) > > >=20 > > > - Host userspace access to guest data (compromised qemu) > > >=20 > > > =3D=3D What does this set NOT mitigate? =3D=3D > > >=20 > > > - Full host kernel compromise. Kernel will just map the pages aga= in. > > >=20 > > > - Hardware attacks > >=20 > > Just as a heads up, we (the Android kernel team) are currently > > involved in something pretty similar for KVM/arm64 in order to bring > > some level of confidentiality to guests. > >=20 > > The main idea is to de-privilege the host kernel by wrapping it in it= s > > own nested set of page tables which allows us to remove memory > > allocated to guests on a per-page basis. The core hypervisor runs mor= e > > or less independently at its own privilege level. It still is KVM > > though, as we don't intend to reinvent the wheel. > >=20 > > Will has written a much more lingo-heavy description here: > > https://lore.kernel.org/kvmarm/20200327165935.GA8048@willie-the-truck= / >=20 > Pardon my arm64 ignorance... No, not at all! > IIUC, in this mode, the host kernel runs at EL1? And to switch to a gu= est > it has to bounce through EL2, which is KVM, or at least a chunk of KVM? > I assume the EL1->EL2->EL1 switch is done by trapping an exception of s= ome > form? Yes, and this is actually the way that KVM works on some Arm CPUs today, as the original virtualisation extensions in the Armv8 architecture do not make it possible to run the kernel directly at EL2 (for example, ther= e is only one page-table base register). This was later addressed in the architecture by the "Virtualisation Host Extensions (VHE)", and so KVM supports both options. With non-VHE today, there is a small amount of "world switch" code at EL2 which is installed by the host kernel and provides a way to transitio= n between the host and the guest. If the host needs to do something at EL2 (e.g. privileged TLB invalidation), then it makes a hypercall (HVC instru= ction) via the kvm_call_hyp() macro (and this ends up just being a function call for VHE). > If all of the above are "yes", does KVM already have the necessary logi= c to > perform the EL1->EL2->EL1 switches, or is that being added as part of t= he > de-privileging effort? The logic is there as part of the non-VHE support code, but it's not grea= t from a security angle. For example, the guest stage-2 page-tables are sti= ll allocated by the host, the host has complete access to guest and hypervis= or memory (including hypervisor text) and things like kvm_call_hyp() are a b= it of an open door. We're working on making the EL2 code more self contained= , so that after the host has initialised KVM, it can shut the door and the hypervisor can install a stage-2 translation over the host, which limits = its access to hypervisor and guest memory. There will clearly be IOMMU work a= s well to prevent DMA attacks. Will