[ktap] Re: [PATCH] FFI support for ktap
- From: Jovi Zhangwei <jovi.zhangwei@xxxxxxxxx>
- To: ktap@xxxxxxxxxxxxx
- Date: Mon, 4 Nov 2013 21:06:18 +0800
On Mon, Nov 4, 2013 at 8:00 PM, Masami Hiramatsu
<masami.hiramatsu@xxxxxxxxx> wrote:
> 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. :)
>
Yes, agreed.
Based on ktap is not merged by Linux kernel at present, it's not proper
to use Kconfig to enable/disable ffi functionality, the sysctl also cannot
be extend from kernel module.
So maybe we can enable/disable ffi in Makefile (make --enable-ffi) in
current stage, and should expose the ffi configuration in ktap tool.
# ktap --version
version 0.4
ffi enabled (or disabled)
...
Once(If) ktap merged into Linux kernel, then we can switch to your
approach, I like CONFIG_KTAP_FFI and sysctl configuration in your
approach.
Comments?
Other related posts:
