On Mon, Jul 21, 2008 at 10:05 PM, Ingo Molnar <mingo@elte.hu> wrote:
quoted text
>
> * Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
>
>> It could be an interesting kmemcheck extension to catch not only
>> non-initialized memory, but also writes into just freed one, but not
>> yet returned by allocator to the next user.
>
> hm, i think kmemcheck does that mostly already. If not then I think
> kmemcheck should just turn off all buffering that might happen on the
> SLUB level (if it doesnt do it already). I.e. a kfree()d buffer should
> be marked as uninitialized immediately.

We don't catch writes (yet, because kmemcheck gets confused by SLUB's
own writes so far), but yes, we mark objects "freed" when they are
freed (until the slab page is returned to the page allocator) and we
may detect reads from this area before the object is reallocated. In
that case, a "read from freed memory" message will appear.

Unfortunately, it doesn't work quite as well as I'd like it to yet. We
did catch one real bug in ACPI in this way (read-after-free). But as I
have discovered, not all machines support single-stepping over REP
STOS instructions properly. Which means that kmemcheck breaks silently
on some machines. There's also the recent DMA patch, which might
improve things. Linus is right, it's really fragile. But we are
working on it. It is going in the right direction anyway.

(Pekka and I were also working on an extension to SLUB which delays
the freeing of objects, i.e. so that objects will remain in the
"freed" state for a certain amount of time before it can be allocated
again. But we don't really have a _good_ patch for this yet, it was
more like an ugly hack at the time.)


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html