linux-kernel - Re: [RFC][PATCH] kprobes: Add separate preempt

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]

Date:	Thu, 30 Jun 2011 12:46:27 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC][PATCH] kprobes: Add separate preempt_disabling for
 kprobes

On Thu, 2011-06-30 at 18:14 +0200, Frederic Weisbecker wrote:

> That's a bit sad we need to bloat preempt_schedule() with a new test, especially
> as kprobes should not add overhead in the off case and then I guess many distros
> enable kprobes by default, so it's probably not just enabled on some debug kernel.

A simple per_cpu var test is not that bad, and that's also why I put it
where I did. It only gets checked after all the other locations fail. I
doubt this really adds any measurable overhead. Note, most distro's
don't even enable CONFIG_PREEMPT so this isn't even touched by them.

> 
> Another idea could be to turn current_thread_info()->preempt_count into a local_t
> var which ensures a single incrementation is performed in a single instruction.

Not all archs support such a thing.

> 
> Well, in the hope that every arch can do something like:
> 
> inc (mem_addr)
> 
> IIRC, I believe arm can't... And the default local_inc is probably not helpful
> in our case...

Some archs (I believe) perform local_inc() slower than i++. In which
case, this solution will more likely slow things down even more than
what I proposed. As the impact will be on every preempt_disable and
enable.

And this would not even help for the place that I actually hit the crash
on. Which was in the scheduler. It wasn't the addition of the
preempt_count that caused my crash, it was just reading it.

	if (unlikely(in_atomic_preempt_off() && !prev->exit_state))
		__schedule_bug(prev);

The in_atomic_preempt_off() is what blew up on me.

#define in_atomic_preempt_off() \
		((preempt_count() & ~PREEMPT_ACTIVE) != PREEMPT_CHECK_OFFSET)

What happened was that the reading of preempt_count was single stepped.
And that had preempt_count set to one more due to the preempt_disable()
in kprobes. Even if preempt_count was a local_t, this bug would have
still triggered, and my system would have crashed anyway. (every
schedule caused a printk to happen).

-- Steve

--
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/