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 88AA2C56202 for ; Wed, 21 Oct 2020 14:47:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DC6072224E for ; Wed, 21 Oct 2020 14:46:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="i02SJGra" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DC6072224E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 37E686B005D; Wed, 21 Oct 2020 10:46:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 32DFD6B0068; Wed, 21 Oct 2020 10:46:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F5926B006C; Wed, 21 Oct 2020 10:46:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0117.hostedemail.com [216.40.44.117]) by kanga.kvack.org (Postfix) with ESMTP id E77046B005D for ; Wed, 21 Oct 2020 10:46:58 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7B35C3620 for ; Wed, 21 Oct 2020 14:46:58 +0000 (UTC) X-FDA: 77396209716.16.mist62_2913a9427249 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id 5899D102133BE for ; Wed, 21 Oct 2020 14:46:58 +0000 (UTC) X-HE-Tag: mist62_2913a9427249 X-Filterd-Recvd-Size: 7002 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf34.hostedemail.com (Postfix) with ESMTP for ; Wed, 21 Oct 2020 14:46:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603291617; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=McsFIc3uuC39J5CjXN1eYmGbwChHomet0XT2rkjh0/Q=; b=i02SJGraajsBwrRpmax11rBJ4SV5jUJqmtKqcGh+J0Vbm38DlY7NXHqqOtiT3GJDRS4z9V 0MB+nLhmrsrC1Lrz3X9Foz6s8cM3Oa2QSsyU37wUdzAkPVDmo1QxmO01huYqm7925KEUXO sI0B11IY7NiMP9t8fWKcRjHKblVYLJA= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-487-Zi5SvRWtM-6OcqBsR2AO0w-1; Wed, 21 Oct 2020 10:46:52 -0400 X-MC-Unique: Zi5SvRWtM-6OcqBsR2AO0w-1 Received: by mail-wm1-f69.google.com with SMTP id s12so1501801wmj.0 for ; Wed, 21 Oct 2020 07:46:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=McsFIc3uuC39J5CjXN1eYmGbwChHomet0XT2rkjh0/Q=; b=k9s2POpZD/k1FlcYzhNj1MaB0Mt5062hM938n7iYX5VNYNypb3RnPD2MUX8v+gbVhF qdAF5cSMGCu5XZDi+DkAGY8D0CfvuAZS82BsRuWFKfrWnyoSx9xgyW9N6LSMbNvFJXUJ 9iy9ExvyCVOPhAAHhFCXZtS9UCR3KULQ5AVi8Oq2/Bm/8MycdPQbk1VscVFCoC4VHdeI ouFN2XxPcV9DR2c/8iJarcs5GC2R7Mvrkw7b/fkQ1TM1cyudN86tuLQrnKXV7NrBXPzq yN2yeziJsW0iKzHaCvDMGaLT+gtfNDxzvClVhB8DTsPLjeA7n2OBBF/yqiHp0uitDMRH 17pQ== X-Gm-Message-State: AOAM530xD3DdpLLHpt120N7pHQAtFOn00feEZnVAeNraSk0C7Eoqpgl7 i2zwkT73A4e6NXghaSZhAsMQdNjbWd05eoQgqndB336lNoavuUUSFiz7xiha+g9Se9nSyybdNHW P18JPhUeVaiU= X-Received: by 2002:adf:c3cd:: with SMTP id d13mr5175545wrg.15.1603291611243; Wed, 21 Oct 2020 07:46:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyLuiHz/EA1MVlnS6k5vCNG0L0fXDex1R+1gOApxkZZ9bGeCuNXSExKywBkiIGO4shIJ4ZYZg== X-Received: by 2002:adf:c3cd:: with SMTP id d13mr5175499wrg.15.1603291610994; Wed, 21 Oct 2020 07:46:50 -0700 (PDT) Received: from vitty.brq.redhat.com (g-server-2.ign.cz. [91.219.240.2]) by smtp.gmail.com with ESMTPSA id j17sm3943426wrw.68.2020.10.21.07.46.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2020 07:46:50 -0700 (PDT) From: Vitaly Kuznetsov To: "Kirill A. Shutemov" 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 In-Reply-To: <20201020134924.2i4z4kp6bkiheqws@box> References: <20201020061859.18385-1-kirill.shutemov@linux.intel.com> <87ft6949x8.fsf@vitty.brq.redhat.com> <20201020134924.2i4z4kp6bkiheqws@box> Date: Wed, 21 Oct 2020 16:46:48 +0200 Message-ID: <87eelr4ox3.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=vkuznets@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 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: "Kirill A. Shutemov" writes: > 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 g= uest >> > memory from some unauthorized host access. The patchset proposes a p= urely >> > software feature that mitigates some of the same host-side read-only >> > attacks. >> > >> > >> > =3D=3D What does this set mitigate? =3D=3D >> > >> > - Host kernel =E2=80=9Daccidental=E2=80=9D access to guest data (th= ink speculation) >> > >> > - Host kernel induced access to guest data (write(fd, &guest_data_p= tr, len)) >> > >> > - Host userspace access to guest data (compromised qemu) >> > >> > - Guest privilege escalation via compromised QEMU device emulation >> > >> > =3D=3D What does this set NOT mitigate? =3D=3D >> > >> > - Full host kernel compromise. Kernel will just map the pages agai= n. >> > >> > - Hardware attacks >> > >> > >> > The second RFC revision addresses /most/ of the feedback. >> > >> > I still didn't found a good solution to reboot and kexec. Unprotect = all >> > the memory on such operations defeat the goal of the feature. Cleari= ng 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 o= n >> why you think that "unprotect all" hypercall (or rather a single >> hypercall supporting both protecting/unprotecting) defeats the purpose >> of the feature? > > If guest has some data that it prefers not to leak to the host and use = the > feature for the purpose, share all the memory to get through reboot is = a > very weak point. > 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. >>=20 >> clean up *all* its memory upon reboot, however: >> - It may only clean up the most sensitive parts. This should probably = be >> done even without this new feature and even on bare metal (think about >> next boot target being malicious). >> - The attack window shrinks significantly. "Speculative" bugs require >> 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 the = VM > rebooted, just reconstruct it from scratch as if it would be new boot. 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? --=20 Vitaly