linux-kernel - Re: [2.6.35-rc6 patch] increase kmemleak robustness at boot

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: <AANLkTik-M_=G4Ks=U6hRm1dBTzbzovR47jdhjTjNqekX@mail.gmail.com>
Date:	Thu, 29 Jul 2010 13:48:06 +0100
From:	Daniel J Blueman <daniel.blueman@...il.com>
To:	Catalin Marinas <catalin.marinas@...il.com>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [2.6.35-rc6 patch] increase kmemleak robustness at boot

On 29 July 2010 12:34, Catalin Marinas <catalin.marinas@...il.com> wrote:
> On 28 July 2010 17:49, Pekka Enberg <penberg@...helsinki.fi> wrote:
>> Daniel J Blueman wrote:
>>>
>>> I've consistently been experiencing kmemleak exhaust it's 400-entry
>>> early-boot buffer and disabling itself; there have been reports of
>>> this also, and I'm finding this on x86-64 with various debug options
>>> enabled.
>>>
>>> If we issue a warning and allow the buffer to wrap, we don't need to
>>> hit the kill-switch. While we lose track of some early potential
>>> leaks, it's better than no functionality.
>>>
>>> Let me know if it's acceptable, and many thanks for such an excellent
>>> tool,
>>
>> Is it just potential leaks that we lose or can this cause false positives?
>
> I wouldn't go this route, it's a great source of false positives.
> Given that it's not always easy to investigate a memory leak, adding
> more false positives would just make people turn the tool off. There
> are several things in place like crc checking and maybe that's why
> Daniel doesn't get false positives but that's not always the case.
>
> I would rather change the static early alloc buffer with something
> like bootmem allocation (the recursiveness should be bound, kmemleak
> tracks bootmem allocations as well). But I'm on holiday until middle
> of August and not able to do any tests in this area.

Indeed, moving to dynamic early allocation is all the more better. For
now, I'll increase the early allocation to 15200 elements, as the
400-entry buffer wraps 38.

Thanks again,
  Daniel
-- 
Daniel J Blueman
--
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/