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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A742C433DB for ; Fri, 12 Feb 2021 18:38:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 96DC064E8E for ; Fri, 12 Feb 2021 18:38:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 96DC064E8E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=amacapital.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2BE828D0080; Fri, 12 Feb 2021 13:38:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 247BB8D0060; Fri, 12 Feb 2021 13:38:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 09A818D0080; Fri, 12 Feb 2021 13:38:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0226.hostedemail.com [216.40.44.226]) by kanga.kvack.org (Postfix) with ESMTP id E117E8D0060 for ; Fri, 12 Feb 2021 13:38:28 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A8C1081D7 for ; Fri, 12 Feb 2021 18:38:28 +0000 (UTC) X-FDA: 77810476296.05.end37_0d14a2827623 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 8BA10181A348A for ; Fri, 12 Feb 2021 18:38:28 +0000 (UTC) X-HE-Tag: end37_0d14a2827623 X-Filterd-Recvd-Size: 5334 Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Fri, 12 Feb 2021 18:38:28 +0000 (UTC) Received: by mail-pf1-f177.google.com with SMTP id 189so46083pfy.6 for ; Fri, 12 Feb 2021 10:38:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=adayvDxf+kuTvmTwkUFdqK4+N9a6TuQ0zVRI9iA+1kE=; b=f4x21HM3hkxSqZnDpcg2U8pXOJWz92xfzDlMKcCAgr9HSWHT/n3xF5JWCjntQd2rQf Y2Rxadvf8Sf9h/m+8QAmItJ+q7/R2EmkV9c+UPoT6c55hB1TUk50E/AAIxT8hahiGHNk lt8y5jVgYqQXld4ZIA8b+9eNffh5kxn55zvlFd0NT2aZCtxmLHhkeQjhPbHGDZo0g+Ti P960YLfgaDJt+DD9bv6it3dWe1X+dnhilrc14QE8laJnSOWhsb59tWKZ9tz/FjZoY3Mx 3Jpvc1v1GAtjXhcQdXcPp1c5oRqH1ZPsxKSQ88SYXvZR5LEc5StWBQAYJQUcMM8XS9u3 uM7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=adayvDxf+kuTvmTwkUFdqK4+N9a6TuQ0zVRI9iA+1kE=; b=l8fwldTkq3wbjMM8IaZcMFySpXGKr6qJDDHsGeH9BT/G4XcvH7ALSsKnBeNhNSdSYV Xcu+4HF1MY8O0Knx4dH3nabFz7Z03JVWl32KMotISX/bwt4ExwL20VURqDnQFZZwsM1A aeWcCiemnEsjyUZoKnGMm4pyQi4lf5aCLQtjf/lTgGboEUn3sQ1PE+b+yu/Irw+GnMbR xD0i30anndrQbcpt6PLIzT9Q9svk1GmjSD57/qewwmezSY+mlPgxG8W0PDA3JPFZPX8F KXhTQlccVO39jWi7CUpX+NRJeoqpOc7riUaeKEzXcE55SGTn7z5JNMiW6LFqy7jZrVD2 aZ1w== X-Gm-Message-State: AOAM531Bnbpv16ETr4uZBICHyUDpLD/VtphnQ/OPeP8nNeBWX6Ak7XMK Jlk33kZID+2Bm+/RQwrlozxuDw== X-Google-Smtp-Source: ABdhPJx+zxkcQAHlClh3Guqj2t8Gb/LvkddJiaI2/J4goEjDTMAiqf9EadpQ6TTdFQqs+ehDVJGkpQ== X-Received: by 2002:a62:a108:0:b029:1c1:119b:8713 with SMTP id b8-20020a62a1080000b02901c1119b8713mr4290950pff.74.1613155107031; Fri, 12 Feb 2021 10:38:27 -0800 (PST) Received: from ?IPv6:2601:646:c200:1ef2:70f0:3400:772e:fd77? ([2601:646:c200:1ef2:70f0:3400:772e:fd77]) by smtp.gmail.com with ESMTPSA id c77sm10754110pfb.138.2021.02.12.10.38.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Feb 2021 10:38:26 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andy Lutomirski Mime-Version: 1.0 (1.0) Subject: Re: AMD SEV-SNP/Intel TDX: validation of memory pages Date: Fri, 12 Feb 2021 10:38:23 -0800 Message-Id: <99A30122-95A8-42CA-96CD-CAD71A1509F1@amacapital.net> References: Cc: Dave Hansen , Peter Zijlstra , Joerg Roedel , David Rientjes , Borislav Petkov , Andy Lutomirski , Andrew Morton , "Kirill A. Shutemov" , Andi Kleen , Brijesh Singh , Tom Lendacky , Jon Grimm , Thomas Gleixner , Christoph Hellwig , Paolo Bonzini , Ingo Molnar , x86@kernel.org, linux-mm@kvack.org In-Reply-To: To: Sean Christopherson X-Mailer: iPhone Mail (18D52) 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 Feb 12, 2021, at 10:22 AM, Sean Christopherson wrot= e: >=20 > =EF=BB=BFOn Fri, Feb 12, 2021, Dave Hansen wrote: >>> On 2/12/21 8:45 AM, Peter Zijlstra wrote: >>> But you're right, if a HV injects #VE in the syscall gap and gets a >>> concurrent CPU to 'fix' the exception frame (which then lives on the >>> user stack) the handler might never know it went ga-ga. >>>=20 >>> Is this something the TDX thread model covers? A malicous HV and a TDX >>> guest co-operating to bring down the guest kernel. >>=20 >> I'll say this: The current TDX guest code that Sathya posted is >> predicated on an assumption that an malicious HV can not inject a #VE in >> the syscall gap, or any of the other sensitive paths. >>=20 >> A #VE in the syscall gap is just as fatal as a #PF or #GP would be >> there. If TDX can't provide guarantees to the guest that a #VE won't >> happen there, then TDX is broken, or the kernel implementation is broken.= >>=20 >> If anyone knows of any way for a HV to inject #VE in the syscall gap, >> please speak up. Better to know now. >=20 > Removing and reinserting the SYSCALL page (or any other page touched in th= e > SYSCALL gap) will result in a #VE, as TDX behavior is to generate a #VE on= an > access to an unaccepated. >=20 > Andy L pointed out this conundrum a while back. My hack idea to "solve" t= his > was to add an API to the TDX-Module that would allow the guest kernel to d= efine > a set of GPAs that must never #VE. >=20 > https://lkml.kernel.org/r/20200825171903.GA20660@sjchrist-ice Is the TDX module involved in #HV delivery? Just how much cleverness is pos= sible without silicon changes?=