Messages in this thread | | | Date | Fri, 3 Mar 2023 14:35:32 -0800 | From | Dave Hansen <> | Subject | KASLR vs. KASAN on x86 |
| |
Hi KASAN folks,
Currently, x86 disables (most) KASLR when KASAN is enabled:
> /* > * Apply no randomization if KASLR was disabled at boot or if KASAN > * is enabled. KASAN shadow mappings rely on regions being PGD aligned. > */ > static inline bool kaslr_memory_enabled(void) > { > return kaslr_enabled() && !IS_ENABLED(CONFIG_KASAN); > }
I'm a bit confused by this, though. This code predates 5-level paging so a PGD should be assumed to be 512G. The kernel_randomize_memory() granularity seems to be 1 TB, which *is* PGD-aligned.
Are KASAN and kernel_randomize_memory()/KASLR (modules and cpu_entry_area randomization is separate) really incompatible? Does anyone have a more thorough explanation than that comment?
This isn't a big deal since KASAN is a debugging option after all. But, I'm trying to unravel why this:
> if (kaslr_enabled()) { > pr_emerg("Kernel Offset: 0x%lx from 0x%lx (relocation range: 0x%lx-0x%lx)\n", > kaslr_offset(), > __START_KERNEL, > __START_KERNEL_map, > MODULES_VADDR-1);
for instance uses kaslr_enabled() which includes just randomizing module_load_offset, but *not* __START_KERNEL. I think this case should be using kaslr_memory_enabled() to match up with the check in kernel_randomize_memory(). But this really boils down to what the difference is between kaslr_memory_enabled() and kaslr_enabled().
| |