> On Wed, Jul 03, 2013 at 17:21, Theo de Raadt wrote:
> >> +       int pval = 0xd0d0caca;
> > 
> > Can you explain the choice of this?
>> 
> I thought it sounded clever.

Ok, because there's more to the picture.

Inside the kernel, we tend to use 0xdeadbeef, or the DEADBEEF0/DEADBEEF1 values.

Reason for the latter is that we can try to put this value into memory
which the kernel does not manage.  Basically on half of our kernel
architectures if that is loaded into a pointer, it will hit unmanaged
kernel memory, exposing the bug.

Furthermore, the idea is that the 0xdeadbeef value should have a high
mix of set bits versus clear bits, for when it lands in a flag
variable.  A lot of bits are set; some paper I read years ago
discussed that on average "flag bits set" tends to traverse.

Furthermore, each of the sub-fields tend to be odd, which in other
use after cases regarding offsets/indexes can lead to more unaligned
access, once again triggering and exposing a bug.

Those are all theoretical ideas to try to expose the bugs as early
as possible.

I think the use of 0xd0d0caca in userland might not be the most
suitable choice, especially in a MI fashion.

> > There are arguments to make this MI; other arguments to make it MD;
> > and other arguments to introduce a bit of randomness.
> > 
> > I'd like to know which arguments you have
> 
> Since libc doesn't do free list integrity checking, I'm currently
> leaning towards a random value. (even with random, we could still
> check that all words of a free chunk are the same.)
> 
> Somebody also noticed that we don't have separate values for allocated
> and freed memory. I suppose this makes debugging harder since you
> can't obviously identify freed memory? I lean towards prioritizing
> finding more bugs, which implies we need more variability, since any
> one value may allow a program to work where a different value would
> not.

I agree with this last sentence.

I suspect the best approach would be a hybrid value.  The upper half
of the address should try to land in an unmapped zone, or into the zero
page, or into some address space hole, ir into super high memory above
the stack which is gauranteed unmapped.

The 64-bit machines require a bit more consideration as well; we want
two 32-bit values to combine into a nice trashy address.

Should we use a kernel sysctl to "recommend" the high word?, and a mask
against random?  Of course, that could also be done using MD includes.

 

Reply via email to