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 0CEE5C19F2D for ; Sat, 13 Aug 2022 20:59:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 590038E0001; Sat, 13 Aug 2022 16:59:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 53E116B0074; Sat, 13 Aug 2022 16:59:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DE288E0001; Sat, 13 Aug 2022 16:59:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3084E6B0073 for ; Sat, 13 Aug 2022 16:59:14 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 04B69160142 for ; Sat, 13 Aug 2022 20:59:13 +0000 (UTC) X-FDA: 79795784628.17.ED2D8BE Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by imf30.hostedemail.com (Postfix) with ESMTP id 9831E8019B for ; Sat, 13 Aug 2022 20:59:13 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2B8695C0107; Sat, 13 Aug 2022 16:59:13 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sat, 13 Aug 2022 16:59:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov.name; h=cc:cc:content-transfer-encoding:content-type:date:date:from :from:in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1660424353; x= 1660510753; bh=8ehvrQN0pYNFeadixhtX5cZ4eBy7Bgjn0JWqP+l7wXQ=; b=g FDwk5/6lXnt8IgUJBQ5h3ul+WnJaUqC6rkxWEvv2tFpia49i71CkydK1KyQRQDD7 tFdrCBX0nFbwO2ac4cjfh58oN2SyUIGUMGewk4oGA6t/spNXjma8R8AeTilZ/FHM fIgHoqm4Gt4ACoZNrK99W/TOU2JbDMMyEABj3iMQpk7j3PqAWbzpv0eMpauS9Wyq GCMy+rz4NDG4A/Oc+xvm16J1c/v1AfGcc072nSHEtXA3byTtikqFjdymuQ2hsbQ5 jqtzU0gweDS4Qtxkm0L//zUvrve55VVROdC/j1E4W68G30B8k3OXFu5+Pt+qEdsZ Q3z7tOhGVFvkcIbpcR93A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1660424353; x= 1660510753; bh=8ehvrQN0pYNFeadixhtX5cZ4eBy7Bgjn0JWqP+l7wXQ=; b=k /y/rtfU1c0w9XkXRQQ2h9nUAvJe3+XoGwPui0wznHuh3MWeSsxNaVmbxLt2g0gxV qn3QGn7HklA3lTPFu8x3xaYDrikQa0uRzhUeLf7s5hIQzoIIz1vGgDEImDzla7mY 6atxbGqUfzrAygK5+7BV3wRE3WAYToZQOKhu/ELdLOImaD7n+8ENYA+jAJhH93RI S5p6R5s6r2281WnD4UBdQifTLvMWmZ/foovmWYg2ozAljvmjCPtaKlmObWsbINsK v2jq9v6zXlOA7ScMETizfN/1Pa932O56p+yYYZFLFXIOnRzxz8RSh/bzRKgEA0cR Hx0SAxmFUKXMUK+swjv2g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdegkedgudehkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtugfgjgesthektddttddtjeenucfhrhhomhepfdfm ihhrihhllhcutedrucfuhhhuthgvmhhovhdfuceokhhirhhilhhlsehshhhuthgvmhhovh drnhgrmhgvqeenucggtffrrghtthgvrhhnpefgjeeikefffeefvedugfdtkedvhfdttdei feevtdehgefgjeffleelgffggfdvkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehkihhrihhllhesshhhuhhtvghmohhvrdhnrghmvg X-ME-Proxy: Feedback-ID: ie3994620:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 13 Aug 2022 16:59:12 -0400 (EDT) Received: by box.shutemov.name (Postfix, from userid 1000) id 57259104A08; Sun, 14 Aug 2022 00:02:15 +0300 (+03) Date: Sun, 14 Aug 2022 00:02:15 +0300 From: "Kirill A. Shutemov" To: Andy Lutomirski Cc: "Kirill A. Shutemov" , Borislav Petkov , 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 , Dave Hansen , 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 Message-ID: <20220813210215.ti7f2vqdg6olthjv@box.shutemov.name> References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <20220614120231.48165-11-kirill.shutemov@linux.intel.com> <7cec93c5-3db4-409b-8c1e-bc1f10dd68fc@www.fastmail.com> <20220809113827.fchtnyzy44z5fuis@box.shutemov.name> <453fb432-ac13-4819-8395-95561bca948b@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <453fb432-ac13-4819-8395-95561bca948b@www.fastmail.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660424353; 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=8ehvrQN0pYNFeadixhtX5cZ4eBy7Bgjn0JWqP+l7wXQ=; b=uNfydAO6EnK3d0NJk7El2TkWpudHKVsstE//MMGNMzE3Riy95HWiea3mmHVsk2AwssfnqV b42kd6OG+t32tcba9HVRvMzOdwZ7x6xH5VV89TSdl5MkZgNXUb/dXXI/8OucO1g2k8glT4 bHSEv4cHM2wOll/0BxOmYC8lIYMAmZQ= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=shutemov.name header.s=fm2 header.b="g FDwk5/"; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="k /y/rtf"; spf=pass (imf30.hostedemail.com: domain of kirill@shutemov.name designates 66.111.4.27 as permitted sender) smtp.mailfrom=kirill@shutemov.name; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660424353; a=rsa-sha256; cv=none; b=Yj7MLLEDwcvXPJkt0XdpKqAM4PB0JOX2aU4wtEH103RnVc6TgRSuZC1cvw0v4Wpl77+Fz3 42bWuxT4WFsCq08oTADJthyl0jgMnZz6CjD1r9UjLXkaYJ52hRf2Fo7SDjO1tFTfr8xxvk d2+tixlGvcOd7eKphNpzntnZ+wdrT8E= X-Stat-Signature: ea4iqz88rqtgub3o91fkxtsmcgpyamzj X-Rspamd-Queue-Id: 9831E8019B Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=shutemov.name header.s=fm2 header.b="g FDwk5/"; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="k /y/rtf"; spf=pass (imf30.hostedemail.com: domain of kirill@shutemov.name designates 66.111.4.27 as permitted sender) smtp.mailfrom=kirill@shutemov.name; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1660424353-902009 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 Sat, Aug 13, 2022 at 09:03:13AM -0700, Andy Lutomirski wrote: > > > On Tue, Aug 9, 2022, at 4:38 AM, Kirill A. Shutemov wrote: > > On Tue, Jul 26, 2022 at 01:17:13PM -0700, Andy Lutomirski wrote: > >> > >> > >> On Tue, Jun 14, 2022, at 5:02 AM, Kirill A. Shutemov wrote: > >> > load_unaligned_zeropad() can lead to unwanted loads across page boundaries. > >> > The unwanted loads are typically harmless. But, they might be made to > >> > totally unrelated or even unmapped memory. load_unaligned_zeropad() > >> > relies on exception fixup (#PF, #GP and now #VE) to recover from these > >> > unwanted loads. > >> > > >> > But, this approach does not work for unaccepted memory. For TDX, a load > >> > from unaccepted memory will not lead to a recoverable exception within > >> > the guest. The guest will exit to the VMM where the only recourse is to > >> > terminate the guest. > >> > >> Why is unaccepted memory marked present in the direct map in the first place? > >> > >> Having kernel code assume that every valid address is followed by > >> several bytes of memory that may be read without side effects other than > >> #PF also seems like a mistake, but I probably won’t win that fight. But > >> sticking guard pages in front of definitely-not-logically present pages > >> seems silly to me. Let’s just not map it. > > > > It would mean no 1G pages in direct mapping for TDX as we accept 2M a > > time. As of now, we don't have a way to recover direct mapping from fragmentation. So once we split 1G to 2M it stays this way. > >> (What if MMIO memory is mapped next to regular memory? Doing random > >> unaligned reads that cross into MMIO seems unwise.) > > > > MMIO is shared, not unaccpted private. We already handle the situation. > > See 1e7769653b06 ("x86/tdx: Handle load_unaligned_zeropad() page-cross to > > a shared page"). > > > > I don’t mean in a confidential guest — I mean generally. This whole > model of “overrun the buffer — no big deal” is just fragile. If you want to remove load_unaligned_zeropad(), I would not object. It can make life easier. I presumed that optimization it brings has measuarable benefit (otherwise, why bother). -- Kiryl Shutsemau / Kirill A. Shutemov