Tests for Andrew's talloc security work

[Jeremy Allison]

On Sat, Sep 05, 2015 at 08:08:42AM +1200, Andrew Bartlett wrote:
> On Fri, 2015-09-04 at 11:18 -0700, Jeremy Allison wrote:
> 
> > Adding the above global static
> > breaks that - so it's an ABI
> > breakage IMHO.
> > 
> > Now in common use this variable
> > is only read, not written, and
> > only initialized once in a constructor
> > attribute when the library is loaded,
> > so this may mitigate the problem.
> 
> That is indeed the design pattern.  If you are concerned that the
> library can reasonably be initialised twice then the second patch using
> 'rand()' could be skipped or re-written to use the sum of the version
> numbers, and therefore get an always-constant result. 
> 
> The variable could be declared as sig_atomic_t but per 
> https://www.gnu.org/software/libc/manual/html_node/Atomic-Types.html in
> t is essentially safe.
> 
> > But I'd need to check that running
> > existing talloc + threaded programs under
> > valgrind hellgrind and drd to ensure
> > we don't get any error messages before
> > I can be convinced this is safe.
> 
> We would very much appreciate if you could do that.  How do you think
> this would happen?  

I personally can't see how, but that's why I run
hellgrind and drd on all my threaded code :-). I
don't trust myself when working on mt-code.

Remember:

http://bholley.net/blog/2015/must-be-this-tall-to-write-multi-threaded-code.html

So yeah, I'll take the time to do these tests
with the talloc-mt-test code I added recently.

Might be next week before I can get to this
though. If you don't hear anything by the end
of next week, bug me again :-).

Thanks,

	Jeremy.