linux-kernel - Re: Valgrinding the kernel?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070706172513.GD10670@c2.user-mode-linux.org>
Date:	Fri, 6 Jul 2007 13:25:13 -0400
From:	Jeff Dike <jdike@...toit.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Dan Kegel <dank@...el.com>, linux-kernel@...r.kernel.org,
	Robert Walsh <rjwalsh@...ables.org>
Subject: Re: Valgrinding the kernel?

On Thu, Jul 05, 2007 at 10:44:05PM -0700, Jeremy Fitzhardinge wrote:
> Dan Kegel wrote:
> >It'd be nice to see if Valgrind could catch uninitialized
> >references in the kernel, if only to see if Coverity is
> >missing anything that happens in practice.
> >
> >Back in December 2002, Valgrind started to run UML:
> >http://user-mode-linux.sourceforge.net/diary.html
> >http://marc.info/?l=linux-kernel&m=104035199923121&w=2
> >but it wasn't quite usable, and it seems broken since then.
> >The last note I could find about this was from Jeff In July 2005:
> >http://marc.info/?l=linux-kernel&m=112273702329952&w=2

I've checked since 2005, and valgrind was still horribly broken wrt UML.

> Not that I know of.  I think all the pieces are in place now.  The 
> original problem was that Valgrind didn't deal with clone and didn't 
> have accurate signal support.  I fixed that.  Then the problem was 
> dealing with the densely packed small kernel stacks.  Valgrind now has a 
> way of registering stack regions, so that it can distinguish between a 
> stack switch and a normal function call.
> 
> So, I think all it needs now is to scatter some valgrind client requests 
> around the kernel and give it a spin.  See, simple ;)

Don't think so.  With what I get on FC5 (valgrind-3.1.0), I get this:

==31913== Jump to the invalid address stated on the next line
==31913==    at 0x9: ???
==31913==    by 0xBEC1599A: ???
==31913==    by 0x696C2F69: ???
==31913==  Address 0x9 is not stack'd, malloc'd or (recently) free'd
==31913== 
==31913== Process terminating with default action of signal 11 (SIGSEGV): dumping core

UML is cloning a thread in order to test the host's ptrace.  However,
it looks like valgrind is branching to 0x9 for some reason.

This particular bit is going to be problematic for other reasons, but
if valgrind ever looks like it has a chance of working, I can work
around that in UML.

				Jeff

-- 
Work email - jdike at linux dot intel dot com
-
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/