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 1552EC433E0 for ; Fri, 12 Feb 2021 19:24:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6321664DD6 for ; Fri, 12 Feb 2021 19:24:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6321664DD6 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 CCB3F6B011F; Fri, 12 Feb 2021 14:24:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C7D006B0121; Fri, 12 Feb 2021 14:24:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B20718D0060; Fri, 12 Feb 2021 14:24:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0044.hostedemail.com [216.40.44.44]) by kanga.kvack.org (Postfix) with ESMTP id 9C2546B011F for ; Fri, 12 Feb 2021 14:24:52 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 6694C824805A for ; Fri, 12 Feb 2021 19:24:52 +0000 (UTC) X-FDA: 77810593224.26.mass23_260e25327623 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 4A45D1813F4BA for ; Fri, 12 Feb 2021 19:24:52 +0000 (UTC) X-HE-Tag: mass23_260e25327623 X-Filterd-Recvd-Size: 6266 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Fri, 12 Feb 2021 19:24:51 +0000 (UTC) Received: by mail-pj1-f48.google.com with SMTP id fa16so189114pjb.1 for ; Fri, 12 Feb 2021 11:24:51 -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=6cVjPvvUWmuc+AIyealtrE3PHqfBt48SH+TVxx91wcU=; b=lZ/pcKRl4cYNuvC1VirWV/QS3SFfn0jdoNrRiVynYY5WQiHhofAJl7L96BXwN77pnD hywZm+Fto7XLCHFJVUNQvXnl0xd4Jt0ykhek0Bg5I0badtaHXAy8su9SVrO4i46VzrIx PD+A8JPGCJ7calrTIW98kS+IOfS2k+fEhPFec8jySiIfkUGR0FuSOSHdW3uhwoRFNeyX ZInLnyA8LKHfXU0Xfln9ULdpYQhfKU77sK7w4Daqa2+UQOcsaxieGYmhLnKEo2pVSZE4 3iNZSu/y0BCOsw+AoQVb2zn3ZrNua19CNQ5tmEl81rFbFPAhYgxRV1hWCP31OFwxX2DC hipg== 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=6cVjPvvUWmuc+AIyealtrE3PHqfBt48SH+TVxx91wcU=; b=Qaybdu/cQTXgjV2U19OJlTlJK36slX4PcSNP0MR7hnJVxYo0l0rUX0C9iFkPtw/3H5 F6UKWxn3dbzsRtzrd7S2qeyXZcnpGNwPTDHf2BABTX8nyP2GzmsV9d+erWDmDwQqe1Ct +6pNFZ6iVDTY2fJi+wXBCdM0ZDzKhmAoMTKwA73ZeWR2YMPPIACfe9I9/nTOggwf0wn+ kTG1Fr/lKMjQG4istga6c5Fsjvng5Do4uettp8UKpqBpTtAZzdSggtVVbSSbZLMMnzlC QmT/aSVpnAAaCKFOzvb1yzlpMas2GYy47vFcvHljvJdLR8iLOZ79QmiIUxnhIbpj/uc4 rVjg== X-Gm-Message-State: AOAM530nKtadEo/p0SyE0uhzGGKWpKfjQ1kchg3lTIE4IXE/+hIS8CsU YSdrN5rBA+SqNF19Tp6xEBEppw== X-Google-Smtp-Source: ABdhPJzNjiFQZN4sBauqVs9mZZ5P2//3D3Zxy43ag6kKh9WNMbT4ZqO0mmI0F+LORoAgLfswpxO4QQ== X-Received: by 2002:a17:902:e881:b029:de:593d:82ca with SMTP id w1-20020a170902e881b02900de593d82camr4094440plg.82.1613157890438; Fri, 12 Feb 2021 11:24:50 -0800 (PST) Received: from google.com ([2620:15c:f:10:b407:1780:13d2:b27]) by smtp.gmail.com with ESMTPSA id v31sm10303329pgl.76.2021.02.12.11.24.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Feb 2021 11:24:49 -0800 (PST) Date: Fri, 12 Feb 2021 11:24:42 -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: <20210212145318.GK5453@suse.de> <20210212152813.GA28884@suse.de> <20210212161849.GB28884@suse.de> <2ab1de5b-58bb-30f9-7fd7-9d3a7efa7d36@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2ab1de5b-58bb-30f9-7fd7-9d3a7efa7d36@intel.com> 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 10:22 AM, Sean Christopherson wrote: > >> 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 > > Reminds me of the "what has to be mapped into userspace?" exercise for > PTI. That was fun. > > Really, the hypervisor shouldn't be able to cause #VE's. This should be > fatal to the guest, period. Or, worst case scenario, Linux should be > able to set a bit that says, I will only run under sane hypervisors. If > I somehow lose a bet and get a crappy, insane hypervisor, I want take my > ball and go home: don't even bother running me any more. Hmm, #VEs and #VCs are required for lazy-accept/pvalidate, and for converting pages between private and shared. Those #VEs/#VCs are technically caused by the hypervisor. What I think we want is to prevent the hypervisor from removing an accepted page without an explicit action from the guest. For TDX, IIRC, one of the motivations for allowing the host to remove a page without an explicit action from the guest was to prevent the guest from holding pages hostage. But, if the guest isn't playing nice, the hypervisor can just kill it. So for TDX, I _think_ we could dodge this bullet by making MAP_GPA an API provided by the TDX module so that the module can track which pages are allowed to be removed by the host. The S-EPT entry could be made not-present on MAP_GPA(SHARED) and tagged as being removable. Since the page is not-present, there should be plenty of bits available in the entry to do the tagging. The big question, other than if the above idea is actually feasible, is if page migration in the host would require the guest to re-accept the new page. That would throw a wrench into the whole thing. > No way do we want another fragile list of magic pages that we have to > maintain.