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 76426C77B7A for ; Tue, 16 May 2023 20:03:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EC5CA900003; Tue, 16 May 2023 16:03:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E9AFF900002; Tue, 16 May 2023 16:03:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D62F0900003; Tue, 16 May 2023 16:03:56 -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 C7E49900002 for ; Tue, 16 May 2023 16:03:56 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 86E0C1203E8 for ; Tue, 16 May 2023 20:03:56 +0000 (UTC) X-FDA: 80797194072.10.1A901DB Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by imf06.hostedemail.com (Postfix) with ESMTP id 942B1180014 for ; Tue, 16 May 2023 20:03:53 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=F0h7rvHg; spf=pass (imf06.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.31 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684267434; 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=UfjGuD2e0ugGDXfVQ07WdsFxuHKpeo1g2ISot0iJ1pU=; b=R1pEw0uKOkaK/wgSEoQGRRfN6pWDkMabQIGiXqnTKqhXsnEA1gaBgkfiHfyGPV1ZRIRoll 6DV9Swa2Kk4tZiBxUOd7pZS/4HPMk9leG2javAenxUNUXPPddYXmMKPLJeqanpPQB/R+PA 3HzFZUNfP3UQSXH0bZGHwoBh2lZZd7s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684267434; a=rsa-sha256; cv=none; b=iSZ9aiW/U96lwuIDMHkg7IRLUjACbj4BGRETEpk1kalsw0I0edR0FTSe+GXle71o1sy8dU AIZjGFfE/7eigoRFfcT59uOjLBXZEsal5L4gDISeQ9gx+hW5Nn6DoIeYQ0Iw1CM9U8zgpB W6a+SvBNYeacEHCv82Rm9/ur4B1Mpao= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=F0h7rvHg; spf=pass (imf06.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.31 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1684267433; x=1715803433; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=953wYAY7UWvrm1tXjfski6EbreQeUgE/9pY7lM47LiQ=; b=F0h7rvHgnqQIOCYBxk8OsKHhRKKa5ZUBYU3ZHYWJmYfbgL+ao43UuvdK bgLFyBlr38FZDa+9GFR1jIMx2f+ryYlPLTcTfFRGar7ZYBKg9TzArQ/1L B5kz0CiNqkog8M23I9zPy2SdUVOwVCIfYMEskuPfegS3Nph5RumiDMNIw NW7vUigwfJcQh5WJCIEM8wmN+DpTcjzPN9bgVVNe1P3iCvKIVB/lAofIa TfgJU5hEG8nplPildHSlw9SV2qWCJifGNb2i1A5gw77288Z/xmkOukLCe yfoyCU0+F3PgsTGhQj8FsvcgnQUDbFDJeWhKwCGKf2W5tZ+vLq9GMiGXD A==; X-IronPort-AV: E=McAfee;i="6600,9927,10712"; a="414982859" X-IronPort-AV: E=Sophos;i="5.99,278,1677571200"; d="scan'208";a="414982859" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2023 13:03:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10712"; a="875784499" X-IronPort-AV: E=Sophos;i="5.99,278,1677571200"; d="scan'208";a="875784499" Received: from mtpanu-mobl1.amr.corp.intel.com (HELO [10.212.203.6]) ([10.212.203.6]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2023 13:03:32 -0700 Message-ID: Date: Tue, 16 May 2023 13:03:32 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCHv11 6/9] efi/unaccepted: Avoid load_unaligned_zeropad() stepping into unaccepted memory Content-Language: en-US To: Ard Biesheuvel Cc: "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Dario Faggioli , Mike Rapoport , David Hildenbrand , Mel Gorman , marcelo.cerri@canonical.com, tim.gardner@canonical.com, khalid.elmously@canonical.com, philip.cox@canonical.com, aarcange@redhat.com, peterx@redhat.com, x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, Dave Hansen References: <20230513220418.19357-1-kirill.shutemov@linux.intel.com> <20230513220418.19357-7-kirill.shutemov@linux.intel.com> <6fe42f66-819c-f2c8-176b-759c1c5a9cf5@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 942B1180014 X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: uud9xjdj6xwithurfwyhhf7b11b1157u X-HE-Tag: 1684267433-427880 X-HE-Meta: U2FsdGVkX1/q16KdCaXhr/kXAjbLuWF+Jk2rMlRgDz8IZXUCfsRpmMdRgOg3rNBJQo7TTrL7kbDog75AweKm6NwgTe6ujPEHbuhUq6Wj3tavtqedbMRk3pprV0TD5wtikekcyyASewgTOsXtpOJqtcQ/4fabYSTWeX8hCLdDmZdhKIXJlCBwbhLhbTLc7lAJLdWEZ+Hbt+esByE2UEGdyHR943LurwYHjZCb8UOvtkTpUVr1/Vl7VwT2uuH5DzRgmGd6/NYa/Cda3qfAGyJRd8dbg88ZCMJRt6bGca8iKWNqp5IvA86a7AEUXRTcU3B1dhoVx1AwZEUMGjsXvRWSFqkbsj56gqQb8Ea+OYXC8fhGA1nAGICcofJeZYD4QT7gAbuUAO+kFAbMSBcK6oq2V3k7ZnfRVYbzSRmYGo40J8iQzcNP52mkkPx7/fTtkWU4b4gUOTOS1cJelGRlA/d6s90JRvrVLPrYQ1sLtDAKK5cnShH/pHdViJtyfyByin/2qfkXpDVunveG791H3UT5WBtptxmGyOeOtfEuajJ/6eOq2ByfldTs6P8hevdjzCd7YTGlxu9EizZ9QX3GDxiJjJ9TU7patUQwrCWj3b4Q2jCcrk/O2f2L/ErgtTe/fAYc0sI0MQKL0FrnhxFY5hX+21LhBGGvrWiEY2H3eJtp2V8VUNeY5GSUXLsuVpw13BKV9pLG0WAg5PizY75ksSJSFa5sFrHEgrLi2rufaov2p0Wq5H9GfJ3/XV4D/mVDKqry+h6yRwpoYUyO+KryFOq9rZenQ5zNLJB/XcY8OSVh4wAfxKoFLykKyjqsugLrP1l+cLQNFqIhdU2+PtNgj8pEGeG0Y5kauU4XmpiyQ5ofRJLvWmGJ35NAyUv1b2MHFLJW3ZPlTfixJwgp96z8hjENShnY7yv+RXbTYyxqKgrtu077NGXcCMcSJXzBpbQjJCWxbElrI23ljf5tF2SZ3EL RRcu5iIU TKnomE22phCIOU4kWMZR56m+Eah5jcrxysL4S5UvFb6MuJ0ODAhOrXrcVj+wK5d8ljvfLHIHQ3GhzFRlxFXplJ/9HEK0q0Pb9jzZbAkvnR+x9bAhGTgYG6TwHqbGBnj3Iz4eaM11EW4U6vS6CyztCqQkiBCRw8gcBrvuEWMCVb+XXvHve50RHeqVbgqEDiiDVqdOSxuisUa0YQK86/PH5kxMMYQ== 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 5/16/23 11:35, Ard Biesheuvel wrote: >>> Does this mean that the kernel maps memory before accepting it? As >>> otherwise, I would assume that such an access would page fault inside >>> the guest before triggering an exception related to the unaccepted >>> state. >> Yes, the kernel maps memory before accepting it (modulo things like >> DEBUG_PAGEALLOC). >> > OK, and so the architecture stipulates that prefetching or other > speculative accesses must never deliver exceptions to the host > regarding such ranges? I don't know of anywhere that this is explicitly written. It's probably implicit _somewhere_ in the reams of VMX/TDX and base SDM docs, but heck if I know where it is. :) If this is something anyone wants to see added to the SEPT_VE_DISABLE documentation, please speak up. I don't think it would be hard to get it added and provide an explicit guarantee.