[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrUAQSg9fQmLwE_tq58sZgMxjVX3iNmPeF-V8-gVBQ+_zQ@mail.gmail.com>
Date: Mon, 20 Nov 2017 13:44:43 -0800
From: Andy Lutomirski <luto@...nel.org>
To: Andy Lutomirski <luto@...nel.org>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
kasan-dev <kasan-dev@...glegroups.com>
Cc: X86 ML <x86@...nel.org>, Borislav Petkov <bpetkov@...e.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Brian Gerst <brgerst@...il.com>,
Dave Hansen <dave.hansen@...el.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Josh Poimboeuf <jpoimboe@...hat.com>
Subject: KASAN help, please (Re: [PATCH 00/16] Entry stuff, in decent shape now)
On Mon, Nov 20, 2017 at 9:07 AM, Andy Lutomirski <luto@...nel.org> wrote:
> This sets up stack switching, including for SYSCALL. I think it's
> in decent shape.
>
> Known issues:
> - KASAN is likely to be busted. This could be fixed either by teaching
> KASAN that cpu_entry_area contains valid stacks (I have no clue how
> to go about doing this) or by rigging up the IST entry code to switch
> RSP to point to the direct-mapped copy of the stacks before calling
> into non-KASAN-excluded C code.
>
I tried to fix the KASAN issue, and I'm doing something wrong. I'm
building this tree:
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/entry_stack&id=8319677bd04a1ab291ca71fe1da7aa023306e4a9
for 64 bits with KASAN on. The relevant commit is:
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/entry_stack&id=a4bdb48c3469708b6b51e5ab90d27bf0c859000c
If I run tools/testing/selftests/single_step_syscall_32, then the
kernel goes into lala land and infinite loops. The root cause seems
to we're hitting do_debug with RSP pointing into the fixmap,
specifically in the cpu_entry_area's exception stack, with a value of
roughly 0xffffffffff1bd108. The KASAN instrumentation in do_debug is
then getting a page fault. I think my KASAN setup code should be
populating the KASAN data there and, indeed, gdb seems to be able to
access the faulting address. So I'm confused.
Help?
Powered by blists - more mailing lists