linux-kernel - Re: [ANNOUNCE] ktap 0.1 released

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] [day] [month] [year] [list]

Date:	Fri, 24 May 2013 11:17:37 +0800
From:	"zhangwei(Jovi)" <jovi.zhangwei@...wei.com>
To:	"Frank Ch. Eigler" <fche@...hat.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [ANNOUNCE] ktap 0.1 released

On 2013/5/22 2:13, Frank Ch. Eigler wrote:
> "zhangwei(Jovi)" <jovi.zhangwei@...wei.com> 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
> https://lkml.org/lkml/2013/1/17/623, 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/