[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 <max%M00nBSD.net@localhost> 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
It doesn't happen after every reboot and breaks
dtrace which treats the region 0.. VM_MIN_KERNEL_ADDRESS
How could we test against the lowest address the kernel
J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - 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
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
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
VM_MIN_KERNEL_ADDRESS -> VM_MAX_KERNEL_ADDRESS
PMAP_DIRECT_BASE -> PMAP_DIRECT_END
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.
Main Index |
Thread Index |