linux-kernel - Re: [PATCH] Provide ways of crashing the kernel through debugfs

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]

Date:	Tue, 2 Feb 2010 09:16:57 +0100
From:	Simon Kagstrom <simon.kagstrom@...insight.net>
To:	ebiederm@...ssion.com (Eric W. Biederman)
Cc:	Andrew Morton <akpm@...ux-foundation.org>, dedekind1@...il.com,
	Américo Wang <xiyou.wangcong@...il.com>,
	linux-kernel@...r.kernel.org,
	David Woodhouse <dwmw2@...radead.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] Provide ways of crashing the kernel through debugfs

On Mon, 01 Feb 2010 20:16:46 -0800
ebiederm@...ssion.com (Eric W. Biederman) wrote:

> Andrew Morton <akpm@...ux-foundation.org> writes:

> > Yes, it's the sort of thing which lots of people have written
> > throw-away ad-hoc versions of.  It probably makes sense to do it once,
> > do it right to save people from having to rererereinvent that wheel.
> >
> > What do others think?
> 
> I think it makes sense, and in fact we have already merged one attempt
> at doing this generically.  drivers/misc/lkdtm.c

So this functionality was already there - it would appear that I didn't do my
research good enough then (I did actually look for this kind of thing).
If something, I guess it shows that the kernel source is getting big!

To add to the irony, I work for a company that works on "DTM", although
it's not related to this functionality :-)

> I think Simon's patch adds some additional interesting failure modes.
> write_after_free, corrupt_stack_write, unaligned_load_store.
> 
> Simon is there any chance you can change your patch to an enhancement of lkdtm?
> 
> lkdtm actually digs into the interesting failure points with a jprobe
> to trigger the harder to reproduce scenarios.  Like stack overflow in
> an interrupt handler.

Yes, this would be a better way of supporting the crash functionality.
I'll take a look on integrating the extra tests into lkdtm.

I think it would also be good to provide a debugfs interface to lkdtm
similar to what provoke-crash has. Right now you have to set it up via
module parameters, and for some tests (write_after_free) I think that's
a limitation since it often doesn't crash immediately.

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