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.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 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 C40B5C433E0 for ; Thu, 4 Jun 2020 15:15:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 890F720738 for ; Thu, 4 Jun 2020 15:15:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="AzUKdjZs" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 890F720738 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 19F8380007; Thu, 4 Jun 2020 11:15:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1288B8E0006; Thu, 4 Jun 2020 11:15:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F318380007; Thu, 4 Jun 2020 11:15:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0019.hostedemail.com [216.40.44.19]) by kanga.kvack.org (Postfix) with ESMTP id D84E18E0006 for ; Thu, 4 Jun 2020 11:15:28 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 957921C593E for ; Thu, 4 Jun 2020 15:15:28 +0000 (UTC) X-FDA: 76891878336.20.move94_69eccc394f361 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id 7818118210264 for ; Thu, 4 Jun 2020 15:15:28 +0000 (UTC) X-HE-Tag: move94_69eccc394f361 X-Filterd-Recvd-Size: 5471 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Thu, 4 Jun 2020 15:15:27 +0000 (UTC) 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 C92422072E; Thu, 4 Jun 2020 15:15:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591283726; bh=ehTRmixmctGTG2rIendMHkrDCa4Xx6HZ+HL+iKOW2Es=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=AzUKdjZsEdsVO/muRW82FLhh+tkqkBsCTIvWLS4USDM3sS+PhXlEGhYN2AoO3MUky qDeDLwPPklB8HVdpx6QGGwSpl3gGSmN9oUfIKPqJ/Ztn2YzdX4ywZKxBWeBlNPpgZf sx/8OtL/Acm09hxo47MoGY/XB+VhUBS7XO8orxq8= Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why) by disco-boy.misterjones.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jgraX-000HRX-9N; Thu, 04 Jun 2020 16:15:25 +0100 Date: Thu, 4 Jun 2020 16:15:23 +0100 From: Marc Zyngier To: "Kirill A. Shutemov" Cc: Dave Hansen , Andy Lutomirski , Peter Zijlstra , Paolo Bonzini , Sean Christopherson , 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, will@kernel.org Subject: Re: [RFC 00/16] KVM protected memory extension Message-ID: <20200604161523.39962919@why> In-Reply-To: <20200522125214.31348-1-kirill.shutemov@linux.intel.com> References: <20200522125214.31348-1-kirill.shutemov@linux.intel.com> Organization: Approximate X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: kirill@shutemov.name, dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, pbonzini@redhat.com, sean.j.christopherson@intel.com, vkuznets@redhat.com, wanpengli@tencent.com, jmattson@google.com, joro@8bytes.org, rientjes@google.com, aarcange@redhat.com, keescook@chromium.org, wad@chromium.org, rick.p.edgecombe@intel.com, andi.kleen@intel.com, x86@kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kirill.shutemov@linux.intel.com, kernel-team@android.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-Rspamd-Queue-Id: 7818118210264 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 Kirill, Thanks for this. On Fri, 22 May 2020 15:51:58 +0300 "Kirill A. Shutemov" wrote: > =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-only > 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 (think s= peculation) >=20 > - Host kernel induced access to guest data (write(fd, &guest_data_ptr, l= en)) >=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 again. >=20 > - Hardware attacks 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. The main idea is to de-privilege the host kernel by wrapping it in its own nested set of page tables which allows us to remove memory allocated to guests on a per-page basis. The core hypervisor runs more or less independently at its own privilege level. It still is KVM though, as we don't intend to reinvent the wheel. Will has written a much more lingo-heavy description here: https://lore.kernel.org/kvmarm/20200327165935.GA8048@willie-the-truck/ This works for one of the virtualization modes that arm64 can use (what we call non-VHE, or nVHE for short). The other mode (VHE), is much more similar to what happens on other architectures, where the kernel and the hypervisor are one single entity. In this case, we cannot use the same trick with nested page tables, and have to rely on something that would very much look like what you're proposing. Note that the two modes of the architecture would benefit from this work anyway, as I'd like the host to know that we've pulled memory from under its feet. Since you have done most of the initial work, I intend to give it a go on arm64 shortly and see what sticks. Thanks, M. --=20 Jazz is not dead. It just smells funny...