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 87298C433EF for ; Fri, 12 Nov 2021 21:12:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 32CD160724 for ; Fri, 12 Nov 2021 21:12:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 32CD160724 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 A6F1A6B0075; Fri, 12 Nov 2021 16:12:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A1F366B007B; Fri, 12 Nov 2021 16:12:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E9216B0078; Fri, 12 Nov 2021 16:12:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0194.hostedemail.com [216.40.44.194]) by kanga.kvack.org (Postfix) with ESMTP id 778BC6B0075 for ; Fri, 12 Nov 2021 16:12:33 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 2DF2C1829804B for ; Fri, 12 Nov 2021 21:12:33 +0000 (UTC) X-FDA: 78801526986.11.E9E90BB Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf17.hostedemail.com (Postfix) with ESMTP id B536EF0003AF for ; Fri, 12 Nov 2021 21:12:32 +0000 (UTC) Received: by mail-lf1-f43.google.com with SMTP id b40so25398436lfv.10 for ; Fri, 12 Nov 2021 13:12:32 -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=Dn+bcXMxMVbConI0dzzOMHuL8/svkzu+Wwj+qbiR4x8=; b=EdzZWhK+twSP8CvwCQlYnN86NLSH4z6uOIKjsX+ieqtsfgIe6iwn4m5q/+wYMjmvo6 062jaDfetxnssAtPg2E/mW7NYDChxtGhOUICnrA7EEJ9XXAMCppnsFgGyZmfJ/yKdjLs s2Z32/7worYPlLhueFmEQv5FTZV6YFWp1RMdOwWJEb/Bb6W+jZgQ6g7FWwJj9uSLrdaQ YBa2H5x5he1yz1h5IuS5JWT8EBlkiVVwdHu6BBUI4yLYa/pa4GYqIL4LegYmg1IyiLJG p3kAsDZK8tDm9KQPdFVvoor0H2zgZJMx9Rw01hfOViR7D8pDtJO5Uvmdy3AlsAooISbU 9zaA== 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=Dn+bcXMxMVbConI0dzzOMHuL8/svkzu+Wwj+qbiR4x8=; b=0hwku00a4JHjPzpErttlmMQtXWusWr+oprz8zRHz+uFc70M0o+Q6/ANlp+H3j78LH2 eBKofUIcsBkcjg+/zD2dRa/QKAe5ud/ynlAoXHmZOp6YgAL5LtwAK/MnziOBVH5YQxvk dako6GKb8sGk/eo0d/GemIWx7YnGYHf2hNPn4FDWtdoPBZPkFVrLre2V1PK5Ibamnzxp d3qcasj8fbKozj9X6C6mhEXz1CztBy1B5T68hqeXq5fGK4AUjcAuFwBwePVc6D6eUAtc kvCeUV82Z9oVe8jTyhd1m62+RE7OyChJFzDrO/Rn4Qil7HCyFzZVZvcOLSKPCUytE/GF slqQ== X-Gm-Message-State: AOAM5322wa4NF0S8pW0w5AHbwnb0n2lTT0Xvbqgki0m8i8QzQLtPNc0A s8ZLX91V1jn42zkVsivqWStvWPf0ilWYfUuh+f1y8Q== X-Google-Smtp-Source: ABdhPJx0zv9oZiVhO/YNxkJ7L7PIPrKlq6CA5xheWOUfHI/cpWmE7wF5mKEaWrnaVRWPNR0426TS6C177SQB4l0qALk= X-Received: by 2002:a05:6512:39c4:: with SMTP id k4mr15332635lfu.79.1636751550683; Fri, 12 Nov 2021 13:12:30 -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: Peter Gonda Date: Fri, 12 Nov 2021 14:12:19 -0700 Message-ID: Subject: Re: [PATCH Part2 v5 00/45] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support To: Borislav Petkov Cc: Sean Christopherson , Dave Hansen , 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, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B536EF0003AF X-Stat-Signature: 8uc37rapcug839896nx6kss86s1h1xyj Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=EdzZWhK+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf17.hostedemail.com: domain of pgonda@google.com designates 209.85.167.43 as permitted sender) smtp.mailfrom=pgonda@google.com X-HE-Tag: 1636751552-558023 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:55 PM Borislav Petkov wrote: > > On Fri, Nov 12, 2021 at 08:37:59PM +0000, Sean Christopherson wrote: > > Let userspace decide what is mapped shared and what is mapped private. > > With "userspace", you mean the *host* userspace? > > > 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. > > That SIGSEGV is generated by the host kernel, I presume, after it checks > whether the memory belongs to the guest? > > > - if kernel accesses guest private memory, it does BUG/panic/oops[*] > > If *it* is the host kernel, then you probably shouldn't do that - > otherwise you just killed the host kernel on which all those guests are > running. I agree, it seems better to terminate the single guest with an issue. Rather than killing the host (and therefore all guests). So I'd suggest even in this case we do the 'convert to shared' approach or just outright terminate the guest. Are there already examples in KVM of a KVM bug in servicing a VM's request results in a BUG/panic/oops? That seems not ideal ever. > > > - if guest accesses memory with the incorrect C/SHARED-bit, it gets killed. > > Yah, that's the easy one. > > > 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. > > I like the explicit nature of this but devil's in the detail and I'm no > virt guy... This seems like a reasonable approach that can help with the issue of terminating the entity behaving poorly. Could this feature be an improvement that comes later? This improvement could be gated behind a per VM KVM CAP, a kvm module param, or insert other solution here, to not blind side userspace with this change? > > > 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. > > Yah, the #MC thing sounds like someone didn't think things through. ;-\ Yes #MC in TDX seems much harder to deal with than the #PF for SNP. I'd propose TDX keeps the host kernel safe bug not have that solution block SNP. As suggested above I like the idea but it seems like it can come as a future improvement to SNP support. > > Thx. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette