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

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

[Randy Dunlap]

On 3/13/19 7:53 PM, Kees Cook wrote:
> Hi!
> 
> On Wed, Mar 13, 2019 at 2:29 PM Randy Dunlap <rdunlap@infradead.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.

Would it make sense to change the WARN_ON_ONCE() to a call to warn_alloc()
instead?  or use a plain raw printk_once()?

warn_alloc() does the _NOWARN check and does rate limiting.


--- lnx-51-rc2.orig/mm/page_alloc.c
+++ lnx-51-rc2/mm/page_alloc.c
@@ -4581,7 +4581,8 @@ __alloc_pages_nodemask(gfp_t gfp_mask, u
 	 * so bail out early if the request is out of bound.
 	 */
 	if (unlikely(order >= MAX_ORDER)) {
-		WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN));
+		warn_alloc(gfp_mask, NULL,
+				"page allocation failure: order:%u", order);
 		return NULL;
 	}
 


-- 
~Randy

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

[Rasmus Villemoes]

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@infradead.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

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

[Kees Cook]

On Mon, May 27, 2019 at 09:53:33AM +0200, Rasmus Villemoes wrote:
> 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@infradead.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?

They still warn, but they don't seem to taint. I.e. this patch:

diff --git a/lib/test_overflow.c b/lib/test_overflow.c
index fc680562d8b6..c922f0d86181 100644
--- a/lib/test_overflow.c
+++ b/lib/test_overflow.c
@@ -486,11 +486,12 @@ static int __init test_overflow_shift(void)
  * Deal with the various forms of allocator arguments. See comments above
  * the DEFINE_TEST_ALLOC() instances for mapping of the "bits".
  */
-#define alloc010(alloc, arg, sz) alloc(sz, GFP_KERNEL)
-#define alloc011(alloc, arg, sz) alloc(sz, GFP_KERNEL, NUMA_NO_NODE)
+#define alloc_GFP	(GFP_KERNEL | __GFP_NOWARN)
+#define alloc010(alloc, arg, sz) alloc(sz, alloc_GFP)
+#define alloc011(alloc, arg, sz) alloc(sz, alloc_GFP, NUMA_NO_NODE)
 #define alloc000(alloc, arg, sz) alloc(sz)
 #define alloc001(alloc, arg, sz) alloc(sz, NUMA_NO_NODE)
-#define alloc110(alloc, arg, sz) alloc(arg, sz, GFP_KERNEL)
+#define alloc110(alloc, arg, sz) alloc(arg, sz, alloc_GFP | __GFP_NOWARN)
 #define free0(free, arg, ptr)	 free(ptr)
 #define free1(free, arg, ptr)	 free(arg, ptr)
 
will remove the tainting behavior but is still a bit "noisy". I can't
find a way to pass __GFP_NOWARN to a vmalloc-based allocation, though.

Randy, is removing taint sufficient for you?

> 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).

Ah! Yes, all excellent points. I've adjusted that too now. I'll send
the result to Andrew.

Thanks!

-- 
Kees Cook

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

[Randy Dunlap]

On 5/28/19 3:47 PM, Kees Cook wrote:
> On Mon, May 27, 2019 at 09:53:33AM +0200, Rasmus Villemoes wrote:
>> 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@infradead.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?
> 
> They still warn, but they don't seem to taint. I.e. this patch:
> 
> diff --git a/lib/test_overflow.c b/lib/test_overflow.c
> index fc680562d8b6..c922f0d86181 100644
> --- a/lib/test_overflow.c
> +++ b/lib/test_overflow.c
> @@ -486,11 +486,12 @@ static int __init test_overflow_shift(void)
>   * Deal with the various forms of allocator arguments. See comments above
>   * the DEFINE_TEST_ALLOC() instances for mapping of the "bits".
>   */
> -#define alloc010(alloc, arg, sz) alloc(sz, GFP_KERNEL)
> -#define alloc011(alloc, arg, sz) alloc(sz, GFP_KERNEL, NUMA_NO_NODE)
> +#define alloc_GFP	(GFP_KERNEL | __GFP_NOWARN)
> +#define alloc010(alloc, arg, sz) alloc(sz, alloc_GFP)
> +#define alloc011(alloc, arg, sz) alloc(sz, alloc_GFP, NUMA_NO_NODE)
>  #define alloc000(alloc, arg, sz) alloc(sz)
>  #define alloc001(alloc, arg, sz) alloc(sz, NUMA_NO_NODE)
> -#define alloc110(alloc, arg, sz) alloc(arg, sz, GFP_KERNEL)
> +#define alloc110(alloc, arg, sz) alloc(arg, sz, alloc_GFP | __GFP_NOWARN)
>  #define free0(free, arg, ptr)	 free(ptr)
>  #define free1(free, arg, ptr)	 free(arg, ptr)
>  
> will remove the tainting behavior but is still a bit "noisy". I can't
> find a way to pass __GFP_NOWARN to a vmalloc-based allocation, though.
> 
> Randy, is removing taint sufficient for you?

Yes it is.  Thanks.

>> 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).
> 
> Ah! Yes, all excellent points. I've adjusted that too now. I'll send
> the result to Andrew.
> 
> Thanks!
> 


-- 
~Randy