linux-kernel - Re: [PATCH] mm: make __GFP_SKIP_ZERO visible to skip zero operation

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: <ZPWNTiAxZZh/kzew@dhcp22.suse.cz>
Date:   Mon, 4 Sep 2023 09:54:54 +0200
From:   Michal Hocko <mhocko@...e.com>
To:     Alexander Potapenko <glider@...gle.com>
Cc:     Zhaoyang Huang <huangzhaoyang@...il.com>,
        Matthew Wilcox <willy@...radead.org>,
        "zhaoyang.huang" <zhaoyang.huang@...soc.com>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, ke.wang@...soc.com,
        Marco Elver <elver@...gle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Kees Cook <keescook@...omium.org>,
        Eric Biggers <ebiggers@...nel.org>,
        Mateusz Guzik <mjguzik@...il.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH] mm: make __GFP_SKIP_ZERO visible to skip zero operation

On Fri 01-09-23 14:55:17, Alexander Potapenko wrote:
> On Fri, Sep 1, 2023 at 12:29 PM Zhaoyang Huang <huangzhaoyang@...il.com> 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@...radead.org> wrote:
> > >
> > > On Thu, Aug 31, 2023 at 06:52:52PM +0800, zhaoyang.huang wrote:
> > > > From: Zhaoyang Huang <zhaoyang.huang@...soc.com>
> > > >
> > > > 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@google.com/#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