linux-kernel - Re: WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (f6f6e1a4), by kmemleak's scan

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:	Tue, 25 Aug 2009 10:25:40 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Vegard Nossum <vegard.nossum@...il.com>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: WARNING: kmemcheck: Caught 32-bit read from uninitialized
	memory  (f6f6e1a4), by kmemleak's scan_block()

On Tue, 2009-08-25 at 12:15 +0300, Pekka Enberg wrote:
> On Tue, 2009-08-25 at 10:11 +0100, Catalin Marinas wrote:
> > Yes, that's possible.
> > 
> > Does kmemcheck work on a page-range basis. If an object doesn't cross
> > page boundaries, would it be considered fully initialised after writing
> > a single location?
> > 
> > > I think it would be better to ask kmemcheck on a per-pointer basis
> > > (i.e. for each pointer-sized word in the object), whether it is
> > > initialized or not.
> > 
> > This should work but how expensive is this check?
> 
> Everything in kmemcheck is expensive :-). kmemcheck_shadow_lookup()
> needs to do PTE lookup to find the shadow page where we record object
> states. I'm not sure why that's a problem, though. If you've enabled
> kmemcheck, everything is already dead slow and kmemleak scanning happens
> in background, no? 

It happens in background but the scan_block() function is called, in
most cases, with interrupts disabled and a spinlock held (to avoid the
object being freed during scanning). In my kmemleak branch, queued for
the next merging window, there are patches to allow rescheduling during
object scanning (by releasing the lock temporarily), so it shouldn't be
a problem.

-- 
Catalin

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