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 006E1C433F5 for ; Fri, 12 Nov 2021 21:16:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8DEE7608FB for ; Fri, 12 Nov 2021 21:16:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8DEE7608FB 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 0F51D6B0075; Fri, 12 Nov 2021 16:16:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A3E46B0078; Fri, 12 Nov 2021 16:16:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED4A26B007B; Fri, 12 Nov 2021 16:16:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0029.hostedemail.com [216.40.44.29]) by kanga.kvack.org (Postfix) with ESMTP id DFA5A6B0075 for ; Fri, 12 Nov 2021 16:16:54 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A07C9805C0 for ; Fri, 12 Nov 2021 21:16:54 +0000 (UTC) X-FDA: 78801537948.13.B89EC13 Received: from mail-oo1-f41.google.com (mail-oo1-f41.google.com [209.85.161.41]) by imf08.hostedemail.com (Postfix) with ESMTP id F3CA630000B5 for ; Fri, 12 Nov 2021 21:16:38 +0000 (UTC) Received: by mail-oo1-f41.google.com with SMTP id t7-20020a4aadc7000000b002b8733ab498so3358594oon.3 for ; Fri, 12 Nov 2021 13:16:54 -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=Wss/5FTdvL/ZsvqJzpcpP0vdH9OVb8c+LLdYEkdhnSs=; b=rH4CDA2O6JCJq7jEtKrpJB3naSzfLAW3EwcXwJBgz8NHwCbEfX4Y7uVz+LkZr+hrEJ +I0JUbdCZ0Eg+jU7wr0UWgv5MDmCQEwSLGmghVhPsyXWCJLkgNTbAEEIodMi2vC+nDGP vAnO27RJCLMGr+oQH3ulQDVXl+wQnrPymGwD+C8Ct6C3DeEXgjsqVjqN+hGRnsLmOFi8 nPkzBkWeT1G3yIcW2QZxvHaZQmPv3Hr+tSGUPT0LwTUvBEwM3VTfJSuVQ97JJ6+ohD0v sm4Jcwh4byJx7uc264omN9uaYgtuYaY49B2I53HH1xF8Dj1+neZHJFB8B1P12TfFku+L wdbA== 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=Wss/5FTdvL/ZsvqJzpcpP0vdH9OVb8c+LLdYEkdhnSs=; b=6BteIrzI9pQP7BFCXSKbp+B3vf91JWdToEYsKHdAL0Stqheg30hsh9zD0LPJQmLJGi wuf3bC7KMy+ctrOp+I7W+6sda4wuVAjuWofjzn9yfLmtxc6wwjmaDFS5LhH24A+2VaLU aMJtsnehclnE+Ygyo7z/sjE32L4wuyKJYC/VjYNE6Ht7Z+VJBES8xee8KkIgEak6GplU zPf0Bf0owqn/TLwBZD+INWQyog0JZzQGcI99s0TXhHxShfjrWQCDB1n+ZLVy6ZuaJTD2 ErdUPwbf4AU1gtJZ4JKco/A0cOknoLX38tWGs+FQ3JO0aTPNwwwyBH14UD6PuzuUBdsV AAuQ== X-Gm-Message-State: AOAM5325+2MKfADqCZc+roKJb8wF56ybWtIKbuwFFMYC/tDd7iezlq8w 7trRG0Te6dEJxEYfbUlXHGc52Uyycuj5l50DvLDpnw== X-Google-Smtp-Source: ABdhPJyat1/wejZeYNbgqmYOxRGD7fk2dWxHtnIZDfKhyhl6kHLjSWImplcgB28WjBzJ96p1EICE1Qugb0LOIJXrx6U= X-Received: by 2002:a4a:dc1a:: with SMTP id p26mr10372786oov.6.1636751813173; Fri, 12 Nov 2021 13:16:53 -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:16:42 -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" Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=rH4CDA2O; spf=pass (imf08.hostedemail.com: domain of marcorr@google.com designates 209.85.161.41 as permitted sender) smtp.mailfrom=marcorr@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: F3CA630000B5 X-Stat-Signature: qw9cjronnudpjgfo3tm444q697h99h7c X-HE-Tag: 1636751798-647774 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: > > So cloud providers should have an interest to prevent such random stray > > accesses if they wanna have guests. :) > > Yes, but IMO inducing a fault in the guest because of _host_ bug is wrong. I want to push back on "inducing a fault in the guest because of _host_ bug is wrong.". The guest is _required_ to be robust against the host maliciously (or accidentally) writing its memory. SNP security depends on the guest detecting such writes. Therefore, why is leveraging this system property that the guest will detect when its private memory has been written wrong? Especially when its orders or magnitudes simpler than the alternative to have everything in the system -- kernel, user-space, and guest -- all coordinate to agree what's private and what's shared. Such a complex approach is likely to bring a lot of bugs, vulnerabilities, and limitations on future design into the picture.