linux-kernel - Re: [PATCH v2 3/3] x86/entry/64: Move #BP from IST to the IRQ stack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrXS_54QAQHWD+KmKAfipb89uo8YWSkX_8n-RYYK1GzX+A@mail.gmail.com>
Date:	Wed, 29 Jul 2015 10:57:26 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Brian Gerst <brgerst@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>, Willy Tarreau <w@....eu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v2 3/3] x86/entry/64: Move #BP from IST to the IRQ stack

On Tue, Jul 28, 2015 at 2:54 AM, Borislav Petkov <bp@...en8.de> wrote:
> On Fri, Jul 24, 2015 at 10:57:06PM -0700, Andy Lutomirski wrote:
>> There's nothing IST-worthy about #BP/int3.  We don't allow kprobes
>> in the small handful of places in the kernel that run at CPL0 with
>> an invalid stack, and 32-bit kernels have used normal interrupt
>> gates for #BP forever.
>>
>> Furthermore, we don't allow kprobes in places that have usergs while
>> in kernel mode, so "paranoid" is also unnecessary.
>>
>> Signed-off-by: Andy Lutomirski <luto@...nel.org>
>> ---
>>  arch/x86/entry/entry_64.S |  2 +-
>>  arch/x86/kernel/traps.c   | 26 +++++++++++++-------------
>>  2 files changed, 14 insertions(+), 14 deletions(-)
>
> ...
>
>> @@ -494,7 +494,15 @@ dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code)
>>       if (poke_int3_handler(regs))
>>               return;
>>
>> +     /*
>> +      * Use ist_enter despite the fact that we don't use an IST stack.
>> +      * We can be called from a kprobe in non-CONTEXT_KERNEL kernel
>> +      * mode or even during context tracking state changes.
>> +      *
>> +      * This means that we can't schedule.  That's okay.
>> +      */
>>       ist_enter(regs);
>
> Let's rename that thing. Call it atomic_ctxt_enter or whatever...
>

OK if I do that as a follow-up?  It would probably want to be a
separate patch anyway.

Hmm, I'm starting to like this new regime in which we never ever
switch to user mode from anywhere other than the standard kernel
stack.  It looks like even Xen may play along and do it cleanly soon
:)  Maybe I'll even add an assertion somewhere to make sure we don't
break it.  (I think this also means that the bad iret fixup can be
simplified.)

Also, with all this stuff applied (and the modify_ldt thing, once the
Xen folks figure out what's wrong), I think we can reinstate the old
LARL check for 16-bit segments and thus prevent naughty users from
banging on espfix using only sigreturn.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/