linux-kernel - Re: kmemcheck: got WARNING when dynamicly adjust /proc/sys/kernel/kmemcheck to 0/1

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: <536CA79B.5010505@oracle.com>
Date:	Fri, 09 May 2014 12:02:03 +0200
From:	Vegard Nossum <vegard.nossum@...cle.com>
To:	Xishi Qiu <qiuxishi@...wei.com>
CC:	Pekka Enberg <penberg@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	David Rientjes <rientjes@...gle.com>,
	Vegard Nossum <vegard.nossum@...il.com>,
	Linux MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: kmemcheck: got WARNING when dynamicly adjust /proc/sys/kernel/kmemcheck
 to 0/1

On 05/09/2014 11:52 AM, Xishi Qiu wrote:
> On 2014/5/9 15:57, Xishi Qiu wrote:
>
>> OS boot with kmemcheck=0, then set 1, do something, set 0, do something, set 1...
>> then I got the WARNING log. Does kmemcheck support dynamicly adjust?
>>
>> Thanks,
>> Xishi Qiu
>>
>> [   20.200305] igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
>> [   20.208652] ADDRCONF(NETDEV_UP): eth0: link is not ready
>> [   20.216504] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>> [   22.647385] auditd (3116): /proc/3116/oom_adj is deprecated, please use /proc/3116/oom_score_adj instead.
>> [   24.845214] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
>> [   30.434764] eth0: no IPv6 routers present
>> [  340.154608] NOHZ: local_softirq_pending 01
>> [  340.154639] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff88083f43a550)
>> [  340.154644] c000000002000000000000000000000080ff5d0100c9ffff400ed34e0888ffff
>> [  340.154667]  u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u
>> [  340.154687]                                  ^
>> [  340.154690]
>> [  340.154694] Pid: 3, comm: ksoftirqd/0 Tainted: G         C   3.4.24-qiuxishi.19-0.1-default+ #2 Huawei Technologies Co., Ltd. Tecal RH2285 V2-24S/BC11SRSC1
>> [  340.154702] RIP: 0010:[<ffffffff81217d72>]  [<ffffffff81217d72>] d_namespace_path+0x132/0x270
>> [  340.154714] RSP: 0018:ffff8808515a1c88  EFLAGS: 00010202
>> [  340.154718] RAX: ffff88083f43a540 RBX: ffff880852e718f3 RCX: 0000000000000001
>> [  340.154721] RDX: ffff8808515a1d28 RSI: 0000000000000000 RDI: ffff881053855a60
>> [  340.154725] RBP: ffff8808515a1ce8 R08: ffff8808515a1c50 R09: ffff880852e75800
>> [  340.154728] R10: 00000000000156f0 R11: 0000000000000000 R12: 0000000000000001
>> [  340.154731] R13: 0000000000000100 R14: ffff880852e71510 R15: ffff880852e71800
>> [  340.154736] FS:  0000000000000000(0000) GS:ffff88085f600000(0000) knlGS:0000000000000000
>> [  340.154740] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [  340.154743] CR2: ffff880852e71570 CR3: 00000008513f2000 CR4: 00000000000407f0
>> [  340.154746] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [  340.154750] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
>> [  340.154753]  [<ffffffff81217f35>] aa_path_name+0x85/0x180
>> [  340.154758]  [<ffffffff812187d6>] apparmor_bprm_set_creds+0x126/0x520
>> [  340.154763]  [<ffffffff811f60ae>] security_bprm_set_creds+0xe/0x10
>> [  340.154771]  [<ffffffff81170d65>] prepare_binprm+0xa5/0x100
>> [  340.154777]  [<ffffffff811716c2>] do_execve_common+0x232/0x430
>> [  340.154781]  [<ffffffff8117194a>] do_execve+0x3a/0x40
>> [  340.154785]  [<ffffffff8100abb9>] sys_execve+0x49/0x70
>> [  340.154793]  [<ffffffff814764bc>] stub_execve+0x6c/0xc0
>> [  340.154801]  [<ffffffffffffffff>] 0xffffffffffffffff
>> [  340.154813] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff88083f43a570)
>> [  340.154817] 746f70000300000078a5433f0888fffff86d433f0888ffff746f700000730000
>> [  340.154839]  u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u
>> [  340.154858]                                  ^
>> [  340.154861]
>> [  340.154864] Pid: 3, comm: ksoftirqd/0 Tainted: G         C   3.4.24-qiuxishi.19-0.1-default+ #2 Huawei Technologies Co., Ltd. Tecal RH2285 V2-24S/BC11SRSC1
>> [  340.154871] RIP: 0010:[<ffffffff811691f4>]  [<ffffffff811691f4>] rw_verify_area+0x24/0x100
>> [  340.154880] RSP: 0018:ffff8808515a1dc8  EFLAGS: 00010202
>> [  340.154883] RAX: ffff88083f43a540 RBX: 0000000000000080 RCX: 0000000000000080
>> [  340.154887] RDX: ffff8808515a1e30 RSI: ffff880852e71500 RDI: 0000000000000000
>> [  340.154890] RBP: ffff8808515a1de8 R08: ffff880852e73200 R09: ffff88085f004900
>> [  340.154894] R10: ffff880852e72600 R11: 0000000000000000 R12: ffff880852e71500
>> [  340.154897] R13: 0000000000000000 R14: ffff880852e73200 R15: 0000000000000001
>> [  340.154901] FS:  0000000000000000(0000) GS:ffff88085f600000(0000) knlGS:0000000000000000
>> [  340.154905] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [  340.154908] CR2: ffff880852e71570 CR3: 00000008513f2000 CR4: 00000000000407f0
>> [  340.154911] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [  340.154914] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
>> [  340.154917]  [<ffffffff811698f4>] vfs_read+0xa4/0x130
>> [  340.154922]  [<ffffffff81170ca4>] kernel_read+0x44/0x60
>> [  340.154926]  [<ffffffff81170d90>] prepare_binprm+0xd0/0x100
>> [  340.154931]  [<ffffffff811716c2>] do_execve_common+0x232/0x430
>> [  340.154935]  [<ffffffff8117194a>] do_execve+0x3a/0x40
>> [  340.154939]  [<ffffffff8100abb9>] sys_execve+0x49/0x70
>> [  340.154944]  [<ffffffff814764bc>] stub_execve+0x6c/0xc0
>> [  340.154950]  [<ffffffffffffffff>] 0xffffffffffffffff
>> [  340.154955] WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (ffff88083f43a540)
>> [  340.154959] c000000002000000000000000000000080ff5d0100c9ffff400ed34e0888ffff
>> [  340.154981]  u u u u u u u u u u u u u u u u i i i i i i i i u u u u u u u u
>> [  340.155000]  ^
>>
>>
>
> Another problem, does there some way will initialize the shadow?
> I only find the object has been initialized.
>
> kmemcheck_slab_alloc()
> 	...
> 	/*
> 	 * Has already been memset(), which initializes the shadow for us
> 	 * as well.
> 	 */
> 	if (gfpflags & __GFP_ZERO)
> 		return;  ----> add kmemcheck_mark_initialized() ?
> 	...
>
> slab:
> 	slab_alloc()
> 	...
> 	if (likely(objp))
> 		kmemcheck_slab_alloc(cachep, flags, objp, cachep->object_size);
>
> 	if (unlikely((flags & __GFP_ZERO) && objp))
> 		memset(objp, 0, cachep->object_size);
>
> 	return objp;
>
> slub:
> 	slab_alloc_node()
> 	...
> 	if (unlikely(gfpflags & __GFP_ZERO) && object)
> 		memset(object, 0, s->object_size);
>
> 	slab_post_alloc_hook(s, gfpflags, object);
>
> 	return object;
>
> The shadow memory which used for slab/slub is called from kmemcheck_alloc_shadow(),
> and it will initialized *only* in kmemcheck_slab_alloc(), right?
>

If you enable kmemcheck at run-time, there is no way to know what 
already-allocated objects have been initialised or not, so we assume 
that they have been. In that case, there is also very little point in 
allocating shadow memory for them, since it will all be marked as 
"initialised" anyway (one exception is if we later memcpy() 
uninitialised memory into them, but that seems like it would be a pretty 
rare occurrence).

The use case for toggling kmemcheck at run-time is to check a particular 
piece of code (enable it, run a program/system call/insert a 
module/whatever, disable it -- this will basically check memory 
allocated while kmemcheck is enabled, but not memory allocated before or 
after).

So to answer your original question, yes, toggling kmemcheck at run-time 
is supported, but there is an increased chance of false negatives (we 
don't spot a problem where there is one). About false positives (we spot 
a problem where there isn't one), I don't think runtime toggling should 
make a difference.


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/