linux-kernel - Re: [tip:perf/core] x86/kprobes: Fix to recover instructions on optimized path

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, 23 Feb 2012 23:29:03 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	mingo@...hat.com, hpa@...or.com, ananth@...ibm.com,
	linux-kernel@...r.kernel.org, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:perf/core] x86/kprobes: Fix to recover instructions on optimized
 path

(2012/02/23 17:37), Ingo Molnar wrote:
>
> * Ingo Molnar <mingo@...e.hu> wrote:
>
>>>> Does not build on x86 if CONFIG_OPTPROBES is off:
>>>>
>>>> arch/x86/kernel/kprobes.c:260:8: error: dereferencing pointer to incomplete
type
>>>> arch/x86/kernel/kprobes.c:260:8: error: invalid use of undefined type
‘struct optimized_kprobe’
>>>> arch/x86/kernel/kprobes.c:262:22: error: dereferencing pointer to
incomplete type
>>>> arch/x86/kernel/kprobes.c:264:18: error: dereferencing pointer to
incomplete type
>>>
>>> Oops, should I update this patch or send new diff?
>>
>> Please send a delta fix.
>
> Hm, it was triggering too often so I removed it from perf:core
> for now - please send an updated patch.

I see.

> Please also pick up the slightly updated changelog I've created
> for the commit - you can see it in the -tip notification email.

OK, I'll do that.

> Btw., why are optprobes limited to !PREEMPT, could we make them
> preempt safe?

Hmm, it may be (become) possible. I need to look into preempt code
carefully, since there are many updates after optprobe was merged.

Originally, there are two issues on enabling optprobe with
preemptive kernel.

One problem can happen when inserting a jump. If we put a kprobe
on preemptive place, some threads might be interrupted and
preempted near there.
After we replaces instructions with a jump, the thread is scheduled
and can go back on the instruction which has already been replaced!

For prohibiting that kind of accident, currently optprobe builds a
bypass route with a breakpoint and copied code, and waits for
interrupted tasks by using synchronize_sched().

Another problem is similar to above. When releasing the bypass code
buffer, we need to wait until that all tasks, who run on there,
get out from the buffer (and again, they can be interrupted.)
So, optprobe uses synchronize_sched() again.

I'm not sure that any progress has been done on preemptive kernel.
At least when I made optprobe, I can ensure that any interrupts
has done, but can not wait for the kernel-preempted tasks.

I think optprobe with preemption requires such API which can wait
for that all tasks, who are kernel-preempted at that time, are
scheduled again and return to user-space or yield by themselves.

Please tell me if you know such one :)

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com
--
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/