This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: can kprobes be modular?


David Wilder wrote:

Roland McGrath wrote:

I was reading over some things, and it occurred to me that kprobes ought to
be a loadable kernel module. I don't have any special motivation for this.
It just seems like an unclean situation that it can't be a module now.
Perhaps many kernels will want to build it in anyway, but I can't see why
it isn't a module. It's not very big, but neither are many other things
that are used much more often and are built as modules.


The #ifdef CONFIG_KPROBES sections in e.g. arch/i386/kernel/traps.c look to
me like things that ought to be enabled unconditionally, so kprobes or any
other module could use them. Things like register_page_fault_notifier
ought to just be enabled and exported by default.


Thoughts?


Thanks,
Roland


What do we gain by making kprobes a module? The only reason I can think of is so a system administrator could disable the feature at will to prevent possible security holes. Any other reasons to do this?.

Well you need to be a super user today to load a module that makes use of kprobes interfaces so, i am not sure i understand what is the security risk you are talking about.




On the s390 side, kprobes is dependent code in the core exception handlers in entry.S. This can't be put into a module so a new interface would need to be created that kprobes could use. Is it worth adding another layer?




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]