MIME-Version: 1.0
References: <299fbb80-e3ab-3b7c-3491-e85cac107930@intel.com>
In-Reply-To: <299fbb80-e3ab-3b7c-3491-e85cac107930@intel.com>
From:   Andrey Ryabinin <ryabinin.a.a@gmail.com>
Date:   Wed, 8 Mar 2023 18:24:05 +0100
Message-ID: <CAPAsAGyG2_sUfb7aPSPuMatMraDbPCFKxhv2kSDkrV1XxQ8_bw@mail.gmail.com>
Subject: Re: KASLR vs. KASAN on x86
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     "the arch/x86 maintainers" <x86@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Mar 3, 2023 at 11:35=E2=80=AFPM Dave Hansen <dave.hansen@intel.com>=
 wrote:
>
> 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?
>

Yeah, I agree with you here, the comment doesn't make sense to me as well.
However, I see one problem with KASAN and kernel_randomize_memory()
compatibility:
vaddr_start - vaddr_end includes KASAN shadow memory
(Documentation/x86/x86_64/mm.rst):
   ffffea0000000000 |  -22    TB | ffffeaffffffffff |    1 TB |
virtual memory map (vmemmap_base)
   ffffeb0000000000 |  -21    TB | ffffebffffffffff |    1 TB | ... unused =
hole
   ffffec0000000000 |  -20    TB | fffffbffffffffff |   16 TB | KASAN
shadow memory
   fffffc0000000000 |   -4    TB | fffffdffffffffff |    2 TB | ... unused =
hole
                    |            |                  |         |
vaddr_end for KASLR

So the vmemmap_base and probably some part of vmalloc could easily end
up in KASAN shadow.

> 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 r=
ange: 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().

This code looks correct to me. __START_KERNEL is just a constant, it's
never randomized.
The location of the kernel image (.text, .data ...) however is
randomized, kaslr_offset() - is the random number here.
So
kaslr_enabled() - randomization of the kernel image and modules.
kaslr_memory_enabled() - randomization of the linear mapping
(__PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap (VMEMMAP_START)