linux-kernel - Re: [PATCH] shmem: add support for user extended attributes

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 21 Aug 2023 10:52:41 -0700 (PDT)
From:   Hugh Dickins <hughd@...gle.com>
To:     Christian Brauner <brauner@...nel.org>
cc:     Franklin “Snaipe” Mathieu 
        <snaipe@...sta.com>, Hugh Dickins <hughd@...gle.com>,
        ovt@...gle.com, corbet@....net, akpm@...ux-foundation.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [PATCH] shmem: add support for user extended attributes

On Tue, 15 Aug 2023, Christian Brauner wrote:
> On Tue, Aug 15, 2023 at 09:46:22AM +0200, Franklin “Snaipe” Mathieu wrote:
> > 
> > So, it's likely that there's some more work to do in that area; I'd
> > certainly expect the OOM killer to take the overall memory footprint
> > of mount namespaces into account when selecting which processes to
> > kill. It's also possible my experiment was flawed and not
> > representative of a real-life scenario, as I clearly have interacted
> > with misbehaving containers before, which got killed when they wrote
> > too much to tmpfs. But then again, my experiment also didn't take
> > memory cgroups into account.
> 
> So mount namespaces are orthogonal to that and they would be the wrong
> layer to handle this.
> 
> Note that an unprivileged user (regular or via containers) on the system
> can just exhaust all memory in various ways. Ultimately the container or
> user would likely be taken down by in-kernel OOM or systemd-oomd or
> similar tools under memory pressure.
> 
> Of course, all that means is that untrusted workloads need to have
> cgroup memory limits. That also limits tmpfs instances and prevents
> unprivileged user from using all memory.
> 
> If you don't set a memory limit then yes, the container might be able to
> exhaust all memory but that's a bug in the container runtime. Also, at
> some point the OOM killer or related userspace tools will select the
> container init process for termination at which point all the namespaces
> and mounts go away. That's probably what you experience as misbehaving
> containers. The real bug there is probably that they're allowed to run
> without memory limits in the first place.

Thanks, this was a good reminder that I very much needed to look back at
the memory cgroup limiting of xattrs on tmpfs - I'd had the patch in the
original series, then was alarmed to find shmem_alloc_inode() using
GFP_KERNEL, so there seemed no point in accounting the xattrs if the
inodes were not being accounted: so dropped it temporarily.  I had
forgotten that SLAB_ACCOUNT on the kmem_cache ensures that accounting.

"tmpfs,xattr: GFP_KERNEL_ACCOUNT for simple xattrs" just sent to fix it:
https://lore.kernel.org/linux-fsdevel/f6953e5a-4183-8314-38f2-40be60998615@google.com/

Thanks,
Hugh