All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	Alexander Potapenko <glider@google.com>,
	Andrey Konovalov <andreyknvl@gmail.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	kasan-dev@googlegroups.com, Kees Cook <keescook@chromium.org>,
	Thomas Garnier <thgarnie@google.com>
Subject: KASLR vs. KASAN on x86
Date: Fri, 3 Mar 2023 14:35:32 -0800	[thread overview]
Message-ID: <299fbb80-e3ab-3b7c-3491-e85cac107930@intel.com> (raw)

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().

             reply	other threads:[~2023-03-03 22:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-03 22:35 Dave Hansen [this message]
2023-03-08 17:24 ` KASLR vs. KASAN on x86 Andrey Ryabinin
2023-03-13  9:41   ` Michal Koutný
2023-03-13 13:40     ` Andrey Ryabinin
2023-05-31 15:05       ` Michal Koutný

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=299fbb80-e3ab-3b7c-3491-e85cac107930@intel.com \
    --to=dave.hansen@intel.com \
    --cc=andreyknvl@gmail.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ryabinin.a.a@gmail.com \
    --cc=thgarnie@google.com \
    --cc=vincenzo.frascino@arm.com \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.