linux-kernel - Re: [PATCH 1/2] kmemcheck v3

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 8 Feb 2008 00:18:21 +0100
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Christoph Lameter" <clameter@....com>
Cc:	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Ingo Molnar" <mingo@...e.hu>,
	"Pekka Enberg" <penberg@...helsinki.fi>,
	"Andi Kleen" <andi@...stfloor.org>,
	"Richard Knutsson" <ricknu-0@...dent.ltu.se>
Subject: Re: [PATCH 1/2] kmemcheck v3

On Feb 7, 2008 11:53 PM, Christoph Lameter <clameter@....com> wrote:
> > Are you sure you are not confusing tracking with tracing? It's only
> > one letter different in spelling, but makes a huge difference in
> > meaning :-)
>
> No I am quite sure what tracking is since the slab allocators have their
> own tracking.
>
> But you may want to explain things better.

Ok, then I think we are still talking about different things :-)

The tracking that kmemcheck does is actually a byte-for-byte tracking
of whether memory has been initialized or not. Think of it as valgrind
for the kernel. We do this by "hiding" pages (marking them non-present
for for MMU) and taking the page faults, which effectively tells us
what memory is being attempted to be read from or written to.

(This generally means that the tracking that kmemcheck does is
page-granular, but we can help this by making entire caches tracked or
non-tracked.)

(This also means that *all* tracked memory allocations require twice
the amount of memory that was requested -- but this is luckily
configurable by disabling kmemcheck entirely :-)).

I chose to implement this in the slab layer because this is probably
where most of the interesting allocations are coming from, and this
gives us a better control over what most users/callers care about,
namely the specific objects.

In a way, kmemcheck is similar to slab poisoning, since that can also
be used to detect the cases where memory is used before it is
initialized. This is a heavier-weight approach, however, and more
precise, as it gives you the exact location of the error.

I hope this clears it up.

Kind regards,
Vegard Nossum
--
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/