linux-hardening - Re: [PATCH v3 0/4] mm: clarify nofail memory allocation

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-next>] [day] [month] [year] [list]

Message-ID: <2663352f-ecef-4e5b-bee5-e31d2b286c63@suse.cz>
Date: Thu, 29 Aug 2024 12:24:49 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Barry Song <21cnbao@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
 David Hildenbrand <david@...hat.com>, Michal Hocko <mhocko@...e.com>,
 Yafang Shao <laoar.shao@...il.com>, akpm@...ux-foundation.org,
 linux-mm@...ck.org, 42.hyeyoo@...il.com, cl@...ux.com, hailong.liu@...o.com,
 hch@...radead.org, iamjoonsoo.kim@....com, penberg@...nel.org,
 rientjes@...gle.com, roman.gushchin@...ux.dev, urezki@...il.com,
 v-songbaohua@...o.com, virtualization@...ts.linux.dev,
 "linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>
Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation

On 8/27/24 09:50, Barry Song wrote:
> On Tue, Aug 27, 2024 at 7:38 PM Vlastimil Babka <vbabka@...e.cz> wrote:
>>
>>
>> Ugh, wasn't aware, well spotted. So it means there at least shouldn't be
>> existing users of __GFP_NOFAIL with order > 1 :)
>>
>> But also the check is in the hotpath, even before trying the pcplists, so we
>> could move it to __alloc_pages_slowpath() while extending it?
> 
> Agreed. I don't think it is reasonable to check the order and flags in
> two different places especially rmqueue() has already had
> gfp_flags & __GFP_NOFAIL operation and order > 1
> overhead.
> 
> We can at least extend the current check to make some improvement
> though I still believe Michal's suggestion of implementing OOPS_ON is a
> better approach to pursue, as it doesn't crash the entire system
> while ensuring the problematic process is terminated.

Linus made clear it's not a mm concern. If e.g. hardening people want to
pursuit that instead, they can.

BTW I think BUG_ON already works like this, if possible only the calling
process is terminated. panic happens in case of being in a irq context, or
due to panic_on_oops. Which the security people are setting to 1 anyway and
OOPS_ON would have to observe it too. So AFAICS the only difference from
BUG_ON would be not panic in the irq context, if panic_on_oops isn't set.
(as for "no mm locks held" I think it's already satisfied at the points we
check for __GFP_NOFAIL).