linux-kernel - Re: [RFC][PATCH] Check write to slab memory which freed already using mudflap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090710084745.GA26752@elte.hu>
Date:	Fri, 10 Jul 2009 10:47:45 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Janboe Ye <yuan-bo.ye@...orola.com>, linux-kernel@...r.kernel.org,
	vegard.nossum@...il.com, graydon@...hat.com, fche@...hat.com
Subject: Re: [RFC][PATCH] Check write to slab memory which freed already
	using mudflap


* Pekka Enberg <penberg@...helsinki.fi> wrote:

> Hi Janboe,
> 
> On Thu, Jul 9, 2009 at 7:13 PM, Janboe Ye<yuan-bo.ye@...orola.com> wrote:
> > slab debug detects the corruption when it allocates and frees the slab. But if someone write to slab memory when it already freed, slab debug could only report its last free point when slab allocates the same block.
> >
> > This information is not enough for debugging when system has complex memory usage. gcc mudflap could insert some check point when a memory is writing and it is helpful to check if the address is writing freed.
> >
> > Because most codes of kernel are drivers, it is most possible that drivers have such problem. So I use mudflap to compile all drivers.
> >
> > kmemcheck is also helpful to check same issue, and it triggers trap every reading and writing, and it need to analysis the instruct which trigger the trap to get the memory address.
> > This heavy depends on the cpu capability. arm has no single-step like x86, so kmemcheck is too heavy to run on real arm system. mudflap way is lighter than kmemcheck for this purpose.
> >
> > As stack allocation is useless for checking slab, kernel mudflap does not implement alloc which is required by gcc mudflap when codes use variable array. So variable array, such as array[i] which i could not determined by compiler, is not supported.
> >
> > Thanks a lot for comments!
> 
> Yeah, something like this makes sense. Some comments below.
> 
> >  arch/arm/include/asm/elf.h |    1 +
> >  arch/arm/kernel/module.c   |    1 +
> >  drivers/Makefile           |    4 +-
> >  include/mf-runtime.h       |   42 ++++++++++++++
> >  kernel/Makefile            |    2 +-
> >  kernel/mudflap.c           |  132 ++++++++++++++++++++++++++++++++++++++++++++
> >  lib/Kconfig.debug          |    7 ++
> >  mm/slab.c                  |   53 ++++++++++++++++++
> >  8 files changed, 240 insertions(+), 2 deletions(-)
> 
> SLAB is (slowly) going away so you might want to port this to SLUB 
> as well so we can merge both.

and SLQB which will replace both? :-/

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/