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 5F753C77B7F for ; Tue, 16 May 2023 22:00:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DAE2C900004; Tue, 16 May 2023 18:00:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D5D84900002; Tue, 16 May 2023 18:00:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C2641900004; Tue, 16 May 2023 18:00:13 -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 B48D6900002 for ; Tue, 16 May 2023 18:00:13 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 84BF8120430 for ; Tue, 16 May 2023 22:00:13 +0000 (UTC) X-FDA: 80797487106.27.48DA2A7 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf07.hostedemail.com (Postfix) with ESMTP id 3D1144000E for ; Tue, 16 May 2023 22:00:09 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=HWLYvNWJ; spf=pass (imf07.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.20 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=1684274411; 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=s4NMYlbcbAELmud9duZpKgCq1uqCZlFQAmRIaN7vKFY=; b=qNo/LgjfholTnGTcClFuiULKi9xq5inEf6E/CUmjfuU4K9iVBBWmChnDhuApOJnToTkl7F krXcVC/0RJ/I9ElLhanwkjT1NomdQtEDZranAVNXTAAjVy/EziXfzhCM3RPxvL6P263rvv +D2OO22ELaW4gGjipEg0zwZchOskezU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684274411; a=rsa-sha256; cv=none; b=Ek74CoyvBGQ2Pww4HjSAdYgv1rjK3ZD9BzNmt3z9/b6h0xUf09dPoqvN/D41QFGdeGroBf HT8UuRo4TnLSSxLKq1SCTtguOkE5up5ebE/+YxPwFr49m4vfN72Auw5GAJRoBZAPKBuiwX sZsdeCA6pMqObupQqzDMSOaSjrIt6Gg= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=HWLYvNWJ; spf=pass (imf07.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.20 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=1684274410; x=1715810410; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=/gElHzywUsJHlUOft8PJljOmt4C9JPUiaPG7wwx26iQ=; b=HWLYvNWJi9xAAACFV8LaEcHW6aZ79CU8WNkLstjzVBdm/VVYEwXSNPZP X7Q45QoK/+JEXSdJs4ZbBIeAm8gTdujGTwlvTWjCStD9q/GHIIthdfEF4 Yza2PmfC1HENRES76Sc5cU0S6nJ/0pqbBhveb8yL8YSyv5nxqT3Ymibm9 Zmu6mt8/c1+g+PHOO9NnKOkq+dwtRD0lJtPrLgWqHpDTPTv7HMAjZnHW7 tSOjLWJ6zCKYKWzb+xsXui/FC2uAqZocDERuWmjttmDb/MWZxcQKdhAJV cD113HHS+FMktLIHJOv3hKU2WW7BDBHCxyhEGzPSRYGc8g3TnOwt+YvMU A==; X-IronPort-AV: E=McAfee;i="6600,9927,10712"; a="340980076" X-IronPort-AV: E=Sophos;i="5.99,280,1677571200"; d="scan'208";a="340980076" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2023 15:00:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10712"; a="813612412" X-IronPort-AV: E=Sophos;i="5.99,280,1677571200"; d="scan'208";a="813612412" Received: from mtpanu-mobl1.amr.corp.intel.com (HELO [10.212.203.6]) ([10.212.203.6]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2023 14:59:56 -0700 Message-ID: Date: Tue, 16 May 2023 14:59:56 -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: "Kirill A. Shutemov" Cc: Ard Biesheuvel , "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> <20230516215210.pviqojbr5o4hd6bb@box.shutemov.name> From: Dave Hansen In-Reply-To: <20230516215210.pviqojbr5o4hd6bb@box.shutemov.name> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Stat-Signature: pzbbw4et1jqugm9y834s68dngrpmzr59 X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 3D1144000E X-HE-Tag: 1684274409-578607 X-HE-Meta: U2FsdGVkX1/c87mb+/uN+s6Fn/DsJUczS4GmW0vKQBiQfDoUNOc5/GeJH8slCthbeewoS5y7VbE6UMe7IXJ0PM+cvNPZzsrQF84DqOi5DyyCeDhZCPpAbGwOSiY7AQNO0W7ZSpQ4XHRZT8nOHV7241lWCovofhEa6ZT7ZHPGg/M6JSiKuc5Zbo77OEw/U3sRGJrgNZftIudD627Yis446RZ3VF4eHS09Ed8fQfM4BM5q7EcBxE5DS20CVhAcLVIjE2IJ0mc2/amaeF3/6TdBbuFAm4JetNBIoJgfn4jVeom5Yas9rVBfa5YuWxqv28gf89IFyKvwbN3WQhf2PQCtHun5+vPVtf1I6mc4ClW1I9lgMCXjMaAKocKl90RFTNLZjHn79Opki6SbEkLvGifQn4nGeG71N4Gwoue4gc5x6gZznvqpGWxYH2qWmOkxUG+DCrwxPQ+hLA4LYNdnzZdt3S9/TjPE4pC66/TzyG0p95O8oPyxUIKe2JPSCoFvGb6hwBAAEYSOaF62vtwUK/+ktif4RaxGy6gRICrVDeZkZin/bryF0eD1IsVckXedVk8oE4zOvIUwwT4vpfJchWKCdOJfz/PLIdkualGFuM2+xhRj8ItHf3JiK1Lb9Ehx/CsA61Zr36oizQKEmlV3yABRCUMs0Q+JIJTCOhTgEum1rJi6NMh7SqHltwIiZWsLX+FywqaaQCWiC4vf9dnPPv8FtWk3NUH5z1VQH11L6gSA75J/5WXEdy8m8GGYgdZe4DuGxhyFg5MKMrzD9zNoqO2fPoPTqn1dL5UqXSPCbV5qz7i2FOP4VpDuxiJPUUZGG3AZrpPeodMVuhd/yT4LUwKoFo0sBW6NZu5gtXLZ/+ZPVJlL+y2LxZZg58H8PI6jfoOrsVpoeRkgTJCkbjhSewdF2Uyh9xSSOsZzk9XcJRXhhIlrJ63OdYbjRYW4ASw+ROj3bE/Ms1gPoPhBVFUrai1 UghR8eiX e91zCQ0nrOk7Kc1rqvBl+9+klqyf881W4mAPKZPXhf/r/ZIJCTeIkv8VkgLV4wo8BVJHP0Yjk/ApfNsUd6DF1iz42hmXkh7hITpJX+jggZ/4f3NfrrU3toMz9grEOWsUQRW/sTYyh6SHkBEJgYirnLeRehNAZIyBqh1N4l0sR4Z+hFVQzVEEVxUmcwUmvwDw/7L62 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 14:52, Kirill A. Shutemov wrote: > On Tue, May 16, 2023 at 01:03:32PM -0700, Dave Hansen wrote: >> 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. 😄 > It is not specific to TDX: on x86 (and all architectures with precise > exceptions) exception handling is delayed until instruction retirement and > will not happen if speculation turned out to be wrong. And prefetching > never generates exceptions. Not to be Debbie Downer too much here, but it's *totally* possible for speculative execution to go read memory that causes you to machine check. We've had such bugs in Linux. We just happen to be lucky in this case that the unaccepted memory exceptions don't generate machine checks *AND* TDX hardware does not machine check on speculative accesses that would _just_ violate TDX security properties. You're right for normal, sane exceptions, though.