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:	Tue, 04 Feb 2014 21:53:49 +0800
From:	Chen Gang <gang.chen.5i5j@...il.com>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
CC:	ananth@...ibm.com, anil.s.keshavamurthy@...el.com,
	HÃ¥vard Skinnemoen 
	<hskinnemoen@...il.com>, David Miller <davem@...emloft.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Hans-Christian Egtvedt <egtvedt@...fundet.no>,
	"yrl.pp-manager.tt@...achi.com" <yrl.pp-manager.tt@...achi.com>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] kernel: kprobe: move all *kretprobe* generic implementation
 to CONFIG_KRETPROBES enabled area

On 02/04/2014 09:29 PM, Masami Hiramatsu wrote:
> (2014/02/04 21:07), Chen Gang wrote:
>> On 02/04/2014 03:17 PM, Masami Hiramatsu wrote:
>>> (2014/02/04 14:16), Chen Gang wrote:
>>>> When CONFIG_KRETPROBES disabled, all *kretprobe* generic implementation
>>>> are useless, so need move them to CONFIG_KPROBES enabled area.
>>>>
>>>> Now, *kretprobe* generic implementation are all implemented in 2 files:
>>>>
>>>>  - in "include/linux/kprobes.h":
>>>>
>>>>      move inline kretprobe*() to CONFIG_KPROBES area and dummy outside.
>>>>      move some *kprobe() declarations which kretprobe*() call, to front.
>>>>      not touch kretprobe_blacklist[] which is architecture's variable.
>>>>
>>>>  - in "kernel/kprobes.c":
>>>>
>>>>      move all kretprobe* to CONFIG_KPROBES area and dummy outside.
>>>>      define kretprobe_flush_task() to let kprobe_flush_task() call.
>>>>      define init_kretprobes() to let init_kprobes() call.
>>>>
>>>> The patch passes compiling (get "kernel/kprobes.o" and "kernel/built-
>>>> in.o") under avr32 and x86_64 allmodconfig, and passes building (get
>>>> bzImage and Modpost modules) under x86_64 defconfig.
>>>
>>> Thanks for the fix! and I have some comments below.
>>>
>>>> Signed-off-by: Chen Gang <gang.chen.5i5j@...il.com>
>>>> ---
>>>>  include/linux/kprobes.h |  58 +++++----
>>>>  kernel/kprobes.c        | 328 +++++++++++++++++++++++++++---------------------
>>>>  2 files changed, 222 insertions(+), 164 deletions(-)
>>>>
>>>> diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
>>>> index 925eaf2..c0d1212 100644
>>>> --- a/include/linux/kprobes.h
>>>> +++ b/include/linux/kprobes.h
>>>> @@ -223,10 +223,36 @@ static inline int kprobes_built_in(void)
>>>>   return 1;
>>>>  }
>>>>  
>>>> +int disable_kprobe(struct kprobe *kp);
>>>> +int enable_kprobe(struct kprobe *kp);
>>>> +
>>>> +void dump_kprobe(struct kprobe *kp);
>>>> +
>>>> +extern struct kretprobe_blackpoint kretprobe_blacklist[];
>>>> +
>>>>  #ifdef CONFIG_KRETPROBES
>>>>  extern void arch_prepare_kretprobe(struct kretprobe_instance *ri,
>>>>     struct pt_regs *regs);
>>>>  extern int arch_trampoline_kprobe(struct kprobe *p);
>>>> +static inline void kretprobe_assert(struct kretprobe_instance *ri,
>>>> + unsigned long orig_ret_address, unsigned long trampoline_address)
>>>> +{
>>>> + if (!orig_ret_address || (orig_ret_address == trampoline_address)) {
>>>> + printk(KERN_ERR
>>>> + "kretprobe BUG!: Processing kretprobe %p @ %p\n",
>>>> + ri->rp, ri->rp->kp.addr);
>>>> + BUG();
>>>> + }
>>>> +}
>>>> +static inline int disable_kretprobe(struct kretprobe *rp)
>>>> +{
>>>> + return disable_kprobe(&rp->kp);
>>>> +}
>>>> +static inline int enable_kretprobe(struct kretprobe *rp)
>>>> +{
>>>> + return enable_kprobe(&rp->kp);
>>>> +}
>>>> +
>>>>  #else /* CONFIG_KRETPROBES */
>>>>  static inline void arch_prepare_kretprobe(struct kretprobe *rp,
>>>>   struct pt_regs *regs)
>>>> @@ -236,19 +262,20 @@ static inline int arch_trampoline_kprobe(struct kprobe *p)
>>>>  {
>>>>   return 0;
>>>>  }
>>>> -#endif /* CONFIG_KRETPROBES */
>>>> -
>>>> -extern struct kretprobe_blackpoint kretprobe_blacklist[];
>>>> -
>>>>  static inline void kretprobe_assert(struct kretprobe_instance *ri,
>>>>   unsigned long orig_ret_address, unsigned long trampoline_address)
>>>>  {
>>>> - if (!orig_ret_address || (orig_ret_address == trampoline_address)) {
>>>> - printk("kretprobe BUG!: Processing kretprobe %p @ %p\n",
>>>> - ri->rp, ri->rp->kp.addr);
>>>> - BUG();
>>>> - }
>>>>  }
>>>> +static inline int disable_kretprobe(struct kretprobe *rp)
>>>> +{
>>>> + return 0;
>>>> +}
>>>> +static inline int enable_kretprobe(struct kretprobe *rp)
>>>> +{
>>>> + return 0;
>>>> +}
>>>
>>> No, these should returns -EINVAL or -ENOSYS, since these are user API.
>>
>> OK, thanks, it sounds reasonable to me.
>>
>>> Anyway, I don't think those inlined functions to be changed, because
>>> most of them are internal functions. If CONFIG_KRETPROBES=n, it just
>>> be ignored.
>>>
>>
>> In original implementation, if CONFIG_KRETPROBES=n, kretprobe_assert(),
>> disable_kretprobe(), and enable_kretprobe() are not ignored.
> 
> Really? where are they called? I mean, those functions do not have
> any instance unless your module uses it (but that is not what the kernel
> itself should help).
> 

If what you said correct (I guess so), for me, we still need let them in
CONFIG_KRETPROBES area, and without any dummy outside, just like another
*kprobe* static inline functions have done in "include/linux/kprobes.h".


>>
>>> So, I think you don't need to change kprobes.h.
>>>
>>
>> So "kprobes.h" still need be changed.
> 
> Is there any concrete problem you have?
> 

No, I just read the code, no additional really issues.


Thanks.
-- 
Chen Gang

Open, share and attitude like air, water and life which God blessed
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ