Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 5 Feb 2021 13:26:49 +0100
From:   Michal Hocko <mhocko@suse.com>
To:     Christian =?iso-8859-1?Q?K=F6nig?= <christian.koenig@amd.com>
Cc:     Hugh Dickins <hughd@google.com>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: Possible deny of service with memfd_create()
Message-ID: <YB05iR9fkaDDll9Y@dhcp22.suse.cz>
References: <e7e6231d-8cf9-80a6-7459-5fec9ee547ba@amd.com>
 <YBwrGNS+Q4JMpuom@dhcp22.suse.cz>
 <alpine.LSU.2.11.2102041627040.2796@eggly.anvils>
 <762ad377-ac21-6d8d-d792-492ba7f6c000@amd.com>
 <YB0i3a6fIhWG7zCP@dhcp22.suse.cz>
 <3597e38e-ace7-104c-dcc8-59471e11dcfe@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3597e38e-ace7-104c-dcc8-59471e11dcfe@amd.com>
Precedence: bulk

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