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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,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 E05CFC388F9 for ; Fri, 23 Oct 2020 11:35:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 36F5124248 for ; Fri, 23 Oct 2020 11:35:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=shutemov-name.20150623.gappssmtp.com header.i=@shutemov-name.20150623.gappssmtp.com header.b="jU38f+iK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 36F5124248 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8479E6B006E; Fri, 23 Oct 2020 07:35:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F8E56B0070; Fri, 23 Oct 2020 07:35:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 70CCD6B0071; Fri, 23 Oct 2020 07:35:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0147.hostedemail.com [216.40.44.147]) by kanga.kvack.org (Postfix) with ESMTP id 426756B006E for ; Fri, 23 Oct 2020 07:35:21 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id C3BB88BE3F6B for ; Fri, 23 Oct 2020 11:35:20 +0000 (UTC) X-FDA: 77402984400.15.act79_29066dc27259 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id 9968F1814B0C1 for ; Fri, 23 Oct 2020 11:35:20 +0000 (UTC) X-HE-Tag: act79_29066dc27259 X-Filterd-Recvd-Size: 7102 Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Fri, 23 Oct 2020 11:35:19 +0000 (UTC) Received: by mail-lf1-f66.google.com with SMTP id d24so1663579lfa.8 for ; Fri, 23 Oct 2020 04:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=n+nJGJpzd/W8n16INkSYqQkDUkF/oTotGcxcg7bvZAY=; b=jU38f+iKMoloRKjrc7spG6UqSiMifftqZ1SZbQrtNvaY7eLmGeolflJh2zjUJkfjpB pbtGnihnHQ8QEoGtqlfDer54+Lb8yBXDqz+bNUOMlfGjbD5X74YO6zEmvaYbR5Cud2qd Jg7dFHyU0w5YkOSgfSgaN6qpiOp00meBrK7coYuDFGvNMR19c/Q4g+U1ELXlpLXn2kLC 9eXFgPg66ep/wQgjZBQ9MCAMPcVJvOyOmrb0ix6lBQo6zTPu7OXUgVaUCcgPDYBW0up3 Q58s6/rzP4gF9rbMqcb5z2I+PhG3uWgO/kQa7rjUWDM7gRNmSLp0rgT7Emh+MTZLoGg+ k9RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=n+nJGJpzd/W8n16INkSYqQkDUkF/oTotGcxcg7bvZAY=; b=GFJRpeWBmbr5F/KetDrpCHsa+paoBKOiNBzo66+jG7z1bpJxqo67ZhaxoYvcdqo/iY L7JEjmNr+a2eC5X9UvmMhHFFE03TuVRlViVr5Lca3WgLtozsn4x0jjiMO0IpNkTvzFaY cdYIDkduDqtzqAlacDdTAzBlOKqTFiHM5R7U44P0o7ZF1KqhnooHu7yRoZeYlZo6VoNP 5DX4M8SbpqG6Ogpri+lhtNaftFQy0Y1C+yvgGLKrLeCXYBhNA/4WtrHGmnBEbHB2a9mB OHcXxQl4tfmseOqbCzi69y/CIJ7RkjOMnf+WIf6s3FP5fbSDMfxkwxyQkCkakKa3Ts90 GK5Q== X-Gm-Message-State: AOAM533gLUnCkf/5wCoNdRXTySxdmojDlKEbsP6zHNqY8zFkkJqHowvh E6G6y8ZU503PRKEIOT5CCgv0vQpecLCrQA== X-Google-Smtp-Source: ABdhPJyJ6oDU73XCxB3tcKhbB2wd+k8K27VwNAKkjtzm8Jer9V8/Rt7fN8o46ChfDM0kd+lShSU6VA== X-Received: by 2002:a19:ed16:: with SMTP id y22mr668637lfy.66.1603452918708; Fri, 23 Oct 2020 04:35:18 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id r19sm111450lfm.301.2020.10.23.04.35.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Oct 2020 04:35:17 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id C4899102F98; Fri, 23 Oct 2020 14:35:17 +0300 (+03) Date: Fri, 23 Oct 2020 14:35:17 +0300 From: "Kirill A. Shutemov" To: Vitaly Kuznetsov Cc: David Rientjes , Andrea Arcangeli , Kees Cook , Will Drewry , "Edgecombe, Rick P" , "Kleen, Andi" , Liran Alon , Mike Rapoport , x86@kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Paolo Bonzini , Sean Christopherson , Wanpeng Li , Jim Mattson , Joerg Roedel Subject: Re: [RFCv2 00/16] KVM protected memory extension Message-ID: <20201023113517.j543e77hmqenjvgw@box> References: <20201020061859.18385-1-kirill.shutemov@linux.intel.com> <87ft6949x8.fsf@vitty.brq.redhat.com> <20201020134924.2i4z4kp6bkiheqws@box> <87eelr4ox3.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87eelr4ox3.fsf@vitty.brq.redhat.com> 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: On Wed, Oct 21, 2020 at 04:46:48PM +0200, Vitaly Kuznetsov wrote: > "Kirill A. Shutemov" writes: >=20 > > On Tue, Oct 20, 2020 at 09:46:11AM +0200, Vitaly Kuznetsov wrote: > >> "Kirill A. Shutemov" writes: > >>=20 > >> > =3D=3D Background / Problem =3D=3D > >> > > >> > 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-on= ly > >> > attacks. > >> > > >> > > >> > =3D=3D What does this set mitigate? =3D=3D > >> > > >> > - Host kernel =E2=80=9Daccidental=E2=80=9D access to guest data (= think speculation) > >> > > >> > - Host kernel induced access to guest data (write(fd, &guest_data= _ptr, len)) > >> > > >> > - Host userspace access to guest data (compromised qemu) > >> > > >> > - Guest privilege escalation via compromised QEMU device emulatio= n > >> > > >> > =3D=3D What does this set NOT mitigate? =3D=3D > >> > > >> > - Full host kernel compromise. Kernel will just map the pages ag= ain. > >> > > >> > - Hardware attacks > >> > > >> > > >> > The second RFC revision addresses /most/ of the feedback. > >> > > >> > I still didn't found a good solution to reboot and kexec. Unprotec= t all > >> > the memory on such operations defeat the goal of the feature. Clea= ring up > >> > most of the memory before unprotecting what is required for reboot= (or > >> > kexec) is tedious and error-prone. > >> > Maybe we should just declare them unsupported? > >>=20 > >> Making reboot unsupported is a hard sell. Could you please elaborate= on > >> why you think that "unprotect all" hypercall (or rather a single > >> hypercall supporting both protecting/unprotecting) defeats the purpo= se > >> of the feature? > > > > If guest has some data that it prefers not to leak to the host and us= e the > > feature for the purpose, share all the memory to get through reboot i= s a > > very weak point. > > >=20 > My point that if it knows that there's something sensitive in its > memory it should clean it up even today without your feature before > rebooting to an unknown target. It's unrealistic to expect everybody to do the right thing. > >> clean up *all* its memory upon reboot, however: > >> - It may only clean up the most sensitive parts. This should probabl= y be > >> done even without this new feature and even on bare metal (think abo= ut > >> next boot target being malicious). > >> - The attack window shrinks significantly. "Speculative" bugs requir= e > >> time to exploit and it will only remain open until it boots up again > >> (few seconds). > > > > Maybe it would be cleaner to handle reboot in userspace? If we got th= e VM > > rebooted, just reconstruct it from scratch as if it would be new boot= . >=20 > We are definitely not trying to protect against malicious KVM so maybe > we can do the cleanup there (when protection was enabled) so we can > unprotect everything without risk of a leak? Do you have any particular codepath in mind? I didn't find anything suitable so far. --=20 Kirill A. Shutemov