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 F2046EB64D8 for ; Wed, 14 Jun 2023 15:26:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A8A46B0078; Wed, 14 Jun 2023 11:26:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 655D56B007B; Wed, 14 Jun 2023 11:26:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 51DC88E0001; Wed, 14 Jun 2023 11:26:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3E02E6B0078 for ; Wed, 14 Jun 2023 11:26:42 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 06AC6160213 for ; Wed, 14 Jun 2023 15:26:42 +0000 (UTC) X-FDA: 80901730644.15.CC6BE4C Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf19.hostedemail.com (Postfix) with ESMTP id 2E93E1A0009 for ; Wed, 14 Jun 2023 15:26:39 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Spmc2zDp; spf=pass (imf19.hostedemail.com: domain of lee@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=lee@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686756400; 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=3W0XZm3EXUvrfXmHM2KdQ76n2GA+FV7rCDLiwWDmFRE=; b=LEfoculAvlBwvffNDd72MtEIFdgb91L/0syoaAhWOfEirYe1W6Kqa+5+WUp6YbVLTf96kz Y7PshxDmAaJkGH4z0Bb+48MWcK5AY88pl/h4VX0/o/iSPvqpaDAyaLTDWVpKfqska9Ol92 kbeIQbcuTB5XB6byT0To5T+PUcHSq3s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686756400; a=rsa-sha256; cv=none; b=5wOU7XZObAF16/ax2bLBP//N4B53OG/y6+/+IaPL6QY/0S/4yWIfjI+3/BNbB6xoECk46Z +ydham2fLF2kGBRJzRUoq/MHa7X917a/+GosN7jtIqmQy78y7Y3SbBMKpzLVWoa2zAiIc8 EVSKK2hfThpeQP28c70Sg8iHCCnngfs= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Spmc2zDp; spf=pass (imf19.hostedemail.com: domain of lee@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=lee@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 280A163FB4; Wed, 14 Jun 2023 15:26:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E991AC433C0; Wed, 14 Jun 2023 15:26:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686756398; bh=1FUrBPPtTuYhiCmgJTnF19xPmAmzMqjMGMN08AUS778=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Spmc2zDprQXdxWiUIGY8bhorL/WQL2Zx6swDV1mnoYUkk8wT0OoDVnACS9v3qsSff 9ZChIce1SHG4Ejj7Hz7qzzxrRGSuW4+HyT4HgJpjx5nNfb32rx52SWamd0eVazUBRU CeBGw0/zrj7gNtq75bYYK14puAWnZvifpaLu1VdxTtmk+/zzZSXUIpeeV+9HObYkbx 4MZaDtZEXhWYmudhpjutQXOwWw9//bc9JYEcPF/MDtJaUh6HEtQ5r+uKwqmj4/trRe /jPSXIOxxVkqkxqG+s42kiLbyhbp1S5S1cj2sAviuaLMRRfMTiOAyykGPPuLyNg6RF 87J4Cgt8Hak0g== Date: Wed, 14 Jun 2023 16:26:32 +0100 From: Lee Jones To: Dave Hansen 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 Subject: Re: x86: pgtable / kaslr initialisation (OOB) help Message-ID: <20230614152632.GZ3635807@google.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230614151003.GY3635807@google.com> X-Rspamd-Queue-Id: 2E93E1A0009 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: xrebqkruc7hpqrteaq1m8pezpfkhpcww X-HE-Tag: 1686756399-587270 X-HE-Meta: U2FsdGVkX19KaRfI5MgsiieWa0F6hkzOUKXTIVmKdFnuTHXWl2EqsNrvekVBI4sslv15w5njpGBZVsmMLMWBuuqeVUqbF3guYmoSH2/o9gVeSaFonsUCsHkcqzyThThWrNzhqLFL/HWObzQYRlYk67iAdqqLhSB/MiPQVpXx9cNbNpean5tYcigKAm+m1yJ4JR83sysFfoSc3Kf0vLlYC3edCtaZGYSwu6uSipZklkmqy4e4nZTH+R1XVxrfvehiu8WADZuEw4T+ew970hErsztnkcMhGLyjchnT+8hnlgKVkxaeXVzDv6NZ0Yc00OPZ7jdcW7gqHxrFVMNvnRek7BiD7L/y77tY+GoGXqDmRp5K7+aZVRMK2KmCEHxRGOK8DclXAG2Q4W48GmnbK52OnoPJdV8oaxhbZgWRv+BOtfJjlw2j1vlGUJqvAYaKh7/8VMAG++eqgQFTqA4AECmqZoUyaY32Ky2V9a+se8JsLueJio3MhsCmSOsOXCfaDayOynN/igNyTQwbjdj+H65yvnw/cn15N6JlN6wkGA9b9/Ycl9hXRfW17NtPebAmYDOP1F8MdXdL34aPpAe9Rh0CkVi+80js0aXU8rL1TOsk64xUG/SRNWF4Q6ccdPUY8lkwXLuDWJFxtJNdnndptmwk5E3+PED6Y+b8WsvTbuK8sdJUeM7GQ8n7/ruTZI4/xXDAXHkgMr/ILmtnF7mtIRwNDiUdBKzeVs8y6GEoaXmhOi/nIkXwLeIrZBNyPpVqjNnFm7R2UdlbjUj7Fw3PYuDGbyPZAuF39pYbBPOHCL8249eoNG7g+Dizn7P9/HMwGDv2/mXUytRAoH9bIpcEVs221ZpPLQfEkOhRz+K1mRpJCjEzN3S7HFtvWts8kIvU9X0oqXluNgO4m0f4/DWbLtilC6htgDrSUq740BZ/aIEtS1Al0bFuc+1kHx7/ep3HhADt/YC+KdAtxbIb/Ulf8DR yJMINuK+ B6R3+etMuOhjT3o3HkNh9K9VGZlT+fdNxZU2CAfC2ojVRfI8O1CL3VDVmDpFYne0Hpd5QV5BhaRbBFm+gqnozfGdEVUEgI50E8FLFsCpSXD7LOrYuE/NEvMbA9iVr3LOrdYKJA+xLXsixrbEDyWfsL39hTTsKpBx49T968pABvZzx+utgbdvj++nwoz/1gcHOkLcPp5pCu6Manusuk5Qe2FWhAiia3iHg3Hqkp/gYKhwBFTvkD6je3VxWohu4LTSW5dQQ 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 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? -- Lee Jones [李琼斯]