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 A8C6EC19F2D for ; Tue, 9 Aug 2022 11:35:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DDBC88E0001; Tue, 9 Aug 2022 07:35:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D891B6B0072; Tue, 9 Aug 2022 07:35:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C51428E0001; Tue, 9 Aug 2022 07:35:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id B2F3B6B0071 for ; Tue, 9 Aug 2022 07:35:38 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 6485E1C6149 for ; Tue, 9 Aug 2022 11:35:38 +0000 (UTC) X-FDA: 79779849156.12.9E3AF3C Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf03.hostedemail.com (Postfix) with ESMTP id 22F6620167 for ; Tue, 9 Aug 2022 11:35:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1660044936; x=1691580936; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=ckfaBQEm61O3oz3fOP7g8FRe9wCmN4sKBCyP+R9DJ+E=; b=hwanY34w6abMtIlH3TCKHGG7T0lu0iY/RCUNMPw9+LTZI3t9ix4opBSw ZRlpw+Cr3sAIgITlh1wgPKq5iy6xCbE/bX4YfwDda9JrsXdeo9mlNAjrl KTo+3XMxQuTMHJIrJWsPtMx7TgQYbZuwG3Ivgn6gEZ2ljntYRSbMLuAGS qo+kQ+fJ3TP6Wjl2o2MlpZR1RZv0mzsMgBz7dGxDRyv9iLF1/dd31mzIG ZF9mRfQIX3RFQ8x3b9jdtKV63p4jPEoPdYO7MIlBoSk7VnU+Arsi8uTEc w0mlrN0qu4NVnykHYrR7vXpgiBHli3HFZx9/esrig6sLaUwDbZ4sEDMSu g==; X-IronPort-AV: E=McAfee;i="6400,9594,10433"; a="288377729" X-IronPort-AV: E=Sophos;i="5.93,224,1654585200"; d="scan'208";a="288377729" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2022 04:35:34 -0700 X-IronPort-AV: E=Sophos;i="5.93,224,1654585200"; d="scan'208";a="747008116" Received: from labukara-mobl.ger.corp.intel.com (HELO box.shutemov.name) ([10.251.214.212]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2022 04:35:28 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 86500103886; Tue, 9 Aug 2022 14:38:27 +0300 (+03) Date: Tue, 9 Aug 2022 14:38:27 +0300 From: "Kirill A. Shutemov" To: Andy Lutomirski Cc: 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: <20220809113827.fchtnyzy44z5fuis@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7cec93c5-3db4-409b-8c1e-bc1f10dd68fc@www.fastmail.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660044937; a=rsa-sha256; cv=none; b=kjWLI8IjaAdzqDGDvubqOkiZYSC6UctrMHFbinevLKzeKMn/4v+UUGrP7SUF/JQe4U1G+G sBYt3qq8Lfk331/0QVnow6jHhDXNTnaEwGJEqqeqnqKinmuB6KIh0iiXvnrkoUHJTaLDqM BxEWrwOIpls/5B6IDZsjoU//vuCZDJ8= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=hwanY34w; spf=none (imf03.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660044936; 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=p4TfHKkg9iKTjELha9o3Z2Y0yX/0d6gSsULjo+6R2eU=; b=gaZqi4OABOyCTlTXookp0oweBgqB6UgzgkLhrGvDAeTnjvsXDpZ3CM9lQE8qKy0JCI4ye0 YMMrq6DBagcgTfgiLD8ksKYgwHTIhafC1xWe2UnnL2Rgth2v0/e/6OMIlZ24oHQrwCPAjA 6Xh57z3mSnwb9anjwASiYPmk6oero1g= X-Rspamd-Server: rspam06 X-Rspam-User: X-Stat-Signature: k1tqbcsbkjionnb54od6c4nxwujbazd3 X-Rspamd-Queue-Id: 22F6620167 Authentication-Results: imf03.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=hwanY34w; spf=none (imf03.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-HE-Tag: 1660044935-804525 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 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. > (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"). -- Kiryl Shutsemau / Kirill A. Shutemov