Re: [ANNOUNCE] ktap 0.1 released

From: zhangwei(Jovi)
Date: Thu May 23 2013 - 23:20:12 EST

On 2013/5/22 2:13, Frank Ch. Eigler wrote:
> "zhangwei(Jovi)" <jovi.zhangwei@xxxxxxxxxx> writes:
>> I'm pleased to announce that ktap release v0.1, this is the first official
>> release of ktap project [...]
> Congrats.
>> = what's ktap?
>> Because this is the first release, so there wouldn't include too
>> much features, just contain several basic features about tracing,
>> [...]
> Nice progress. Reviewing the safety/security items from
>, I see improvement in most.
Thanks, frank, you give me a lot of helpful technical comments in that RFC mail,
also as this one :) really thanks.
> For example, you seem to be using GFP_ATOMIC for run-time memory
> allocation, which is safer than before (though still could exhaust
> resources). OTOH your code doesn't handle *failure* of such
> allocation attempts (see call sites to kp_*alloc).
Yes, memory allocation would be change to be more safer.
> There still doesn't seem to be safety constraints on the incoming
> byte code (like jump ranges, or loop counts).
> It's nice to see some arithmetic OP_* checks, and the user_string
> function is probably safe enough now. You'll need something analogous
> for kernel space (and possibly as verification for the various %s
> kp_printfs). The hash tables might be susceptible to the deliberate
> hash collision attacks from last year.
Current hashtable implementation is efficient, but need have more
security concern as you pointed.
> It's nice to see the *_STACK_SIZE constraints in the bytecode
> interpreter; is there any C-level recursion remaining to consume
> excessive kernel stack?
library C functions should not be a problem, like other kernel functions,
author should take care on stack overflow in own risk.
> Exposing os.sleep/os.wait (or general kernel functions) to become
> callable from the scripts is fraught with danger. You just can't call
> the underlying functions from random kernel context (imagine from the
> most pessimal possible kprobe or tracepoint, somewhere within an
> atomic section), and you'll get crashes.
Right, so those functions only can be called from mainthread,
I will add these checking later.

> You should write several time/space/invasivity stress-tests to help
> see how future progress improves the code's performance/safety on
> these and other problem areas.
Yes, there already have a test/ directory for basic functionality testing,
obviously it's not enough, I will add more benchmark and safety checking testcases.
>> = Planned Changes
>> we are planning to enable more kernel ineroperability into ktap [...]
> As per the above, you'll want to be extremely careful about the idea
> to export FFI to let the lua scripts call into arbitrary kernel
> functions. Perhaps wrap it into a 'guru' mode flag?
Definitely, there must need a mode flag to separate safety and not-safety.
> - FChE
> .

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at