linux-kernel - Re: lib/test_overflow.c causes WARNING and tainted kernel

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: <97c4b023-06fe-2ec3-86c4-bfdb5505bf6d@rasmusvillemoes.dk>
Date:   Mon, 27 May 2019 09:53:33 +0200
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Randy Dunlap <rdunlap@...radead.org>,
        Kees Cook <keescook@...omium.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Matthew Wilcox <willy@...radead.org>,
        Linux MM <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: lib/test_overflow.c causes WARNING and tainted kernel

On 25/05/2019 17.33, Randy Dunlap wrote:
> On 3/13/19 7:53 PM, Kees Cook wrote:
>> Hi!
>>
>> On Wed, Mar 13, 2019 at 2:29 PM Randy Dunlap <rdunlap@...radead.org> wrote:
>>>
>>> This is v5.0-11053-gebc551f2b8f9, MAR-12 around 4:00pm PT.
>>>
>>> In the first test_kmalloc() in test_overflow_allocation():
>>>
>>> [54375.073895] test_overflow: ok: (s64)(0 << 63) == 0
>>> [54375.074228] WARNING: CPU: 2 PID: 5462 at ../mm/page_alloc.c:4584 __alloc_pages_nodemask+0x33f/0x540
>>> [...]
>>> [54375.079236] ---[ end trace 754acb68d8d1a1cb ]---
>>> [54375.079313] test_overflow: kmalloc detected saturation
>>
>> Yup! This is expected and operating as intended: it is exercising the
>> allocator's detection of insane allocation sizes. :)
>>
>> If we want to make it less noisy, perhaps we could add a global flag
>> the allocators could check before doing their WARNs?
>>
>> -Kees
> 
> I didn't like that global flag idea.  I also don't like the kernel becoming
> tainted by this test.

Me neither. Can't we pass __GFP_NOWARN from the testcases, perhaps with
a module parameter to opt-in to not pass that flag? That way one can
make the overflow module built-in (and thus run at boot) without
automatically tainting the kernel.

The vmalloc cases do not take gfp_t, would they still cause a warning?

BTW, I noticed that the 'wrap to 8K' depends on 64 bit and
pagesize==4096; for 32 bit the result is 20K, while if the pagesize is
64K one gets 128K and 512K for 32/64 bit size_t, respectively. Don't
know if that's a problem, but it's easy enough to make it independent of
pagesize (just make it 9*4096 explicitly), and if we use 5 instead of 9
it also becomes independent of sizeof(size_t) (wrapping to 16K).

Rasmus