On Fri 01-09-23 14:55:17, Alexander Potapenko wrote: > On Fri, Sep 1, 2023 at 12:29 PM Zhaoyang Huang <huangzhaoyang@xxxxxxxxx> wrote: > > > > loop alex > > (adding more people who took part in the previous discussions) > > > > > On Thu, Aug 31, 2023 at 8:16 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > > > > On Thu, Aug 31, 2023 at 06:52:52PM +0800, zhaoyang.huang wrote: > > > > From: Zhaoyang Huang <zhaoyang.huang@xxxxxxxxxx> > > > > > > > > There is no explicit gfp flags to let the allocation skip zero > > > > operation when CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y. I would like to make > > > > __GFP_SKIP_ZERO be visible even if kasan is not configured. > > Hi all, > > This is a recurring question, as people keep encountering performance > problems on systems with init_on_alloc=1 > (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1862822 being > one of the examples). > > Brad Spengler has also pointed out > (https://twitter.com/spendergrsec/status/1296461651659694082) that > there are cases where there is no security vs. performance tradeoff > (e.g. kmemdup() and kstrdup()). > > An opt-out flag was included in the initial init_on_alloc series, but > back then Michal Hocko has noted that it might easily get out of > control: https://patchwork.kernel.org/project/linux-hardening/patch/20190418154208.131118-2-glider@xxxxxxxxxx/#22600229. I still maintain my opinion. I really do not like the idea of mixing concepts of init_on_alloc (which is pretty much security oriented) and an opt out flag which bypasses it. Sooner or later this will become an unreviewable mess so the value of init_on_alloc will become very dubious. > Now that init_on_alloc is actually being used by people which may have > different preferences wrt. security and performance (in the cases > where this tradeoff exists), we must be very careful with the opt-out > GFP flag. Not initializing a particular allocation site in the > upstream kernel will affect every downstream user, and some may > consider this a security regression. Fully agreed! > Another problematic case is an OS vendor mandating init_on_alloc > everywhere, but a third party driver vendor doing kmalloc(..., > __GFP_SKIP_ZERO) for their allocations. Exactly. This allows to sniff into driver unrelated proper and allow a whole class of isssues. > So I think a working opt-out scheme for the heap initialization should > be two-step: > 1. The code owner may decide that a particular allocation site needs > an opt-out, and make the upstream code change; > 2. The OS vendor has the ability to override that decision for the > kernel they ship without the need to patch the source. Practically speaking this would require a new mode init_on_alloc_but_potentially_unsafe Another option would be to provide a simple page allocator wrapper that would allow to recycle pages for a particular user or providing a slab cache that would achieve the same thing. This would be still a bit quetiongable because the user could be seeing stale data but less of a problem than crossing propers and potentially security domains. -- Michal Hocko SUSE Labs
