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.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,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 9D555C433DB for ; Fri, 12 Feb 2021 18:43:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 20C0264E9C for ; Fri, 12 Feb 2021 18:43:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 20C0264E9C Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A77978D0081; Fri, 12 Feb 2021 13:43:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D9958D0060; Fri, 12 Feb 2021 13:43:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F0DE8D0081; Fri, 12 Feb 2021 13:43:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0090.hostedemail.com [216.40.44.90]) by kanga.kvack.org (Postfix) with ESMTP id 741D28D0060 for ; Fri, 12 Feb 2021 13:43:57 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 3BA491801A230 for ; Fri, 12 Feb 2021 18:43:57 +0000 (UTC) X-FDA: 77810490114.09.skin81_080eef527623 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id 22A9D1804F1BD for ; Fri, 12 Feb 2021 18:43:57 +0000 (UTC) X-HE-Tag: skin81_080eef527623 X-Filterd-Recvd-Size: 5800 Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Fri, 12 Feb 2021 18:43:56 +0000 (UTC) Received: by mail-pg1-f170.google.com with SMTP id r38so208297pgk.13 for ; Fri, 12 Feb 2021 10:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=OH3pAw4Q95a6Yy21lX/dHi89D/tzSFs/Wje6Saa32wk=; b=o41LmrygWKSNo+FdExmK7lZzK83VZEN1FrHvlVnuVrwNFDlywUgsdS2/FSp4hkh370 i2p/iwst0bo7S3MKi/Om319FgeYX95w8lGcW2W5d0fsOMAzbiqasnt0fcIGArrcRsr5Q 6X7huER/n+WzJ8sDkZQHDAaG+fhcw03aMKxwo18v+3Fu7d+THIJNStJ5xMmB0mBzlkGw HvQo8Be1e4wG7MdK4NLQXW4yk8AUjCUSuZW19HXVrT/04GAAFD3PUMdUbCpci0FI0wVu 8SBepk03djjSCIkY9ycCV2SVMjxIVkDq7p/u2aH597455dY3JuPOTdpdS9K2Dgw69MQd C2WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=OH3pAw4Q95a6Yy21lX/dHi89D/tzSFs/Wje6Saa32wk=; b=qH4aw4U8hU5/YG90JBBPyN2ydC0sLqxeA7ls8bcWur7U98X3iqulDyq8OGu0YnA3HU G/52mhYzWlXcVUk5FrEQOIELG/4/AXo8hbbk1/vIBEE5d7aVe552DPKZw9E198bH12zF qYoGr2NTLTNoz0ZBSNsWyRCbIongf78oPGR91zm0Y7lnO9LBvoXqK5pd7X6/U9vaW1kb LVzuwdVr7uHhk0NcP39OsBqkVswzx2Zb2ub/ahveapxQyJi9MnzqMus1sELuFm7I3fCW rT7ZZ88jT7ok9Gsxq9JwAp9okQ3IrrygyAdbUq0HMkPT7hpc5JeUkiN4+bsEVZH9QOox RZrA== X-Gm-Message-State: AOAM530iHbpJggddH2yDIwhjPCCUrqLeo8bM9/NRYLUF7Ed71exlDqsp nBncnpXaXwqoDuKyeLnPnGwB/g== X-Google-Smtp-Source: ABdhPJwiv12O79wcUd0A3ZWOW6KDQhQRQrrVh0s41zHL/LvH1fo8kuFMNvm2mf4UhZUqOOaStpwsag== X-Received: by 2002:aa7:8f2a:0:b029:1d5:d250:9d40 with SMTP id y10-20020aa78f2a0000b02901d5d2509d40mr4204415pfr.46.1613155435579; Fri, 12 Feb 2021 10:43:55 -0800 (PST) Received: from google.com ([2620:15c:f:10:b407:1780:13d2:b27]) by smtp.gmail.com with ESMTPSA id u17sm9388042pfn.5.2021.02.12.10.43.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Feb 2021 10:43:54 -0800 (PST) Date: Fri, 12 Feb 2021 10:43:48 -0800 From: Sean Christopherson To: Andy Lutomirski 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 Subject: Re: AMD SEV-SNP/Intel TDX: validation of memory pages Message-ID: References: <99A30122-95A8-42CA-96CD-CAD71A1509F1@amacapital.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <99A30122-95A8-42CA-96CD-CAD71A1509F1@amacapital.net> Content-Transfer-Encoding: quoted-printable 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, Feb 12, 2021, Andy Lutomirski wrote: >=20 > > On Feb 12, 2021, at 10:22 AM, Sean Christopherson = wrote: > >=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 th= e > >>> 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 #V= E 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 br= oken. > >>=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 the > > 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 "sol= ve" this > > was to add an API to the TDX-Module that would allow the guest kernel= to define > > a set of GPAs that must never #VE. > >=20 > > https://lkml.kernel.org/r/20200825171903.GA20660@sjchrist-ice >=20 > Is the TDX module involved in #HV delivery? Just how much cleverness i= s > possible without silicon changes? In this case, yes. TDD-Module controls the Secure EPT PTEs, including th= e SUPPRESS_VE bit. Specifically, for unaccepated pages, the SUPPRESS_VE bi= t is cleared so that accesses will be reflected by hardware as #VEs instead of causing EPT violation VM-Exit. The untrusted hypervisor manages resources, but any changes to S-EPT must= be routed through TDX-Module.