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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 86D66C433F5 for ; Fri, 12 Nov 2021 21:40:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1E11360E54 for ; Fri, 12 Nov 2021 21:40:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1E11360E54 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 AC5A96B0078; Fri, 12 Nov 2021 16:40:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A73E16B007B; Fri, 12 Nov 2021 16:40:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 963116B007D; Fri, 12 Nov 2021 16:40:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0139.hostedemail.com [216.40.44.139]) by kanga.kvack.org (Postfix) with ESMTP id 886FB6B0078 for ; Fri, 12 Nov 2021 16:40:56 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 5246E8249980 for ; Fri, 12 Nov 2021 21:40:56 +0000 (UTC) X-FDA: 78801598344.19.3B6C4D9 Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) by imf30.hostedemail.com (Postfix) with ESMTP id 840FDE0019B7 for ; Fri, 12 Nov 2021 21:40:33 +0000 (UTC) Received: by mail-ot1-f49.google.com with SMTP id o15-20020a9d410f000000b0055c942cc7a0so15824407ote.8 for ; Fri, 12 Nov 2021 13:40:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sloIfHJE+iKk44+AlxrE6ZUAY0xZ35xpRmFUJf3Gn7g=; b=jbcHJF+9hw4eupohwgwDHSMp00T1Og3E98oOfGaje91bd+dB1KH7tEeFB5c9b12QZf M4SfUDdzJh6g/h8SHtMEiY/OpXQgZa1mp35EAXj0B5F0TgrglUAjwdbZeXKRKexgpfYO JeOnZeMhhCE8gyh2sFfqBX7/I9k4lZqXwrlsBgSoRfE0SUOzqVQ4eVF+1qCFkBMQh1kK 298qvzCaX1ue3cAtufn+eVTZhGsynUII+gkPfNYusg3eSIIg+qWAWt/vCVbxhZ82tHZc cGcYM6mp+5vX6aBy1DxY0HXVj3TuSIbR+XqrVr1amrcn02wI48UBN3Yh804aRilPcDTK ws/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sloIfHJE+iKk44+AlxrE6ZUAY0xZ35xpRmFUJf3Gn7g=; b=cVfYQFEjALhrSNjhx07WPYFimGDjjVCLgn6E9XNa6DCZix5ksWdonDDn6pmzDGOgP/ RTwsZN2sNfRPDzYOqBkSVac9EoQ2tj2CDKXBBmGMf/KEcAPhXTAunMKCArNBKL8cMeY8 ATDeuqaiX/e2fytMOXLbWgYGZ38zZu79qXq4Kt84o1UYAxIfCu86rjl+kJ+1NPv5hlX+ C9m9ei/E2d81GWli5UBOvS6ppyTDGBPuKagdRyuwBTDx4c0I5iWryHpU6hyKSiF+/Q5E f9CoQUHMefw+OTBA+5dg2ZFJa7TAxIno2KjISfOI65bZ+Yzg0diswbSuTpqS/RP1V+nr kDCw== X-Gm-Message-State: AOAM532A9Oh1jCuRmES0nWj8lX6/SRw5/doV9WEYXp9ew0lzMt6GsLyJ fr3JrEck+J/TH/QBDtDIXWdMeEeFjHiWL441Hf/m/A== X-Google-Smtp-Source: ABdhPJzJAeqA1sayja54+gOvTJNTZu3qoAAJtDM/QZXI4YyzJUymLHcSZzFuIQbvvaE/f6iQ+J28yRbXzpfZhgNiSG4= X-Received: by 2002:a05:6830:1aee:: with SMTP id c14mr15114563otd.25.1636753255031; Fri, 12 Nov 2021 13:40:55 -0800 (PST) MIME-Version: 1.0 References: <20210820155918.7518-1-brijesh.singh@amd.com> <061ccd49-3b9f-d603-bafd-61a067c3f6fa@intel.com> <48e20b96-3995-6998-56cf-3f15694c5db2@intel.com> In-Reply-To: <48e20b96-3995-6998-56cf-3f15694c5db2@intel.com> From: Marc Orr Date: Fri, 12 Nov 2021 13:40:43 -0800 Message-ID: Subject: Re: [PATCH Part2 v5 00/45] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support To: Dave Hansen Cc: Sean Christopherson , Borislav Petkov , Peter Gonda , Brijesh Singh , x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Michael Roth , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , tony.luck@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 840FDE0019B7 X-Stat-Signature: x8c34tfwsjgha6jser1sxnq9m45szqjn Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=jbcHJF+9; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf30.hostedemail.com: domain of marcorr@google.com designates 209.85.210.49 as permitted sender) smtp.mailfrom=marcorr@google.com X-HE-Tag: 1636753233-83588 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 Fri, Nov 12, 2021 at 1:38 PM Dave Hansen wrote: > > On 11/12/21 1:30 PM, Marc Orr wrote: > > In this proposal, consider a guest driver instructing a device to DMA > > write a 1 GB memory buffer. A well-behaved guest driver will ensure > > that the entire 1 GB is marked shared. But what about a malicious or > > buggy guest? Let's assume a bad guest driver instructs the device to > > write guest private memory. > > > > So now, the virtual device, which might be implemented as some host > > side process, needs to (1) check and lock all 4k constituent RMP > > entries (so they're not converted to private while the DMA write is > > taking palce), (2) write the 1 GB buffer, and (3) unlock all 4 k > > constituent RMP entries? If I'm understanding this correctly, then the > > synchronization will be prohibitively expensive. > > Are you taking about a 1GB *mapping* here? As in, something us using a > 1GB page table entry to map the 1GB memory buffer? That was the only > case where I knew we needed coordination between neighbor RMP entries > and host memory accesses. > > That 1GB problem _should_ be impossible. I thought we settled on > disabling hugetlbfs and fracturing the whole of the direct map down to 4k. No. I was trying to give an example where a host-side process is virtualizing a DMA write over a large buffer that consists of a lot of 4k or 2MB RMP entries. I picked 1 GB as an arbitrary example.