linux-kernel - Re: [PATCH 15/28] ktap: add built-in functions and library (runtime/lib

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: <20140331131353.GH22728@two.firstfloor.org>
Date:	Mon, 31 Mar 2014 15:13:53 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Jovi Zhangwei <jovi.zhangwei@...il.com>
Cc:	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH 15/28] ktap: add built-in functions and library
 (runtime/lib_*.c)

On Mon, Mar 31, 2014 at 10:01:04AM +0800, Jovi Zhangwei wrote:
> On Sun, Mar 30, 2014 at 8:58 AM, Andi Kleen <andi@...stfloor.org> wrote:
> >> Maybe in future, after ktap support "include" or "require" to
> >> import user defined library in userspace.
> >
> > Can't you just have some hardcoded standard script for now that is
> > always appeneded and provides these functions?
> >
> Maybe it's fine to hardcoded just for now.
> 
> Since we are agreed on review userspace part in another schedule,
> so I will remove this ansi library from kernel part in next version.
> 
> Thanks for this suggestion.

Please do the following for the next version:

- Don't repost with all the TODOs regarding changing other
kernel parts. Just fix them.

- As others pointed out elsewhere it's too big and full featured right
now. Please find ways to define a useful "core ktap" for now with less
features. This could be dropping library parts or dropping some of the
probe types or some parts of the language. These can then be later phased
in over time. For the library it may make sense to add some module
interface and keep parts of it external for now?

- Please run as much test content as you have with all the kernel debug
options to automatically find bugs. I would at least two runs one with
lockdep/lock debugging/preempt debugging/slab/page debugging etc.
and another with kmemleak (that is exclusive with some other options)
Some of these checks may have false positives, but the messages
should be all analyzed at least, and false positives commented.

- Do similar with the static compile time checks: checkpatch,
sparse, coccinelle. There will be likely a lot more false positives
here, so it may not be feasible to check all, but should at least
eyeball the output to see if there are some obvious problems.
For sparse it would be also good to annotate the user ioctl 
parts with __user and carefully look at the warnings there,
as that is a common problem area.

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