From: <dan.j.williams@intel.com>
To: Balbir Singh <balbirs@nvidia.com>,
Dan Williams <dan.j.williams@intel.com>,
<dave.hansen@linux.intel.com>, <peterz@infradead.org>
Cc: <linux-mm@kvack.org>, <linux-cxl@vger.kernel.org>,
<linux-pci@vger.kernel.org>, 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>, Mike Rapoport <rppt@kernel.org>,
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: Mon, 10 Nov 2025 15:34:22 -0800 [thread overview]
Message-ID: <6912767eb60ac_1d9810070@dwillia2-mobl4.notmuch> (raw)
In-Reply-To: <d6ad21dd-82f1-486e-8a0d-b007b39b4d32@nvidia.com>
Balbir Singh wrote:
> On 11/8/25 13:32, 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>
>
> P2PDMA requires ZONE_DEVICE, Most distros have P2PDMA enabled, you mention
> smaller devices - are you referring to kernels/distros where P2PDMA is not
> enabled and only ZONE_DEVICE is?
There are 2 considerations
- Occasions where P2PDMA is disabled, but ZONE_DEVICE is enabled.
I started looking at this after a report about CXL failures with KASLR.
I do not have the kernel configuration for that end user report, but I
can only a imagine it was indeed a case of CONFIG_PCI_P2PDMA=n and
CONFIG_DEV_DAX_CXL=y
- Occasions where ZONE_DEVICE and memory hotplug are enabled, but ACPI
does not publish any hotplug or CXL memory ranges, and BIOS did not
find any large PCI devices at initial scan.
In this case even the default 10 TB padding is overkill and more address
bits could be consumed for KASLR entropy.
next prev parent reply other threads:[~2025-11-10 22:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-08 2:32 Dan Williams
2025-11-08 2:39 ` Balbir Singh
2025-11-10 23:34 ` dan.j.williams [this message]
2025-11-11 1:57 ` Balbir Singh
2025-11-12 10:17 ` Yasunori Gotou (Fujitsu)
2025-11-09 6:51 ` Mike Rapoport
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
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=6912767eb60ac_1d9810070@dwillia2-mobl4.notmuch \
--to=dan.j.williams@intel.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=balbirs@nvidia.com \
--cc=bhelgaas@google.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=rppt@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox