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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20150819171811.GB21717@lerouge>
Date:	Wed, 19 Aug 2015 19:18:12 +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 18, 2015 at 03:40:20PM -0700, Andy Lutomirski wrote:
> On Tue, Aug 18, 2015 at 3:34 PM, Frederic Weisbecker <fweisbec@...il.com> wrote:
> >> If we switched back to exception_enter, we'd have to remember the
> >> previous state, and, with a single exception right now, I think that's
> >> unnecessary.
> >>
> >> I think there are only three states we can be in at exception entry:
> >> user (and user_mode(regs)), kernel (and kernel_mode(regs)), or
> >> NMI-like.
> >
> > But we can have user && (!user_mode(regs)) if exception happens on exception
> > entry code.
> 
> I sure hope not, unless it nests inside an NMI-like thing.  It's
> conceivable that this might happen due to perf NMIs causing a failed
> MSR read or similar.  We might need to relax the assertions to check
> that we're either in kernel or NMI context.  If so, that's
> straightforward.  Meanwhile no one has reported this happening.

But we can still have #DB on entry code right? We blocked breakpoints on entry
code (I still don't get why and it looks to me like an overkill) but we still
have watchpoints.

> 
> >
> >> In the user case, the new code is correct.  In the kernel
> >> case, the new code is also correct.  In the NMI case (if we're nested
> >> in an NMI or similar entry)) then it is and was the responsibility of
> >> the NMI-like entry to call rcu_nmi_enter(), and things that nest
> >> inside that shouldn't touch context tracking (with the possible
> >> exception of calling rcu_nmi_enter() again).
> >>
> >> In current -tip, there's a slight hole in this due to syscalls, and I'll fix it.
> >
> > There must be a check for context tracking enabled anyway. So why can't
> > we just just do in exception entry code:
> >
> >        if (exception_slow_path()) {
> >            exception_enter()
> >            exception_handler()
> >            exception_exit()
> >        } else {
> >            normal stuff
> >        }
> >
> > Especially if we can manage to implement static keys in ASM, this will sum up to
> > a single one.
> 
> There isn't really an exception slow path.  There's already a branch
> for user vs kernel (in the CPL sense), and with my patches, there's no
> additional branch for previous context tracking state.

But an exception slow path based on static key would the most lightweight
thing for context tracking off-case (which is 99.9999% of usecases) and we
would keep it robust (ie: no need to enumerate all the fragile non-possibility
for an exception in entry code to get it safe).

> > So now we can't set a breakpoint on syscall entry anymore?
> >
> > I'm still nervous with all that.
> 
> We haven't done anything that would make breakpoints on syscall entry
> less safe than they were, but we now disallow the breakpoints.  In the
> future, we might take advantage of that change.

I still don't get the reason of that.
--
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/