Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3268171pxb; Fri, 12 Feb 2021 13:50:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJwYfxMn3Z1uL9ron3xMlVOvqDEhogpi65K8ejA2fL8JQn+h6zRhrc93ApFg799YVEFJOCGJ X-Received: by 2002:a17:906:3801:: with SMTP id v1mr4997189ejc.353.1613166632783; Fri, 12 Feb 2021 13:50:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613166632; cv=none; d=google.com; s=arc-20160816; b=NosWPnO8ZVgWTucUsLKKQFmBdN7ExX8HB07IJE1reztby7x7iEkRrtO9PRewH/urkL 5NLS9OPjwqiyEOyMG84J0SbjanYvSPXu2QYfRRJa0kauLvhNRLlJGyZetlRyUDkE+CLY NmoFf1NDEoyHHto44pyLE4iyrX7vMME6keWjisXqP7I+FXA+W3YmamhugNvSDawKfLMp RebNGx7ccpzuR5VayT5O5AAQ4M4VRZRbstYRyV2Pwc0wd2DAAAaWXLuwXvzU4HMnEvlP jkKXZ8VF+iUtPQprM5YDDiP4SgjdQ1JNP/p5oWEAz2qZ1ui2fKdgzw4j/AqCv2hdSGJw VpBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=UIItYsS06toyTXuBC+EkkSLp3s6hUYrVVYVA5yzd3ZY=; b=YF/wgiFWEvxK+NP+8UA0y9/MMcBMJ1T6uapGtFpTZoZXnhEWfqMMBNllpXHPZl+m3/ MYM+zcdQB9qkTJWNjsjkyFuB4exo4hhkF+Ne4BqoizRmJqw2FS2Ripi2UgjVDl3I5Sz+ qBELQ9kwkn56miWGqHSKSjA5DI03q/sVULhbjyfzhUTBVVWHTlvTaL/lkJfUzUO7wk58 IEuFMVfuKj/WFdVUNR1/bhUDIYv2pbQ4O2DTXRJuJJTYXQz6BB8zCqzEmJILMKV+M0tx wIifEfPb3z6NUF+i0Rd34NCnYwncsDgV7s9mNQpHYyKxfJ/AAOJoV87K3bmqG2G42n4O +jpw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=IdvlBN3h; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cc7si2140349edb.420.2021.02.12.13.50.09; Fri, 12 Feb 2021 13:50:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=IdvlBN3h; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229679AbhBLVsP (ORCPT + 99 others); Fri, 12 Feb 2021 16:48:15 -0500 Received: from mail.kernel.org ([198.145.29.99]:35778 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229648AbhBLVsO (ORCPT ); Fri, 12 Feb 2021 16:48:14 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id EEC4064E36 for ; Fri, 12 Feb 2021 21:47:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1613166454; bh=Kv70a1+yCdYDmMZp2KaJ7CNkCDLjUtW0dJHR2g8xWPY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=IdvlBN3htDscXoj0MZ014Aa04rMJoOlQk2mFCkeO6EGFig3efhJcxvd/C5RQ788YQ HVcEBThc6kFiC/vi9+P4HYCePuYqJPWzKgXsvIALWRXPnDmZ1yPXP0K6rEVQlXSbdp ODCJgpBdacraVhAILyoUL5q4FrDTBROnK4J3q05j8ZwzXzW5iKJ02T2LK5oZVoDNJ/ jLEmZZLXN0rFBCPYy1RNM5IzgsBy0u1Y42nUcBvEaI9LARwIip+Nes77exBHZ6cBTM wHgWQH7532f725Wqi8eS2exYTryL3rcCObzTQKVSUtmbZ/5sENuUlHg/LmXFR27njx LjwELdNxIPtUw== Received: by mail-ej1-f47.google.com with SMTP id y9so1503921ejp.10 for ; Fri, 12 Feb 2021 13:47:33 -0800 (PST) X-Gm-Message-State: AOAM530NRLaaFkVjzYk+hcY/nff3c1lWr82a9KUvBmBIRDquvKo08nh1 ttB0l6y0+f4cYPirCIgLrOVkpp0s9hrl3RyekcOL/Q== X-Received: by 2002:a17:906:24d1:: with SMTP id f17mr4874863ejb.503.1613166452442; Fri, 12 Feb 2021 13:47:32 -0800 (PST) MIME-Version: 1.0 References: <48a702f536ccf953eee5778023ed6d1a452f6dcf.1612563142.git.sathyanarayanan.kuppuswamy@linux.intel.com> <8c23bbfd-e371-a7cf-7f77-ec744181547b@intel.com> <514734d9-d8be-03ee-417e-4d0ad2f56276@intel.com> <7d0b08c4-5ae7-f914-e217-767a9fae7b78@intel.com> In-Reply-To: From: Andy Lutomirski Date: Fri, 12 Feb 2021 13:47:20 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC v1 05/26] x86/traps: Add #VE support for TDX guest To: Sean Christopherson Cc: Dave Hansen , Andy Lutomirski , Kuppuswamy Sathyanarayanan , Peter Zijlstra , Andi Kleen , Kirill Shutemov , Kuppuswamy Sathyanarayanan , Dan Williams , Raj Ashok , LKML , Sean Christopherson Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 12, 2021 at 1:37 PM Sean Christopherson wrote: > > On Fri, Feb 12, 2021, Dave Hansen wrote: > > On 2/12/21 12:54 PM, Sean Christopherson wrote: > > > Ah, I see what you're thinking. > > > > > > Treating an EPT #VE as fatal was also considered as an option. IIUC it was > > > thought that finding every nook and cranny that could access a page, without > > > forcing the kernel to pre-accept huge swaths of memory, would be very difficult. > > > It'd be wonderful if that's not the case. > > > > We have to manually set up the page table entries for every physical > > page of memory (except for the hard-coded early stuff below 8MB or > > whatever). We *KNOW*, 100% before physical memory is accessed. > > > > There aren't nooks and crannies where memory is accessed. There are a > > few, very well-defined choke points which must be crossed before memory > > is accessed. Page table creation, bootmem and the core page allocator > > come to mind. > > Heh, for me, that's two places too many beyond my knowledge domain to feel > comfortable putting a stake in the ground saying #VE isn't necessary. > > Joking aside, I agree that treating EPT #VEs as fatal would be ideal, but from a > TDX architecture perspective, when considering all possible kernels, drivers, > configurations, etc..., it's risky to say that there will _never_ be a scenario > that "requires" #VE. > > What about adding a property to the TD, e.g. via a flag set during TD creation, > that controls whether unaccepted accesses cause #VE or are, for all intents and > purposes, fatal? That would allow Linux to pursue treating EPT #VEs for private > GPAs as fatal, but would give us a safety and not prevent others from utilizing > #VEs. That seems reasonable.