linux-kernel - Re: [RFC] kmemcheck: trap uses of uninitialized memory (v2)

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: <19f34abd0711290204m6d23957o9b31b1d527c07694@mail.gmail.com>
Date:	Thu, 29 Nov 2007 11:04:04 +0100
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Pekka J Enberg" <penberg@...helsinki.fi>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC] kmemcheck: trap uses of uninitialized memory (v2)

On Nov 29, 2007 10:39 AM, Pekka J Enberg <penberg@...helsinki.fi> wrote:
> Hi,
>
> On Nov 29, 2007 9:02 AM, Pekka Enberg <penberg@...helsinki.fi> wrote:
> > > Is it really necessary to track every memory address? Tracking slab
> > > objects would require far less memory. You might also want to make
> > > kzalloc() and GFP_ZERO mark the memory area as initialized to avoid
> > > some page faults.
>
> On Thu, 29 Nov 2007, Vegard Nossum wrote:
> > Yes, we are in fact only tracking the memory within SLUB allocations
> > (minus what SLUB itself needs for bookkeeping -- like the caches).
>
> Yeah but you didn't answer my question: why do we track every memory
> address instead of slab objects? What's the benefit? Like I already said,
> tracking slab objects would require much less memory which makes the
> thing more practical. It also reduces the number of false positives (the
> CONFIG_OPTIMIZE_FOR_SIZE problem). And we already have slab poisoning to
> cover the cases we would not catch with this scheme.

If I understand you correctly, you only want to be notified if any
memory within an allocation is used before any memory within the
allocation has been initialized. I think that this would be quite
useless compared to tracking all the bytes of an allocation. I am not
truly concerned about the memory usage; this kind of error detection
is by definition slow and memory intense. I think that slab poisoning
is in a way more subtle, since it does not immediately produce a
warning on its own; what it does is really to invoke *other* error
catching mechanisms. Slab poisoning works best with pointers since
pointers will be dereferenced. What about other kinds of data? The
kernel will not complain (loudly enough, anyway) if your bit-field
contains some arbitrary unexpected value. Kmemcheck will immediately
print a message to the log in this case.

> On Thu, 29 Nov 2007, Vegard Nossum wrote:
> > As for the kzalloc() and GFP_ZERO, I believe these will write zeros to
> > the data in question before the memory is returned to the caller. In
> > that case, the area will be "automatically" set to initialized since
> > these writes are also intercepted by kmemcheck.
>
> Yes, and what I proposed is as a potential optimization. Debugging aids
> need to be fast enough to be practical.

Yep, I didn't realize. Thanks. :-)

>
>                         Pekka
>

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