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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 13DD1C433E0 for ; Fri, 12 Feb 2021 18:22:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 87E2D64E8E for ; Fri, 12 Feb 2021 18:22:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 87E2D64E8E 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 079728D007B; Fri, 12 Feb 2021 13:22:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 027798D0060; Fri, 12 Feb 2021 13:22:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E814F8D007B; Fri, 12 Feb 2021 13:22:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0026.hostedemail.com [216.40.44.26]) by kanga.kvack.org (Postfix) with ESMTP id D0FEF8D0060 for ; Fri, 12 Feb 2021 13:22:10 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 94E2F182056CC for ; Fri, 12 Feb 2021 18:22:10 +0000 (UTC) X-FDA: 77810435220.04.bear43_030a1e927623 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 7530E80170F1 for ; Fri, 12 Feb 2021 18:22:10 +0000 (UTC) X-HE-Tag: bear43_030a1e927623 X-Filterd-Recvd-Size: 5249 Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Fri, 12 Feb 2021 18:22:09 +0000 (UTC) Received: by mail-pg1-f175.google.com with SMTP id m2so198866pgq.5 for ; Fri, 12 Feb 2021 10:22:09 -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:in-reply-to; bh=hfHmf3BBnIvQKhqOMP1XUo7y9/B+CkXlMhvpG94aWAw=; b=j5x/XFMbDRFnHLZFtfkPpQuJl9llXou570N82/t+1grFQRCGWj4EMYCVvr2tfUER1u 6pI2wtolQ++/GfjXoGHTCmHYP8Tv7zb1y/e+FaCNVe55e9ob1mJXo/y5r952pwP6rRiQ xQ+SJEnK8RnkEYv1Wfhibvu5T5NLyQFc5CytA799mxuq+4RYezUiiikwJGFrjqESr/Px dCW/RQY9xtlBN4ZrYUrIdvPMBbk+A8Mvi+lN42X/hPXCyR5NDuT4GyLxjoNGZLf/VhJl 1vAgOM8l09RuRyR54QpVEHeJyo05RPsNdKE5juXY4RBVaflN//QKSYTMqQuQoZ+uV57P MLqA== 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:in-reply-to; bh=hfHmf3BBnIvQKhqOMP1XUo7y9/B+CkXlMhvpG94aWAw=; b=jTdk4hFGgjkoarX1sfXx64g6Ascbae7xDHJ3QW53bUIAKK81tPqbGHZmsN4MMV3suh /tva+EuKw4S3JgyO0QhMV7+o+vTlyiH9jEz/ARB3BwW0MkxinuPNHqRoQk6sV5/NhAji VezVvNkG7ijvROPWiCXv5ML3IWmmU57SDog2Rq2O1vWCD8uPG1de/pmqc/QsAYGIZ03x vVQQJtWng8i23nFba6RSlNWfy5IBnZ89PwlZWuxdMPhxfW3OVhy60q0cn7T/MY2zUStB IA+VOjtHaJZHNV9dLhl6r3DA3w0r8LKgWZqiAkJLICFZ1st+UH8s5y6pspNrRUNPX/nA T/PQ== X-Gm-Message-State: AOAM5327hgiU0B9VtQWg/xleQtskAEqmyBBMwDpAo6UWUPP490umni43 FYpHhaeUbKtBmHDXLX2RdrFwIA== X-Google-Smtp-Source: ABdhPJx1hta7zfarHAwDjyo4bFeGRjXz2brks9BcbtW2pOdiFhhNkG5zy9hsqWUCk1B6MbUn73qu7A== X-Received: by 2002:a63:c148:: with SMTP id p8mr4344665pgi.188.1613154128740; Fri, 12 Feb 2021 10:22:08 -0800 (PST) Received: from google.com ([2620:15c:f:10:f588:a708:f347:3ebb]) by smtp.gmail.com with ESMTPSA id u3sm10354589pfm.144.2021.02.12.10.22.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Feb 2021 10:22:08 -0800 (PST) Date: Fri, 12 Feb 2021 10:22:01 -0800 From: Sean Christopherson To: Dave Hansen Cc: 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: <7515a81a-19e-b063-2081-3f5e79f0f7a8@google.com> <20210212131907.GI5453@suse.de> <20210212145318.GK5453@suse.de> <20210212152813.GA28884@suse.de> <20210212161849.GB28884@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, 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. > > > > Is this something the TDX thread model covers? A malicous HV and a TDX > > guest co-operating to bring down the guest kernel. > > 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. > > 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. > > If anyone knows of any way for a HV to inject #VE in the syscall gap, > please speak up. Better to know now. 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. Andy L pointed out this conundrum a while back. My hack idea to "solve" 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. https://lkml.kernel.org/r/20200825171903.GA20660@sjchrist-ice