lkml.org 
[lkml]   [2023]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectKASLR 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().

\
 
 \ /
  Last update: 2023-03-27 00:43    [W:1.259 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site