linux-kernel - Re: [uml-devel] [PATCH 2/6] UML: Don't valgrind userspace

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:	Sat, 06 Sep 2008 13:55:34 -0700
From:	John Reiser <jreiser@...Wagon.com>
To:	Jeff Dike <jdike@...toit.com>
CC:	Steve VanDeBogart <vandebo-lkml@...dBox.Net>, jiayingz@...gle.com,
	linux-kernel@...r.kernel.org,
	user-mode-linux-devel@...ts.sourceforge.net, dkegel@...gle.com
Subject: Re: [uml-devel] [PATCH 2/6] UML: Don't valgrind userspace

Jeff Dike wrote:
> On Fri, Aug 29, 2008 at 04:15:24PM -0700, Steve VanDeBogart wrote:
>> Add a flag to tell Valgrind to run the forked child natively.  Necessary
>> because Valgrind makes additional system calls to instrumented processes,
>> which confuse UML.
> 
>> +#ifdef UML_CONFIG_VALGRIND_SUPPORT
>> +		flags |= VALGRIND_CLONE_LETGO;
>> +#endif
>> +	}
> 
> I keep forgetting that I have a really bad feeling about this:
> 
> +#define VALGRIND_CLONE_LETGO   0x80000000      /* do not track fork like childr
> en*/
> 
> This is effectively appropriating part of the kernel's ABI for
> valgrind's use.  

UML is part of the kernel, so getting a memory reference checker (valgrind)
running in UML is part of the kernel, too.  The concept of "escape from the
virtualizer" eventually occurs to more than just memory reference checkers.

> Not to mention that that bit is already taken:
> 
> #define CLONE_IO		0x80000000	/* Clone io context */

It wasn't taken a few months ago when the valgrind patches for UML were
first proposed.  The list of free bits in that flag word is now empty.
There may be some overlap of concept with CLONE_UNTRACED, which might
be used temporarily while figuring out an alternative.

> 
> Could you do this with an annotation that says "let the next clone run
> untraced"?

Why wouldn't that be a race between the next _NR_clone from this thread
and the next _NR_clone from any other existing thread [in the same process]?

Valgrind can pre-pend a block of code at the start of the new thread,
but almost immediately that code will want to "unvirtualize."
Doing so at _NR_clone itself is convenient all around.

-- 
John Reiser, jreiser@...Wagon.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/