linux-kernel - Re: [tip:x86/asm] x86/asm/entry/64: Migrate error and IRQ exit work to C and remove old assembly code

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20150811232234.GD15639@lerouge>
Date:	Wed, 12 Aug 2015 01:22:35 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Denys Vlasenko <dvlasenk@...hat.com>,
	Rik van Riel <riel@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Brian Gerst <brgerst@...il.com>,
	Denys Vlasenko <vda.linux@...glemail.com>,
	Kees Cook <keescook@...omium.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Oleg Nesterov <oleg@...hat.com>,
	Andrew Lutomirski <luto@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-tip-commits@...r.kernel.org" 
	<linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:x86/asm] x86/asm/entry/64: Migrate error and IRQ exit work
 to C and remove old assembly code


On Tue, Aug 11, 2015 at 03:51:26PM -0700, Andy Lutomirski wrote:
> On Tue, Aug 11, 2015 at 3:38 PM, Frederic Weisbecker <fweisbec@...il.com> wrote:
> >
> > This makes me very nervous as well!
> >
> > It means that instead of using the context tracking save/restore model that we had
> > with exception_enter/exception_exit(), now we rely on the CS register.
> >
> > I don't think we can do that because our "context tracking" is a soft tracking whereas
> > CS is hard tracking and both are not atomically synchronized together.
> >
> > Imagine this situation: we are running in userspace. Context tracking knows it, everything
> > is fine. Now we do a syscall, we enter in kernel entry code but we trigger an exception
> > (DEBUG for example) before we got a chance to call user_exit(), which means that the context
> > tracking code still thinks we are in userspace, so we look at CS from the exception entry code
> > and it says the exception happened in the kernel. Hence we don't call user_exit() before calling
> > the exception handler. There is the bug because the exception handler may use RCU which still
> > thinks we run in userspace.
> 
> #DB doesn't go through this patch -- it uses the paranoid entry path
> and ist_enter.  But I see your point.  I think that, if we have a
> problem like this in practice, then we should fix it.

Whatever hack we do to prevent from exceptions happening in between real kernel entry
to tracked kernel entry is going to be far less robust than relying strictly on soft
context tracking.

The resulting bugs are rare and very hard to reproduce and diagnose.

> 
> But the old code had the same issue.  If we got an exception (the most
> likely one is probably a vmalloc fault) during user_exit and we then
> hit exception_enter, the result would probably be bad.

We have a recursion protection in context tracking that should protect against
exceptions triggering in the middle of half-set states.

> 
> >
> > In early context tracking days we have relied on CS. But I changed that because of such
> > issue. The only reliable source for soft context tracking is the soft context tracking itself.
> 
> I don't see why the soft state is more reliable.  The only bad case is
> where the entry itself (HW entry up to user_exit) is not atomic
> enough, but that path should be at least as atomic as user_exit itself
> is.

Note it's not only about entry code up to user_exit() but also about
user_enter() up to iret.

Also as long as there is at least one instruction between entry to the kernel
and context tracking noting it, there is a risk for an exception. Hence entry
code will never be atomic enough to avoid this kind of bugs.

Heh if only we had something like local_exception_save()!
--
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/