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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B034BC19F2D for ; Sat, 13 Aug 2022 16:05:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 39A378E0003; Sat, 13 Aug 2022 12:05:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 348F68E0002; Sat, 13 Aug 2022 12:05:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E9808E0003; Sat, 13 Aug 2022 12:05:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 109B78E0002 for ; Sat, 13 Aug 2022 12:05:27 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id DAD2FAB3D7 for ; Sat, 13 Aug 2022 16:05:26 +0000 (UTC) X-FDA: 79795044252.30.0C8C4D5 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf13.hostedemail.com (Postfix) with ESMTP id 5991420080 for ; Sat, 13 Aug 2022 16:05:25 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 30A69B80688; Sat, 13 Aug 2022 16:05:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF93BC433D6; Sat, 13 Aug 2022 16:05:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1660406723; bh=3g9RQwus4TjJnSLEmDO7GO8w4lhwGY5MWBNfeGUrI14=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=bR3utfteio3+HXiiA5b9ZVNOesXk99inIzLdtSS3Fbr4O2vhnqjAKFXnIUNKErZU1 AXlqTpnV+qv86BuGxlLt8Uswr1e9UsMcDl/tWW7lYBmIEThfMUqBYA/vB9H0GEoZlF /gKQdhBaqegWs78Sn/gdnhx1jwE+1BhLHOQhhRpfpE3L52xy6RRYPfC2Cv8tp7XBo0 e+5Eugq7TqDz4Z68+k6mXXnc8WDhTS7WOAWrP2Rm43CtwGTrNLZPQEwR1DcChwNm65 JXptI7Xq2yutap0/sMdFhWOD4woGK/ikcOLQmk3yZi2hqSFKwUGc8ZSJWj3Lv/zBTu PdllclRHsw4nQ== Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id CB83A27C005A; Sat, 13 Aug 2022 12:05:20 -0400 (EDT) Received: from imap48 ([10.202.2.98]) by compute2.internal (MEProxy); Sat, 13 Aug 2022 12:05:20 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdegkedgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtgfesthhqredtreerjeenucfhrhhomhepfdet nhguhicunfhuthhomhhirhhskhhifdcuoehluhhtoheskhgvrhhnvghlrdhorhhgqeenuc ggtffrrghtthgvrhhnpeduveffvdegvdefhfegjeejlefgtdffueekudfgkeduvdetvddu ieeluefgjeeggfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpegrnhguhidomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudduiedu keehieefvddqvdeifeduieeitdekqdhluhhtoheppehkvghrnhgvlhdrohhrgheslhhinh hugidrlhhuthhordhush X-ME-Proxy: Feedback-ID: ieff94742:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1B36831A0063; Sat, 13 Aug 2022 12:05:20 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-841-g7899e99a45-fm-20220811.002-g7899e99a Mime-Version: 1.0 Message-Id: In-Reply-To: <073c5a97-272c-c5a0-19f2-c3f14f916c72@intel.com> References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <20220614120231.48165-11-kirill.shutemov@linux.intel.com> <80cc204b-a24f-684f-ec66-1361b69cae39@intel.com> <073c5a97-272c-c5a0-19f2-c3f14f916c72@intel.com> Date: Sat, 13 Aug 2022 09:04:58 -0700 From: "Andy Lutomirski" To: "Dave Hansen" , "Borislav Petkov" , "Kirill A. Shutemov" Cc: "Sean Christopherson" , "Andrew Morton" , "Joerg Roedel" , "Ard Biesheuvel" , "Andi Kleen" , "Sathyanarayanan Kuppuswamy" , "David Rientjes" , "Vlastimil Babka" , "Tom Lendacky" , "Thomas Gleixner" , "Peter Zijlstra (Intel)" , "Paolo Bonzini" , "Ingo Molnar" , "Varad Gautam" , "Dario Faggioli" , "Mike Rapoport" , "David Hildenbrand" , "Marcelo Henrique Cerri" , tim.gardner@canonical.com, khalid.elmously@canonical.com, philip.cox@canonical.com, "the arch/x86 maintainers" , linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, "Linux Kernel Mailing List" Subject: Re: [PATCHv7 10/14] x86/mm: Avoid load_unaligned_zeropad() stepping into unaccepted memory Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660406725; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=BBGqWRsgfGwmmvoCG1QPIjuzB4DU/hpnHUCHZCh/SzM=; b=jHhSoU+Ynk0KAWHBqLOJT2xNUS+tSr/fvg2JiY3iGwn2NMRbil9HnalVQv4vS6gcbmgVmp QDicLuEHcTzDLH4qoC/5LKqP6+zVhy0YFUwxJwqcTBIAPqff1dS+n9ClEhf8N0oCTcZ8ZX Dy17YdfhdwuMFpCqQo0RVIhwal5Ler8= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bR3utfte; spf=pass (imf13.hostedemail.com: domain of luto@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660406725; a=rsa-sha256; cv=none; b=llgQlh046BydVCt1/lzA8qrvrvQEWGCJRHsZoHppjLP4S3/NIVcMS1cLTo7AmFm8N2tIR8 0Pa5Gi3hhABe3aLUwZsv1k94ILQMu3KzGeAYkeUP55y4MwEYRUP4rtN1g5Kvs2Sx2VYJVV +J1LxoFvIq3cbXX4xTsPtdfZV+G5r6w= X-Stat-Signature: ek6mdc67mumrekjoe76tpjthcgexsesa X-Rspamd-Queue-Id: 5991420080 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bR3utfte; spf=pass (imf13.hostedemail.com: domain of luto@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1660406725-22345 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 Wed, Aug 3, 2022, at 7:02 AM, Dave Hansen wrote: > On 8/2/22 16:46, Dave Hansen wrote: >> To sum it all up, I'm not happy with the complexity of the page >> acceptance code either but I'm not sure that it's bad tradeoff compar= ed >> to greater #VE complexity or fragility. >>=20 >> Does anyone think we should go back and really reconsider this? > > One other thing I remembered as I re-read my write up on this. > > In the "new" mode, guests never get #VE's for unaccepted memory. They > just exit to the host and can never be reentered. They must be killed. > > In the "old" mode, I _believe_ that the guest always gets a #VE for > non-EPT-present memory. The #VE is basically the same no matter if the > page is unaccepted or if the host goes out and makes a > previously-accepted page non-present. > > One really nasty implication of this "old" mode is that the host can > remove *accepted* pages that are used in the syscall gap. That means > that the #VE handler would need to be of the paranoid variety which > opens up all kinds of other fun. > > * "Old" - #VE's can happen in the syscall gap > * "New" - #VE's happen at better-defined times. Unexpected ones are > fatal. > > There's a third option which I proposed but doesn't yet exist. The TDX > module _could_ separate the behavior of unaccepted memory #VE's and > host-induced #VEs. This way, we could use load_unaligned_zeropad() wi= th > impunity and handle it in the #VE handler. At the same time, the host > would not be allowed to remove accepted memory and cause problems in t= he > syscall gap. Kinda the best of both worlds. > > But, I'm not sure how valuable that would be now that we have the > (admittedly squirrelly) code to avoid load_unaligned_zeropad() #VE's. How would that be implemented? It would need to track which GPAs *were*= accepted across a host-induced unmap/remap cycle. This would involve pr= eventing the host from ever completely removing a secure EPT table witho= ut the guest=E2=80=99s help, right? Admittedly this would IMO be better behavior. Is it practical to impleme= nt?