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

Message-ID: <y0m8v38jj62.fsf@fche.csb>
Date:	Tue, 21 May 2013 14:13:09 -0400
From:	fche@...hat.com (Frank Ch. Eigler)
To:	"zhangwei(Jovi)" <jovi.zhangwei@...wei.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [ANNOUNCE] ktap 0.1 released

"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.

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).

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.

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?

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.

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.

> = 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?

- 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/