tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kmem_alloc() vs. VM_MIN_KERNEL_ADDRESS

Le 02/07/2019 à 16:21, J. Hannken-Illjes a écrit :
On 1. Jul 2019, at 20:12, Maxime Villard <> wrote:

Le 01/07/2019 à 19:40, J. Hannken-Illjes a écrit :
Sometimes kmem_alloc() returns an address below
VM_MIN_KERNEL_ADDRESS, something like
   kmem_alloc() -> 0xffffaba25800a5a8 with
   VM_MIN_KERNEL_ADDRESS 0xffffad8000000000
It doesn't happen after every reboot and breaks
dtrace which treats the region 0.. VM_MIN_KERNEL_ADDRESS
as toxic.
How could we test against the lowest address the kernel
may use?
J. Hannken-Illjes - - TU Braunschweig

Mmh, this seems to be a side effect of 1/2-KASLR which is enabled by default
in GENERIC. Reminder: in GENERIC, we now randomize by default every kernel
memory region.

It is now possible that the direct map is below the main memory map -- it was
not the case before. kmem_alloc uses the direct map for certain allocations.

First, please confirm by also dumping PMAP_DIRECT_BASE and PMAP_DIRECT_END to
make sure the area returned by kmem_alloc is indeed in the dmap when dtrace
doesn't work.

Then, it seems that dtrace should be taught to consider as toxic everything
that is neither in the main map nor in the dmap. That is, only these ranges
are valid:


There is no actual "lowest" address the kernel may use; there are just two
separate regions that are valid. (Plus the kernel image itself, if it

It would work but unfortunately dtrace is a module and cannot
use PMAP_DIRECT_BASE aka. pmap_direct_base.  These variables
are not visible from module context and don't exist if the
kernel is built with KASAN.


Solaris uses the toxic areas 0 .. _userlimit and all regions
mapped from devices.

Will the kernel ever map anything below


Do we have a mapping that contains all device-mapped memory?

No, it's either the main map or the direct map.

Home | Main Index | Thread Index | Old Index