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 A5F28C433FE for ; Fri, 12 Nov 2021 21:40:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 895DA61078 for ; Fri, 12 Nov 2021 21:40:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235803AbhKLVns (ORCPT ); Fri, 12 Nov 2021 16:43:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54812 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231877AbhKLVnq (ORCPT ); Fri, 12 Nov 2021 16:43:46 -0500 Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D7215C061766 for ; Fri, 12 Nov 2021 13:40:55 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id u18-20020a9d7212000000b00560cb1dc10bso15794307otj.11 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=p5vp19QbeOkZ2HErMLt9nfa+Q9oRJHZiYGjSytrHZi/S6rt/R4LFdf49aMrH1V8AUt LR9TbU9HvVpu7J8YvwoDlNHoQoRFx2tyBcUo80au8/daOVWcb4gXr8zgfSJ1ubGF03HU tUCBVBdRNtKSCG1eUXu1dCkNoRKLTM7yzrByV3enzkhtJNTBoUJIGt9fh1s6s70G9tmF Ug30+Y37+0JsM4Di5BgjZ5C3ehOtxOFqQHyw8HmFlINWyhlssOClxjkf2uEwc8qVzHGa Kbdgy/efEjo2yw5z8WLXcRvVuTrl/hxGCFQnyFLmnofDew6LLmrhGbHrVzrLMVhB6ZMT Vf4A== X-Gm-Message-State: AOAM530PTfWtkf9ZJTKbCTXNA+mje4cnqoVTiHv631o4fVh00D1sCJFZ NQ+USegmtsL0DBFwR9ffhB6kVcapc6f6ZWRQN7oRDw== 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.