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 <>
To:	Ingo Molnar <>
Subject: Re: [tip:perf/core] x86/kprobes: Fix to recover instructions on optimized

(2012/02/23 17:37), Ingo Molnar wrote:
> * Ingo Molnar <> wrote:
>>>> Does not build on x86 if CONFIG_OPTPROBES is off:
>>>> arch/x86/kernel/kprobes.c:260:8: error: dereferencing pointer to incomplete
>>>> 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,

Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists