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 EE68CC433F5 for ; Fri, 12 Nov 2021 21:30:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8A818610F8 for ; Fri, 12 Nov 2021 21:30:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8A818610F8 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 F15CE6B0075; Fri, 12 Nov 2021 16:30:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EC4C96B0078; Fri, 12 Nov 2021 16:30:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB3D26B007B; Fri, 12 Nov 2021 16:30:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0149.hostedemail.com [216.40.44.149]) by kanga.kvack.org (Postfix) with ESMTP id CC5886B0075 for ; Fri, 12 Nov 2021 16:30:39 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 8A2A07C39C for ; Fri, 12 Nov 2021 21:30:39 +0000 (UTC) X-FDA: 78801572598.08.BAC7DC5 Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) by imf06.hostedemail.com (Postfix) with ESMTP id 2A2EA801AB21 for ; Fri, 12 Nov 2021 21:30:39 +0000 (UTC) Received: by mail-ot1-f45.google.com with SMTP id o15-20020a9d410f000000b0055c942cc7a0so15791219ote.8 for ; Fri, 12 Nov 2021 13:30:38 -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=+vmT47JswBq7qxvW2mmjE/g946I5saxbuX5b7gNLFL4=; b=D+gcCXh1f960budU8lRnqkEeApuI8XhOqtSVvs0dvBafahJkfh0OCX/v6oi/L8uoIW h0ADo3uvGEiLXn1ziPjvl9m3NKy8i2nrGKIggbclcW73xbKNNvuhwTbPubCSDReUis3c eIrpTM53tPPkO6JjyiG+rasTsXGxT6j7LwGtTz0Rnpj2ZRHB4l6QGMWQXelwdpSTtS+M QEqML6xNRvBqkTktfaXaPii0CI20inBmaYdX4SSk2vXeTV+TI2ekReL3GTR2Jo8Txurw Bzu5soH9DfgA2BLQiucG2RibYEFf4Ht0LphtU4tl7FvlSOabHfHCqnoLbj7IQ0xlIJTV AQyw== 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=+vmT47JswBq7qxvW2mmjE/g946I5saxbuX5b7gNLFL4=; b=79BlXt/J80Gg8jUpuq2ZS6/3smoYmvoIRGBwR5qxxFgom9Ek022xwHRkazCRLjX7iQ nE+obJnyZ1oOy7Irqiwu+XP6q7X5kn8DSfsvrjmaftrROwXyU+hGV+F49bbl36LjQ2hG RPGW2+f1as3PjmSclkszT7l7fCvH4j6gqa0KxXMoPctNSvrmdN6Q0P9UwX2VKSEzw606 lrAGbMmOdiD0ZD8Zn0SejovA1z5oj5e80ZG8Z5dFUrZ+sE6VTcmX03YBnbsKYWd11xW5 Law7u1FiRUWm/QAfSSe1HoSQT5DEKf17VsEsS2/jIXCAQCk2aBrXh9bxN170mRyrr3b9 cv0Q== X-Gm-Message-State: AOAM533KSGHevVQEdNT5jqrJTiIzJozn2w0yBlM6RsCQocuAsk9n0JDO vYS8YD9KlZUleKYWyQ3+PuSGTjuMByvSkIUkm4EEoQ== X-Google-Smtp-Source: ABdhPJyx1AWCSNjtqlponw22EGcsSL4a/s3aR2bIU6ixr3xAwW099I1ZHWbBZZx2PhIrAjcNg3Rs+YuMZQEXWd8m6is= X-Received: by 2002:a9d:ed6:: with SMTP id 80mr14812790otj.35.1636752638202; Fri, 12 Nov 2021 13:30:38 -0800 (PST) MIME-Version: 1.0 References: <20210820155918.7518-1-brijesh.singh@amd.com> <061ccd49-3b9f-d603-bafd-61a067c3f6fa@intel.com> In-Reply-To: From: Marc Orr Date: Fri, 12 Nov 2021 13:30:27 -0800 Message-ID: Subject: Re: [PATCH Part2 v5 00/45] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support To: Sean Christopherson Cc: Borislav Petkov , Dave Hansen , 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: 2A2EA801AB21 X-Stat-Signature: bxz9kumtb7bu7bynbw351s5x5e5rb9de Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=D+gcCXh1; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of marcorr@google.com designates 209.85.210.45 as permitted sender) smtp.mailfrom=marcorr@google.com X-HE-Tag: 1636752639-594350 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 12:38 PM Sean Christopherson wrote: > > On Fri, Nov 12, 2021, Borislav Petkov wrote: > > On Fri, Nov 12, 2021 at 07:48:17PM +0000, Sean Christopherson wrote: > > > Yes, but IMO inducing a fault in the guest because of _host_ bug is wrong. > > > > What do you suggest instead? > > Let userspace decide what is mapped shared and what is mapped private. The kernel > and KVM provide the APIs/infrastructure to do the actual conversions in a thread-safe > fashion and also to enforce the current state, but userspace is the control plane. > > It would require non-trivial changes in userspace if there are multiple processes > accessing guest memory, e.g. Peter's networking daemon example, but it _is_ fully > solvable. The exit to userspace means all three components (guest, kernel, > and userspace) have full knowledge of what is shared and what is private. There > is zero ambiguity: > > - if userspace accesses guest private memory, it gets SIGSEGV or whatever. > - if kernel accesses guest private memory, it does BUG/panic/oops[*] > - if guest accesses memory with the incorrect C/SHARED-bit, it gets killed. > > This is the direction KVM TDX support is headed, though it's obviously still a WIP. > > And ideally, to avoid implicit conversions at any level, hardware vendors' ABIs > define that: > > a) All convertible memory, i.e. RAM, starts as private. > b) Conversions between private and shared must be done via explicit hypercall. > > Without (b), userspace and thus KVM have to treat guest accesses to the incorrect > type as implicit conversions. > > [*] Sadly, fully preventing kernel access to guest private is not possible with > TDX, especially if the direct map is left intact. But maybe in the future > TDX will signal a fault instead of poisoning memory and leaving a #MC mine. 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.