[ktap] Re: [PATCH] FFI support for ktap
- From: Masami Hiramatsu <masami.hiramatsu@xxxxxxxxx>
- To: ktap@xxxxxxxxxxxxx
- Date: Mon, 4 Nov 2013 21:00:54 +0900
2013/11/4 Jovi Zhangwei <jovi.zhangwei@xxxxxxxxx>
> On Mon, Nov 4, 2013 at 4:44 PM, Masami Hiramatsu
> <masami.hiramatsu@xxxxxxxxx> wrote:
> > Hi,
> >
> > At first, this looks great debugging feature! :)
> >
> > I just concern about safety, because many kernel functions are not
> > safely called from ktapvm context. For example, what happens if
> > I call sched() from ktap?
> >
> > IMHO, this kind of intrusive feature support should be enabled
> > by a debug kconfig, like CONFIG_KTAP_FFI which depends on
> > CONFIG_KTAP_INTRUSIVE_MODE.
> > And also, it looks better to have a knob to enable such kind of intrusive
> > mode on sysctl, like /proc/sys/debug/ktap-intrusive-mode which default
> > value is 0 (disabled).
> > This will allow admins to choose stability or maximum debug-ability on
> > their production/developing systems.
> >
> Thanks, Masami.
>
> FFI is powerful, but with damage sword. :)
>
> I planed to use a command option like "guru mode"(similar with Systemtap)
> in ktap, but I also doubt whether the command option really is enough to
> make
> ktap safe, user still can crash the kernel easily on ktap installed
> system, like
> the example you posted, just call the schedule in atomic context.
>
> Maintaining blacklist/whilelist functions for FFI also seems not
> practicable.
>
I doubt the blacklist works, there are too many functions to be checked
and such functions can silently break memory/device etc.
(for example, from my personal experiment, i8042 PS/2 controller will
lock up itself if doing the broken initializing process, and it is not able
to unlock even by power-off/reboot.)
So, only the white-list may handle it. But anyway, such white-listed
functions also be changed by any commit.
Thus, I recommend you to give a knob to enable it and it might better to
"taint" kernel, since it is very powerful if real "guru" uses it ;)
I think giving such knob to sysadmin also lets distros to hire ktap
easier, because they can ensure that ktap is safe and guarantee it
unless such intrusive features are enabled. :)
> So I agree with you since I have no other idea now, seems we have to
> disable
> it in build stage if user want ktap to be completely safe (like the
> safety in Dtrace).
> How about Systemtap handle this? just only "guru mode"? allow to call
> sleep-able function in atomic context by some trick?
>
Systemtap gives no guarantee of safety about the "guru mode".
Users must use it at their own risk...
Thank you,
--
Masami Hiramatsu
mailto:masami.hiramatsu@xxxxxxxxx
Other related posts:
