Re: Redzone overwritten with CONFIG_SECURITY

[Vegard Nossum]

Hello!

On Tue, May 27, 2008 at 4:00 PM, Eric Sesterhenn <snakebyte@xxxxxx> wrote:
> hi,
>
> i tested a kmemcheck kernel as an attempt to debug
> this further... seems CONFIG_SECURITY is unrelated to
> this, but slub debugging only catches the
> overwrite it if i enable CONFIG_SECURITY.

Oy, whow! :-)

I actually tried to reproduce your problem yesterday to see if
kmemcheck would catch it, but I couldn't reproduce it, so I gave up
:-(

>
> with slub_debug=FZPU i get the warning at
> init_object+0x63:
>
> (gdb) l *(init_object+0x63)
> 0xc0187243 is in init_object (mm/slub.c:544).
> 539     {
> 540             u8 *p = object;
> 541
> 542             if (s->flags & __OBJECT_POISON) {
> 543                     memset(p, POISON_FREE, s->objsize - 1);
> 544                     p[s->objsize - 1] = POISON_END;
> 545             }
> 546
> 547             if (s->flags & SLAB_RED_ZONE)
> 548                     memset(p + s->objsize,
>

This is sort of expected. kmemcheck is not directly incompatible with
slub debugging, but it may produce some false positives (that we
haven't worked out yet). So I recommend that you turn slub debugging
off, like you did below.

> if i set slub_debug=- i get the kmemcheck warning at
>
> (gdb) l *(__slab_alloc+0x238)
> 0xc0187bc8 is in __slab_alloc (mm/slub.c:303).
> 298             return *(void **)(object + s->offset);
> 299     }
> 300
> 301     static inline void set_freepointer(struct kmem_cache *s, void
> *object, void *fp)
> 302     {
> 303             *(void **)(object + s->offset) = fp;
> 304     }
> 305
> 306     /* Loop over all objects in a slab */
> 307     #define for_each_object(__p, __s, __addr, __objects) \

Hm, yes. It would be nice to see the actual kmemcheck error message as
well in order to determine the cause of this.

I don't really see how that write (= fp) can cause an error, so it has
to be the s->offset dereference that is doing it. That seems extremely
unlikely and would indicate a bug in SLUB itself...

Out of curiosity, will your crash go away entirely if you compile the
kernel using SLAB?

>
> I used the kmemcheck git tree from
> git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-kmemcheck-4.git
>
> In case you need some of the other kmemcheck output please
> let me know.
>

It would be nice to see the whole dmesg if you can get it.

You should also make sure you have either

CONFIG_KMEMCHECK_ENABLED_BY_DEFAULT=y

set in your config or that you are booting with the kmemcheck=1
command-line option; otherwise, you'll only get the first warning
before kmemcheck auto-disables itself. Forcing it to stay on will
potentially give us more useful output.

There is actually a newer kmemcheck tree which supports
kmemcheck+SLAB, but the version you are running should be usable for
debugging your problem, so I'm not going to ask you to try that.

Thanks for trying it out, it would feel good if kmemcheck would
finally be useful for something :-) Good luck.


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 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/