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 DBAE0EB64DB for ; Wed, 14 Jun 2023 16:03:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 363EA6B0074; Wed, 14 Jun 2023 12:03:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2EDA58E0002; Wed, 14 Jun 2023 12:03:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 18D308E0001; Wed, 14 Jun 2023 12:03:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 0458F6B0074 for ; Wed, 14 Jun 2023 12:03:33 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BD0341606F7 for ; Wed, 14 Jun 2023 16:03:32 +0000 (UTC) X-FDA: 80901823464.23.638F550 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf06.hostedemail.com (Postfix) with ESMTP id 1D8E71801AB for ; Wed, 14 Jun 2023 16:01:32 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=LkiOItee; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf06.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686758494; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/1VvfLZxSvxSvFMwoRts7DpVDT0t8e+Xidsx71wfGo4=; b=APC8Rm3jX3tunhionq3A/t3yV57YeQlANB4gvXwDbkfHzbKCRSFELiwO4Tuw5RLUq9aU93 rFY8oNFIa6PzJ+ovxBJSqGAiFgihWW8MzJHw05VNLV1WFkbL6aYVZjqCpbtzzfMsxvd+/g VpVtUSpWtUPBQRbF0tJ5bVL/WIQ5L6o= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=LkiOItee; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf06.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686758494; a=rsa-sha256; cv=none; b=46c92z1QljOjjJT4pzk0mEHO2rVj0aomqn1F/MwJNw1qj9uEK75bjjyk4cNfmnKFEuxmlA ucMMiEdKJ+fbzdd3J1F5wRmD0sdOZUlBwCa9gJWx3RroLwi4k4A5BeS2MSugvVNw4Ap+y0 DpmiYIJLlvlGTiNS48UtCav4h2A41d8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1686758493; x=1718294493; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to; bh=2h/idbtEo15I0ifYftHepvrSWhA6QoEfwm35jZ8etOA=; b=LkiOIteerRJRFxIJf308WRYQB62d6xp1ZayIPooyydd520HW3713ydFN j5gYHE3ekC8wV58PBnO5sosFzDZohUVQ7pXWWFzpwRhV91TS8tUbVEbDa b/o3oGlnfeOPY7afNyyGDdvuPlgCPxhD/NY16kzmH2Vou0vGz677ZjiN5 neyY1nol7dbi0U7LY71t1wTJJsMjtFp3wpXI5SDDZzX7YJZvhyWj++yFl tsS5UTRULk+hKFfnA9tPq4lC62wLm5/eg025sNQNOMXRADkQuhlEEWv9S a08tO5oB2qOIdqCoQyllv9qvvVBVQiJR9eqVxcmodgNuMf6CSmVJx3Dq8 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10741"; a="339005668" X-IronPort-AV: E=Sophos;i="6.00,242,1681196400"; d="scan'208";a="339005668" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jun 2023 09:01:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10741"; a="782142034" X-IronPort-AV: E=Sophos;i="6.00,243,1681196400"; d="scan'208";a="782142034" Received: from ngarg3-mobl3.amr.corp.intel.com (HELO [10.212.191.43]) ([10.212.191.43]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jun 2023 09:01:27 -0700 Content-Type: multipart/mixed; boundary="------------IqVKoRf2AFEuZikwKIfxDN60" Message-ID: Date: Wed, 14 Jun 2023 09:01:26 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: x86: pgtable / kaslr initialisation (OOB) help Content-Language: en-US To: Lee Jones Cc: Peter Zijlstra , Dave Hansen , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20230614132339.GS3635807@google.com> <20230614141654.GA1640123@hirez.programming.kicks-ass.net> <20230614143732.GW3635807@google.com> <0cefb67a-6fae-daa2-c871-ae35b96aac08@intel.com> <20230614150615.GX3635807@google.com> <20230614151003.GY3635807@google.com> <20230614152632.GZ3635807@google.com> From: Dave Hansen In-Reply-To: <20230614152632.GZ3635807@google.com> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 1D8E71801AB X-Stat-Signature: 4omtfohe66a84xa7dt7z9bwnywgxszha X-HE-Tag: 1686758492-124083 X-HE-Meta: U2FsdGVkX1/oayXqF31NUQoDnFsJwUH/63ERJCnDuRVbCbnGPKV7r2uJ+HuTRIokIZe8xaom7f8FNuEvW0ikY37SDrv/AxyxTIAKkgZOKPNAt/3LDnGrsFaiOuWeEHn+57x6++xGw91CSNW2r/dA0cDz/m8gbE+igX7lTzWnw1EeyNOM2hIHXwPl/2zAt9JjOKwIipkBbDP+NSIogZUYnCXC9exO+9bspPEB5s9yf6W8ZNhhbker0oUqjhx1aFucaCgRLEewCGVF/UeJHbefIS06WYKvOFVZkOTSFDvAjhLYWlVUphszIoDd7jZHOeNrlZTKdED9+1dsTXsXOQV+6YQQiODL2sE2L7XeXudcMIva6QGRE0YO6tbI6C3NamAZQt4so6mx+k87amjLJZ3jBZ2K1rD6DwBH0OINQdMA93oFHraJWoKAgmhLfphKAXUBzuB+UpZNBeVkH4y5adhT2FOw7otZwL1tMz2J890561scW18WiQRjYIrkB/6ekl/S/2EjCpKGJRYMC1PBXpvu0zucZSCiS4cfq5Mrts16vv8gHlf7TLZzbn8uWq5VqHCu271c6w9h4XGKQ2/uEtSdP8lBVinEtkuXAtxa+MvO0dHGGPh6C1TS8+pio1SeehPyWF8Tyqek+rP9ivvhMW30XKtwMNJ3BY7IQom/FtIuruU/nuyFDk44J1fI2uvxqS59/Ae4aSwb+TP6jA7kGR/aV2iCivrytbKoXguIJyI0pwbgBbuALhlIXAxAiQUZMX/YLEgT+6nlssTm0XR2JhFODAtXqpvu1OejqSIzkNX9cyITmK4OblWp0mtItkOuGW6B7pOJrHQWRb3oWUS8oEMGr+q5D+G0g8pBOn2BsSqFkof3TxCfchleApop7tTkMMC4Gs3V4Tzib6j2Qj41B44p2E5gMWvXtmX/prAIM2uAC4y3FxoKhQ5ViIy6MXu8EpKBd1RyVbvq+sZqKUCd/8A KLBnG+rr nY1oE91PgjiNKVN3htvlnoQI+HiakxROcrNERc4I+7z3QC5c/vwfoK/AMGLxfH1lQvf5haH/ybvI+PWXdXXiVCzFjk4PLzW4ZRBRJlyp9lupUJ21+gDmOF997MTItFAxGJ97moh/4zWoLaMDZZd2U97UR3Ja96ajC4AINuuIWiulUv8KRamA3452wgju4V9Q8ViFmz75s+pRE8NHCVrHYDC1Hc7uGF4Rn96aHPZQv+npoadzoyZ0QSG4kSvtbBZB7QHPG4BHlbL3pAjFp+HdYRreaFL4vtYSFQjHCUGRRWpuONIMqZyBIx4v80fBMfaDNCvj6+Ki8N+rk2/djsU41S4xDJeYDaUXQLfznBhwsLcZ0EhZNKJa4szgC9uyDJA0krRM6 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: This is a multi-part message in MIME format. --------------IqVKoRf2AFEuZikwKIfxDN60 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 6/14/23 08:26, Lee Jones wrote: > On Wed, 14 Jun 2023, Lee Jones wrote: > >> On Wed, 14 Jun 2023, Lee Jones wrote: >> >>> Thanks for chiming in Dave. I hoped you would. >>> >>> On Wed, 14 Jun 2023, Dave Hansen wrote: >>> >>>> On 6/14/23 07:37, Lee Jones wrote: >>>>> Still unsure how we (the kernel) can/should write to an area of memory >>>>> that does not belong to it. Should we allocate enough memory >>>>> (2*PAGE_SIZE? rather than 8-Bytes) for trampoline_pgd_entry to consume >>>>> in a more sane way? >>>> >>>> No. >>>> >>>> I think this: >>>> >>>> set_pgd(&trampoline_pgd_entry, >>>> __pgd(_KERNPG_TABLE | __pa(p4d_page_tramp))); >>>> >>>> is bogus-ish. set_pgd() wants to operate on a pgd_t inside a pgd >>>> *PAGE*. But it's just being pointed at a single _entry_. The address >>>> of 'trampoline_pgd_entry' in your case also just (unfortunately) >>>> happens to pass the: >>>> >>>> __pti_set_user_pgtbl -> pgdp_maps_userspace() >>>> >>>> test. I _think_ we want these to just be something like: >>>> >>>> trampoline_pgd_entry = __pgd(_KERNPG_TABLE | >>>> __pa(p4d_page_tramp); >>>> >>>> That'll keep us away from all of the set_pgd()-induced nastiness. >>> >>> Okay. Is this what you're suggesting? >>> >>> diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c v >>> index d336bb0cb38b..803595c7dcc8 100644 >>> --- a/arch/x86/mm/kaslr.c >>> +++ b/arch/x86/mm/kaslr.c >>> @@ -176,7 +176,7 @@ void __meminit init_trampoline_kaslr(void) >>> set_pgd(&trampoline_pgd_entry, >>> __pgd(_KERNPG_TABLE | __pa(p4d_page_tramp))); >>> } else { >>> - set_pgd(&trampoline_pgd_entry, >>> - __pgd(_KERNPG_TABLE | __pa(pud_page_tramp))); >>> + trampoline_pgd_entry = >>> + __pgd(_KERNPG_TABLE | __pa(p4d_page_tramp); >> >> Note the change of *.page_tramp here. >> >> s/pud/p4d/ >> >> I'm assuming that too was intentional? > > Never mind. I can see that p4d_page_tramp is local to the if() segment. > > While we're at it, does the if() segment look correct to you: > > if (pgtable_l5_enabled()) { > p4d_page_tramp = alloc_low_page(); > > p4d_tramp = p4d_page_tramp + p4d_index(paddr); > > set_p4d(p4d_tramp, > __p4d(_KERNPG_TABLE | __pa(pud_page_tramp))); > > set_pgd(&trampoline_pgd_entry, > __pgd(_KERNPG_TABLE | __pa(p4d_page_tramp))); > } else { > trampoline_pgd_entry = > __pgd(_KERNPG_TABLE | __pa(pud_page_tramp)); > } > > - pud_page_tramp is being passed to set_p4d() > - p4d_page_tramp is being passed to set_pgd() > > Should those be the other way around, or am I missing the point? You're missing the point. :) PGDs are always set up to point to the physical address of the thing at one lower level than them. A page is allocated for that level when 5-level paging is in play. No page is needed when it is not in play. The pattern is _almost_ always pgd = ... __pa(p4d); In other words, point the PGD at the physical address of a p4d. But things get funky on systems without p4ds, thus the special casing here. Does the (completely untested) attached patch fix your problem? --------------IqVKoRf2AFEuZikwKIfxDN60 Content-Type: text/x-patch; charset=UTF-8; name="trampoline_pgd_entry.patch" Content-Disposition: attachment; filename="trampoline_pgd_entry.patch" Content-Transfer-Encoding: base64 CgotLS0KCiBiL2FyY2gveDg2L21tL2thc2xyLmMgfCAgICA4ICsrKystLS0tCiAxIGZpbGUg Y2hhbmdlZCwgNCBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9ucygtKQoKZGlmZiAtcHVOIGFy Y2gveDg2L21tL2thc2xyLmN+dHJhbXBvbGluZV9wZ2RfZW50cnkgYXJjaC94ODYvbW0va2Fz bHIuYwotLS0gYS9hcmNoL3g4Ni9tbS9rYXNsci5jfnRyYW1wb2xpbmVfcGdkX2VudHJ5CTIw MjMtMDYtMTQgMDg6NTQ6MDguNjg1NTU0MDk0IC0wNzAwCisrKyBiL2FyY2gveDg2L21tL2th c2xyLmMJMjAyMy0wNi0xNCAwODo1NTozNi4wNzcwODk3OTMgLTA3MDAKQEAgLTE3MiwxMCAr MTcyLDEwIEBAIHZvaWQgX19tZW1pbml0IGluaXRfdHJhbXBvbGluZV9rYXNscih2b2kKIAkJ c2V0X3A0ZChwNGRfdHJhbXAsCiAJCQlfX3A0ZChfS0VSTlBHX1RBQkxFIHwgX19wYShwdWRf cGFnZV90cmFtcCkpKTsKIAotCQlzZXRfcGdkKCZ0cmFtcG9saW5lX3BnZF9lbnRyeSwKLQkJ CV9fcGdkKF9LRVJOUEdfVEFCTEUgfCBfX3BhKHA0ZF9wYWdlX3RyYW1wKSkpOworCQl0cmFt cG9saW5lX3BnZF9lbnRyeSA9CisJCQlfX3BnZChfS0VSTlBHX1RBQkxFIHwgX19wYShwNGRf cGFnZV90cmFtcCkpOwogCX0gZWxzZSB7Ci0JCXNldF9wZ2QoJnRyYW1wb2xpbmVfcGdkX2Vu dHJ5LAotCQkJX19wZ2QoX0tFUk5QR19UQUJMRSB8IF9fcGEocHVkX3BhZ2VfdHJhbXApKSk7 CisJCXRyYW1wb2xpbmVfcGdkX2VudHJ5ID0KKwkJICAgICAgIAlfX3BnZChfS0VSTlBHX1RB QkxFIHwgX19wYShwdWRfcGFnZV90cmFtcCkpOwogCX0KIH0KXwo= --------------IqVKoRf2AFEuZikwKIfxDN60--