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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 09C1BC432BE for ; Wed, 1 Sep 2021 17:50:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7D6536109E for ; Wed, 1 Sep 2021 17:50:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7D6536109E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 22BD08D0006; Wed, 1 Sep 2021 13:50:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1DB5C8D0001; Wed, 1 Sep 2021 13:50:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A2868D0006; Wed, 1 Sep 2021 13:50:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id EAAA48D0001 for ; Wed, 1 Sep 2021 13:50:18 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A7A821801A88D for ; Wed, 1 Sep 2021 17:50:18 +0000 (UTC) X-FDA: 78539743716.17.17021F0 Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by imf22.hostedemail.com (Postfix) with ESMTP id 56D3C1904 for ; Wed, 1 Sep 2021 17:50:18 +0000 (UTC) Received: by mail-pj1-f52.google.com with SMTP id f11-20020a17090aa78b00b0018e98a7cddaso267512pjq.4 for ; Wed, 01 Sep 2021 10:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=lTCwx671qN0Uv7CtZL+BVS1+Oy6Uwn1k3lSPRkK+jKg=; b=tX+iQK/XObeHHie9CEoItYwWrUuxY48SNGKS8OIkVuSOl9Zy8ONZjSy2CselzwLN6U fyDvLPYuMEHd2HtKTTBEpeJFwD9IiR/4nv0idT+PmOH6YFqIuelzoQtvb0nTX4PVmdXv OWdqauuhaUkvyAW9xaC+yanWAiLb+viasEaEDcErrr4YaU66XQV37GdSUJlrAI18OJ58 Xf2pXFmsPLt9vio2mK5Noy6PET+oEXr+jLkXY/5X2AQu7JJ++uEMK2w4L6v0f84FrkGP aOmqGtD7El0+sCcQxz1LVQjZB3IidTm9OdswbBH+7IPFy1A9z08/jb25AhGGV9cLIDNs V6HA== 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:in-reply-to; bh=lTCwx671qN0Uv7CtZL+BVS1+Oy6Uwn1k3lSPRkK+jKg=; b=kC3fux0J1qyNDQydA61dYJ62DzwXvoRtMqs+AkGwOwTkf65BUXiC3qOPR+i1ly5sEH WKRj7YjXIKwV3mQ9ZH5sgAQxe4H4r9WXt4Cgu5T6FJMC9IBYdMMCTM9hjAEtZVJVA7G3 8RZdiCsxMu7/lRZXco2wqkSpXtZm8YYzoPiB1/OVlWw2cDBc3o24E//XdRmCC5NcyMli miQSB/BCSn0CPzX9gqCwcPO+XfVFDjhFtZsHpP1pMrcnpLVszvjw44zsLYyMScmlhbAu 6OETGriD9Tsrc4ApOeAPO6kRR7ECNymbJIMwdc+kA3kmy0jVHXsaToSmYqRCHsOcUjbq 0vVA== X-Gm-Message-State: AOAM532ikhs8Ingi0vq45q2NQcUOIf3NvaNQhYuNxnr+TBFkSpLuXRc2 v1B/kJWLz+HRaUsDjS1LHWn3rA== X-Google-Smtp-Source: ABdhPJyTBcvoxYT1UazLo75DFYLRiAcTN2BKdr2FfvtOwvNd4cqBc9u77mrXNn/DJzvrSUbkCYr6XQ== X-Received: by 2002:a17:902:f683:b0:138:fe47:4e47 with SMTP id l3-20020a170902f68300b00138fe474e47mr675191plg.60.1630518617183; Wed, 01 Sep 2021 10:50:17 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id o10sm122146pfk.212.2021.09.01.10.50.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Sep 2021 10:50:16 -0700 (PDT) Date: Wed, 1 Sep 2021 17:50:12 +0000 From: Sean Christopherson To: David Hildenbrand Cc: jejb@linux.ibm.com, Andy Lutomirski , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm list , Linux Kernel Mailing List , Borislav Petkov , Andrew Morton , Joerg Roedel , Andi Kleen , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , "Peter Zijlstra (Intel)" , Ingo Molnar , Varad Gautam , Dario Faggioli , the arch/x86 maintainers , linux-mm@kvack.org, linux-coco@lists.linux.dev, "Kirill A. Shutemov" , "Kirill A . Shutemov" , Sathyanarayanan Kuppuswamy , Dave Hansen , Yu Zhang Subject: Re: [RFC] KVM: mm: fd-based approach for supporting KVM guest private memory Message-ID: References: <61ea53ce-2ba7-70cc-950d-ca128bcb29c5@redhat.com> <9ec3636a-6434-4c98-9d8d-addc82858c41@www.fastmail.com> <0d6b2a7e22f5e27e03abc21795124ccd66655966.camel@linux.ibm.com> <1a4a1548-7e14-c2b4-e210-cc60a2895acd@redhat.com> <4b863492fd33dce28a3a61662d649987b7d5066d.camel@linux.ibm.com> <214ca837-3102-d6d1-764e-6b4cd1bab368@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <214ca837-3102-d6d1-764e-6b4cd1bab368@redhat.com> Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b="tX+iQK/X"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of seanjc@google.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=seanjc@google.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 56D3C1904 X-Stat-Signature: bao1djz4fi8phnyzgrjbs8zn3m7qnhb8 X-HE-Tag: 1630518618-246688 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, Sep 01, 2021, David Hildenbrand wrote: > > > > Well not necessarily, but it depends how clever we want to get. If > > > > you look over on the OVMF/edk2 list, there's a proposal to do guest > > > > migration via a mirror VM that invokes a co-routine embedded in the > > > > OVMF binary: > > > > > > Yes, I heard of that. "Interesting" design. > > > > Heh, well what other suggestion do you have? The problem is there > > needs to be code somewhere to perform some operations that's trusted by > > both the guest and the host. The only element for a confidential VM > > that has this shared trust is the OVMF firmware, so it seems logical to > > use it. > > > > Let me put it this way: I worked with another architecture that doesn't > fault on access of a secure page, but instead automatically exports/encrypts I thought s390 does fault on insecure accesses to secure pages, and it's the kernel's fault handler that "automatically" converts the page? E.g. trap 0x3d -> do_secure_storage_access() -> arch_make_page_accessible(). > it so it can be swapped. It doesn't send a MCE and kills the host. It > doesn't require fancy code in the guest firmware to export a page. > > The code runs in the ultravisor -- yes, I'm talking about s390x. Now, I am > not an expert on all of the glory details of TDX, SEV, ... to say which > attack surface they introduced with that design, and if it can't be > mitigated. I can only assume that there are real reasons (e.g., supporting > an ultravisor is problematic, patents? ;) ) why x86-64 is different. > > So whenever I see something really complicated to work around such issues, > it feels to me like a hardware/platform limitation is making our life hard > and forces us to come up with such "interesting" designs. Oh, 100% agree, the TDX "limitation" of poisoning cache line and leaving a land mine to trip over is absolutely abhorrent. SEV-ES and SEV aren't much better in that they happily corrupt guest memory. I am quite jealous of s390 behavior of simply faulting on the actual access. SEV-SNP does fault on the access and could do something similar to s390, but I'm not totally convinced that's actually desirable as it has ramifications with respect to debugging host and/or guest. But it'd be nice to have the option... > Sure, it's logical in this context, but it feels like "The house doesn't Heh, for some definitions of "logical". > have a door, so I'll have to climb through the window.". It gets the job > done but isn't ideally what you'd want to have. If you understand what I am > trying to say :) > >