linux-kernel - Re: [PATCH 4/4] kmemcheck v4

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] [day] [month] [year] [list]

Message-ID: <19f34abd0802151118k142439e9nc47ea1f7a359fe0f@mail.gmail.com>
Date:	Fri, 15 Feb 2008 20:18:54 +0100
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Andi Kleen" <andi@...stfloor.org>
Cc:	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Daniel Walker" <dwalker@...sta.com>,
	"Ingo Molnar" <mingo@...e.hu>,
	"Richard Knutsson" <ricknu-0@...dent.ltu.se>,
	"Pekka Enberg" <penberg@...helsinki.fi>,
	"Christoph Lameter" <clameter@....com>
Subject: Re: [PATCH 4/4] kmemcheck v4

On Thu, Feb 14, 2008 at 10:49 PM, Andi Kleen <andi@...stfloor.org> wrote:
>  The ifdefs are quite ugly. I would recommend to define standard
>  functions (kmemcheck_init_zero or similar and an own __GFP flag) that can
>  be used without ifdef and easily nop'ed out on !KMEMCHECK kernels.

Yes, they are. We do in fact have a flag for this purpose,
__GFP_NOTRACK (or SLAB_NOTRACK for entire slab caches). I have now
changed some of the hunks to use this method instead of ifdefs. Thanks
for pointing this out.

Also note that this patch is not meant to be a part of kmemcheck
itself; it simply silences some of the (some bogus) warnings.
Preferably, each one of these call-sites should be carefully audited
and "fixed" independently of kmemcheck itself. In fact, the patch
should probably be split, one for the bogus warnings (where the
bogus-warning fixes are no-ops if kmemcheck is disabled), and the real
errors in their own patches.

There is currently a huge problem with bit-fields. When bit-fields are
initialized, gcc may use the AND/OR instructions to initialize one
field at a time (depending on what the C code looks like, of course).
This is seen by kmemcheck as 1. full 8/16/32-bit read 2. full
8/16/32-bit write. Therefore the first initialization of (access to) a
bit-field variable will generally cause a warning from kmemcheck. And
this is perfectly legal from the compiler point of view.

Ingo's approach so far has been to initialize all the bit-field
variables at once. This is probably what the author of the original
code wants to do anyway, though not in all cases. I admit that I am
not confident enough with kernel code myself to decide what the
appropriate fix would be in most cases of kmemcheck warnings.
Therefore, take this last patch with a grain of salt (for now).

Thank you.

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/