Re: [patch 3/4 -mm] flex_array: poison free elements

[David Rientjes]

On Mon, 24 Aug 2009, Dave Hansen wrote:

> > diff --git a/include/linux/poison.h b/include/linux/poison.h
> > --- a/include/linux/poison.h
> > +++ b/include/linux/poison.h
> > @@ -65,6 +65,9 @@
> >  #define MUTEX_DEBUG_INIT       0x11
> >  #define MUTEX_DEBUG_FREE       0x22
> > 
> > +/********** lib/flex_array.c **********/
> > +#define FLEX_ARRAY_FREE        0x6c    /* for use-after-free poisoning */
> 
> This seems like a good idea, but perhaps we should pick a non-ASCII
> character as the poison value.  If someone ever tried to store strings
> as one-byte elements, they'd be in for a rude awakening the first time
> they store an 'l'.
> 

I wasn't aware that storing an array of ASCII characters was a use case 
for flex array, I'm having a hard type imagining such a user.  We're 
always going to have the possibility of conflict with the poison value 
just from allowing eight byte element sizes, yet that possibility is still 
going to exist if we disabled it on smaller elements and re-defined 
FLEX_ARRAY_FREE as 0x6c6c, for example; the only thing that we've done is 
eliminated the possibility of flex_array_shrink() for arrays consisting of 
smaller elements.  FLEX_ARRAY_FREE (or an additional poison value to 
distinguish between use-uninitialized vs. use-after-free) must be used in 
flex_array_clear() otherwise the cgroup patchset, the only proposed user 
of this library code, could never shrink this array when pid's are free 
like the kmalloc vs. vmalloc patchset could do.

On the other hand, I'd have no problem trying to eliminate 
fa->total_nr_elements (since we already have fa->element_size) since we 
can calculate it in real-time; the only problem is being able to 
distinguish when the elements are being stored in struct flex_array vs. 
being stored in struct flex_array_part.  We could then use that
unsigned int in struct flex_array to store the number of inuse elements 
which is an alternative implementation to flex_array_shrink(), yet I'd 
still propose to keep the poisoning to reveal use-uninitialized.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/