From: Mike Rapoport <rppt@kernel.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: dave.hansen@linux.intel.com, peterz@infradead.org,
linux-mm@kvack.org, linux-cxl@vger.kernel.org,
linux-pci@vger.kernel.org, Balbir Singh <balbirs@nvidia.com>,
Ingo Molnar <mingo@kernel.org>, Kees Cook <kees@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Andy Lutomirski <luto@kernel.org>,
Logan Gunthorpe <logang@deltatee.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@redhat.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
"Yasunori Gotou (Fujitsu)" <y-goto@fujitsu.com>
Subject: Re: [PATCH] x86/kaslr: P2PDMA is one of a class of ZONE_DEVICE-KASLR collisions
Date: Sun, 9 Nov 2025 08:51:39 +0200 [thread overview]
Message-ID: <aRA5-wgo6bm_TA74@kernel.org> (raw)
In-Reply-To: <20251108023215.2984031-1-dan.j.williams@intel.com>
On Fri, Nov 07, 2025 at 06:32:15PM -0800, Dan Williams wrote:
> Commit 7ffb791423c7 ("x86/kaslr: Reduce KASLR entropy on most x86 systems")
> is too narrow. ZONE_DEVICE, in general, lets any physical address be added
> to the direct-map. I.e. not only ACPI hotplug ranges, CXL Memory Windows,
> or EFI Specific Purpose Memory, but also any PCI MMIO range for the
> CONFIG_DEVICE_PRIVATE and CONFIG_PCI_P2PDMA cases.
>
> A potential path to recover entropy would be to walk ACPI and determine the
> limits for hotplug and PCI MMIO before kernel_randomize_memory(). On
> smaller systems that could yield some KASLR address bits. This needs
> additional investigation to determine if some limited ACPI table scanning
> can happen this early without an open coded solution like
> arch/x86/boot/compressed/acpi.c needs to deploy.
>
> Cc: Balbir Singh <balbirs@nvidia.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Kees Cook <kees@kernel.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Logan Gunthorpe <logang@deltatee.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Mike Rapoport <rppt@kernel.org>
> Cc: Suren Baghdasaryan <surenb@google.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: "Yasunori Gotou (Fujitsu)" <y-goto@fujitsu.com>
> Fixes: 7ffb791423c7 ("x86/kaslr: Reduce KASLR entropy on most x86 systems")
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> drivers/pci/Kconfig | 6 ------
> mm/Kconfig | 12 ++++++++----
> arch/x86/mm/kaslr.c | 10 +++++-----
> 3 files changed, 13 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index f94f5d384362..47e466946bed 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -207,12 +207,6 @@ config PCI_P2PDMA
> P2P DMA transactions must be between devices behind the same root
> port.
>
> - Enabling this option will reduce the entropy of x86 KASLR memory
> - regions. For example - on a 46 bit system, the entropy goes down
> - from 16 bits to 15 bits. The actual reduction in entropy depends
> - on the physical address bits, on processor features, kernel config
> - (5 level page table) and physical memory present on the system.
> -
> If unsure, say N.
>
> config PCI_LABEL
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 0e26f4fc8717..d17ebcc1a029 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -1128,10 +1128,14 @@ config ZONE_DEVICE
> Device memory hotplug support allows for establishing pmem,
> or other device driver discovered memory regions, in the
> memmap. This allows pfn_to_page() lookups of otherwise
> - "device-physical" addresses which is needed for using a DAX
> - mapping in an O_DIRECT operation, among other things.
> -
> - If FS_DAX is enabled, then say Y.
> + "device-physical" addresses which is needed for DAX, PCI_P2PDMA, and
> + DEVICE_PRIVATE features among others.
> +
> + Enabling this option will reduce the entropy of x86 KASLR memory
> + regions. For example - on a 46 bit system, the entropy goes down
> + from 16 bits to 15 bits. The actual reduction in entropy depends
> + on the physical address bits, on processor features, kernel config
> + (5 level page table) and physical memory present on the system.
>
> #
> # Helpers to mirror range of the CPU page tables of a process into device page
> diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
> index 3c306de52fd4..834641c6049a 100644
> --- a/arch/x86/mm/kaslr.c
> +++ b/arch/x86/mm/kaslr.c
> @@ -115,12 +115,12 @@ void __init kernel_randomize_memory(void)
>
> /*
> * Adapt physical memory region size based on available memory,
> - * except when CONFIG_PCI_P2PDMA is enabled. P2PDMA exposes the
> - * device BAR space assuming the direct map space is large enough
> - * for creating a ZONE_DEVICE mapping in the direct map corresponding
> - * to the physical BAR address.
> + * except when CONFIG_ZONE_DEVICE is enabled. ZONE_DEVICE wants to map
> + * any physical address into the direct-map. KASLR wants to reliably
> + * steal some physical address bits. Those design choices are in direct
> + * conflict.
> */
> - if (!IS_ENABLED(CONFIG_PCI_P2PDMA) && (memory_tb < kaslr_regions[0].size_tb))
> + if (!IS_ENABLED(CONFIG_ZONE_DEVICE) && (memory_tb < kaslr_regions[0].size_tb))
> kaslr_regions[0].size_tb = memory_tb;
A stupid question, why we adjust virtual kaslr to actual physical memory
size at all rather than always use maximal addressable size?
> /*
>
> base-commit: 6146a0f1dfae5d37442a9ddcba012add260bceb0
> --
> 2.51.0
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2025-11-09 6:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-08 2:32 [PATCH] x86/kaslr: P2PDMA is one of a class of ZONE_DEVICE-KASLR collisions Dan Williams
2025-11-08 2:39 ` Balbir Singh
2025-11-10 23:34 ` dan.j.williams
2025-11-11 1:57 ` Balbir Singh
2025-11-12 10:17 ` Yasunori Gotou (Fujitsu)
2025-11-09 6:51 ` Mike Rapoport [this message]
2025-11-10 23:39 ` dan.j.williams
2025-11-11 1:22 ` Balbir Singh
2025-12-01 17:39 ` Dave Hansen
2025-12-01 21:29 ` dan.j.williams
2026-01-06 1:11 ` Dave Jiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aRA5-wgo6bm_TA74@kernel.org \
--to=rppt@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=balbirs@nvidia.com \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=kees@kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pci@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=lorenzo.stoakes@oracle.com \
--cc=luto@kernel.org \
--cc=mhocko@suse.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=y-goto@fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.