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.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 53BDBC433B4 for ; Wed, 7 Apr 2021 13:31:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D054661363 for ; Wed, 7 Apr 2021 13:31:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D054661363 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 4BA326B007D; Wed, 7 Apr 2021 09:31:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 46A056B007E; Wed, 7 Apr 2021 09:31:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BC266B0080; Wed, 7 Apr 2021 09:31:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0069.hostedemail.com [216.40.44.69]) by kanga.kvack.org (Postfix) with ESMTP id 0F5F26B007D for ; Wed, 7 Apr 2021 09:31:36 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B7ABB180ACF8B for ; Wed, 7 Apr 2021 13:31:35 +0000 (UTC) X-FDA: 78005658150.03.3F6F772 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by imf20.hostedemail.com (Postfix) with ESMTP id 977D73C1 for ; Wed, 7 Apr 2021 13:31:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617802294; 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=EnG+MjyTVqXm7o2GzbaneMy7mN1KIeUj4VgvlhyWQQM=; b=EVN9HqZq8QQguaQ/eVFDQsz9rwTBtd3cAsfCCoM3UwzDKZFX3XiFfG9K9vpwr28knKKUvG Pp67Wzx70iT0xOHS4iwoETSMqTaB5mdx0quMW/yAcjw6+Gt8gtfi7Oto7DOL1w3Y8T3Od9 hvTgIH3sS0kaWmQxKvATk1YjiovStFA= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-512-glzNypmwMeWosJu96R2kdw-1; Wed, 07 Apr 2021 09:31:33 -0400 X-MC-Unique: glzNypmwMeWosJu96R2kdw-1 Received: by mail-wr1-f70.google.com with SMTP id s13so3475449wrt.21 for ; Wed, 07 Apr 2021 06:31:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vJkU8vXKb0BvHUAPz+V+eKFMW3IPbu7jFAYroR0o//I=; b=cyfeZK932VeWSwqZGOX8FpmBHIiXYYq7bIcX7f544Vqsroblb8uoEzwi8RqDWOLoIO xN2cCZMYhdJlMWIhE4F1ub9QqANLifgtGnho1c5HwF8PvfJNr4N71Y0vqnXUvkot9c+i uHBp+r/2H8pVKQotCAXh5rsV5C8Tzvu+YMunkoZUWENnFkJNBCmcPfX3NYnjjCngWL/O 969FW9d4sO21kXI6Qdu9Y5TGygEXT9w/i3vq9Hpf7yHqaRVKlUV9YlIKcGLaSpzyeJYf d0J6Bf5KIPbg9WtuiXL9bImaZotncyF1GMHrlIzbPjwmyqd/i2jkDAFpN6XEg5Sp1KoK jc8A== X-Gm-Message-State: AOAM532Ei1EPJkKRBpTgbPgUn+rbg2x7LV0IuzRaX6WQognUGpBTg6Fb +77vLUWuTEN/vFrd977m4zC3j3tU3GPjv1/NhbQ0kaB+WkNrUjyn/kyS72o9NNkmu6pZDabk+9h nbchgdLwq5Xs= X-Received: by 2002:adf:fd0b:: with SMTP id e11mr550471wrr.347.1617802290842; Wed, 07 Apr 2021 06:31:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzwq628wJtz5+hwuBUC2lqHMaUJJqHRIwbBPct9QaQxXpt5xT0WtUpxxEbEiXll2GkmWiz0Pg== X-Received: by 2002:adf:fd0b:: with SMTP id e11mr550429wrr.347.1617802290484; Wed, 07 Apr 2021 06:31:30 -0700 (PDT) Received: from ?IPv6:2a01:e0a:466:71c0:99e0:ccd6:fcea:5668? ([2a01:e0a:466:71c0:99e0:ccd6:fcea:5668]) by smtp.gmail.com with ESMTPSA id u17sm7339826wmq.3.2021.04.07.06.31.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Apr 2021 06:31:30 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: [RFCv1 7/7] KVM: unmap guest memory using poisoned pages From: Christophe de Dinechin In-Reply-To: <20210407131647.djajbwhqsmlafsyo@box.shutemov.name> Date: Wed, 7 Apr 2021 15:31:28 +0200 Cc: David Hildenbrand , Dave Hansen , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Sean Christopherson , Jim Mattson , David Rientjes , "Edgecombe, Rick P" , "Kleen, Andi" , "Yamahata, Isaku" , x86@kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" Message-Id: References: <20210402152645.26680-1-kirill.shutemov@linux.intel.com> <20210402152645.26680-8-kirill.shutemov@linux.intel.com> <52518f09-7350-ebe9-7ddb-29095cd3a4d9@intel.com> <20210407131647.djajbwhqsmlafsyo@box.shutemov.name> To: "Kirill A. Shutemov" X-Mailer: Apple Mail (2.3654.60.0.2.21) Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=cdupontd@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 977D73C1 X-Stat-Signature: zny9hqno4fpzsuajowo88z9cn9txqrtw X-Rspamd-Server: rspam02 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf20; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=63.128.21.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1617802292-896196 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 7 Apr 2021, at 15:16, Kirill A. Shutemov wrote: >=20 > On Tue, Apr 06, 2021 at 04:57:46PM +0200, David Hildenbrand wrote: >> On 06.04.21 16:33, Dave Hansen wrote: >>> On 4/6/21 12:44 AM, David Hildenbrand wrote: >>>> On 02.04.21 17:26, Kirill A. Shutemov wrote: >>>>> TDX architecture aims to provide resiliency against confidentiality a= nd >>>>> integrity attacks. Towards this goal, the TDX architecture helps enfo= rce >>>>> the enabling of memory integrity for all TD-private memory. >>>>>=20 >>>>> The CPU memory controller computes the integrity check value (MAC) fo= r >>>>> the data (cache line) during writes, and it stores the MAC with the >>>>> memory as meta-data. A 28-bit MAC is stored in the ECC bits. >>>>>=20 >>>>> Checking of memory integrity is performed during memory reads. If >>>>> integrity check fails, CPU poisones cache line. >>>>>=20 >>>>> On a subsequent consumption (read) of the poisoned data by software, >>>>> there are two possible scenarios: >>>>>=20 >>>>> - Core determines that the execution can continue and it treats >>>>> poison with exception semantics signaled as a #MCE >>>>>=20 >>>>> - Core determines execution cannot continue,and it does an unbreaka= ble >>>>> shutdown >>>>>=20 >>>>> For more details, see Chapter 14 of Intel TDX Module EAS[1] >>>>>=20 >>>>> As some of integrity check failures may lead to system shutdown host >>>>> kernel must not allow any writes to TD-private memory. This requirmen= t >>>>> clashes with KVM design: KVM expects the guest memory to be mapped in= to >>>>> host userspace (e.g. QEMU). >>>>=20 >>>> So what you are saying is that if QEMU would write to such memory, it >>>> could crash the kernel? What a broken design. >>>=20 >>> IMNHO, the broken design is mapping the memory to userspace in the firs= t >>> place. Why the heck would you actually expose something with the MMU t= o >>> a context that can't possibly meaningfully access or safely write to it= ? >>=20 >> I'd say the broken design is being able to crash the machine via a simpl= e >> memory write, instead of only crashing a single process in case you're d= oing >> something nasty. From the evaluation of the problem it feels like this w= as a >> CPU design workaround: instead of properly cleaning up when it gets tric= ky >> within the core, just crash the machine. And that's a CPU "feature", not= a >> kernel "feature". Now we have to fix broken HW in the kernel - once agai= n. >>=20 >> However, you raise a valid point: it does not make too much sense to to = map >> this into user space. Not arguing against that; but crashing the machine= is >> just plain ugly. >>=20 >> I wonder: why do we even *want* a VMA/mmap describing that memory? Sound= s >> like: for hacking support for that memory type into QEMU/KVM. >>=20 >> This all feels wrong, but I cannot really tell how it could be better. T= hat >> memory can really only be used (right now?) with hardware virtualization >> from some point on. From that point on (right from the start?), there sh= ould >> be no VMA/mmap/page tables for user space anymore. >>=20 >> Or am I missing something? Is there still valid user space access? >=20 > There is. For IO (e.g. virtio) the guest mark a range of memory as shared > (or unencrypted for AMD SEV). The range is not pre-defined. >=20 >>> This started with SEV. QEMU creates normal memory mappings with the SE= V >>> C-bit (encryption) disabled. The kernel plumbs those into NPT, but whe= n >>> those are instantiated, they have the C-bit set. So, we have mismatche= d >>> mappings. Where does that lead? The two mappings not only differ in >>> the encryption bit, causing one side to read gibberish if the other >>> writes: they're not even cache coherent. >>>=20 >>> That's the situation *TODAY*, even ignoring TDX. >>>=20 >>> BTW, I'm pretty sure I know the answer to the "why would you expose thi= s >>> to userspace" question: it's what QEMU/KVM did alreadhy for >>> non-encrypted memory, so this was the quickest way to get SEV working. >>>=20 >>=20 >> Yes, I guess so. It was the fastest way to "hack" it into QEMU. >>=20 >> Would we ever even want a VMA/mmap/process page tables for that memory? = How >> could user space ever do something *not so nasty* with that memory (in t= he >> current context of VMs)? >=20 > In the future, the memory should be still managable by host MM: migration= , > swapping, etc. But it's long way there. For now, the guest memory > effectively pinned on the host. Is there even a theoretical way to restore an encrypted page e.g. from (hos= t) swap without breaking the integrity check? Or will that only be possible wi= th assistance from within the encrypted enclave? >=20 > --=20 > Kirill A. Shutemov >=20