linux-kernel - Re: Possible deny of service with memfd

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

Message-ID: <YB05iR9fkaDDll9Y@dhcp22.suse.cz>
Date:   Fri, 5 Feb 2021 13:26:49 +0100
From:   Michal Hocko <mhocko@...e.com>
To:     Christian König <christian.koenig@....com>
Cc:     Hugh Dickins <hughd@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Possible deny of service with memfd_create()

On Fri 05-02-21 11:57:09, Christian König wrote:
> Am 05.02.21 um 11:50 schrieb Michal Hocko:
> > On Fri 05-02-21 08:54:31, Christian König wrote:
> > > Am 05.02.21 um 01:32 schrieb Hugh Dickins:
> > > > On Thu, 4 Feb 2021, Michal Hocko wrote:
[...]
> > > > > The only existing protection right now is to use memoery cgroup
> > > > > controller because the tmpfs memory is accounted to the process which
> > > > > faults the memory in (or write to the file).
> > > Agreed, but having to rely on cgroup is not really satisfying when you have
> > > to maintain a hardened server.
> > Yes I do recognize the pain. The only other way to mitigate the risk is
> > to disallow the syscall to untrusted users in a hardened environment.
> > You should be very strict in tmpfs usage there already.
> > 
> 
> Well it is perfectly valid for a process to use as much memory as it wants,
> the problem is that we are not holding the process accountable for it.
> 
> As I said we have similar problems with GPU drivers and I think we just need
> a way to do this.
> 
> Let me think about it a bit, maybe we can somehow use the file owner for
> this.

There are some land mines on the way to watch for. The most obvious one
would be to not double account populated file with its mapping. Those
two might live in separate processes. So you would need a rmap walk just
to evaluate oom_badness. Also you need to consider files which are not
open anymore or they have been passed through to another process. And
then the question is what to do about them. Killing their owner doesn't
help anything because the file is still left behind.  I do expect you
will learn more problems on the way but I definitely do not want to
discourage you from this endeavor.
-- 
Michal Hocko
SUSE Labs