From: Yafang Shao <laoar.shao@gmail.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
akpm@linux-foundation.org, paul@paul-moore.com,
jmorris@namei.org, serge@hallyn.com, linux-mm@kvack.org,
linux-security-module@vger.kernel.org, bpf@vger.kernel.org,
ligang.bdlg@bytedance.com
Subject: Re: [RFC PATCH -mm 0/4] mm, security, bpf: Fine-grained control over memory policy adjustments with lsm bpf
Date: Tue, 14 Nov 2023 19:59:53 +0800 [thread overview]
Message-ID: <CALOAHbDi_8ERHdtPB6sJdv=qewoAfGkheCfriW+QLoN0rLUQAw@mail.gmail.com> (raw)
In-Reply-To: <ZVNIprbQU3NqwPi_@tiehlicka>
On Tue, Nov 14, 2023 at 6:15 PM Michal Hocko <mhocko@suse.com> wrote:
>
> On Mon 13-11-23 11:15:06, Yafang Shao wrote:
> > On Mon, Nov 13, 2023 at 12:45 AM Casey Schaufler <casey@schaufler-ca.com> wrote:
> > >
> > > On 11/11/2023 11:34 PM, Yafang Shao wrote:
> > > > Background
> > > > ==========
> > > >
> > > > In our containerized environment, we've identified unexpected OOM events
> > > > where the OOM-killer terminates tasks despite having ample free memory.
> > > > This anomaly is traced back to tasks within a container using mbind(2) to
> > > > bind memory to a specific NUMA node. When the allocated memory on this node
> > > > is exhausted, the OOM-killer, prioritizing tasks based on oom_score,
> > > > indiscriminately kills tasks. This becomes more critical with guaranteed
> > > > tasks (oom_score_adj: -998) aggravating the issue.
> > >
> > > Is there some reason why you can't fix the callers of mbind(2)?
> > > This looks like an user space configuration error rather than a
> > > system security issue.
> >
> > It appears my initial description may have caused confusion. In this
> > scenario, the caller is an unprivileged user lacking any capabilities.
> > While a privileged user, such as root, experiencing this issue might
> > indicate a user space configuration error, the concerning aspect is
> > the potential for an unprivileged user to disrupt the system easily.
> > If this is perceived as a misconfiguration, the question arises: What
> > is the correct configuration to prevent an unprivileged user from
> > utilizing mbind(2)?"
>
> How is this any different than a non NUMA (mbind) situation?
In a UMA system, each gigabyte of memory carries the same cost.
Conversely, in a NUMA architecture, opting to confine processes within
a specific NUMA node incurs additional costs. In the worst-case
scenario, if all containers opt to bind their memory exclusively to
specific nodes, it will result in significant memory wastage.
> You can
> still have an unprivileged user to allocate just until the OOM triggers
> and disrupt other workload consuming more memory. Sure the mempolicy
> based OOM is less precise and it might select a victim with only a small
> consumption on a target NUMA node but fundamentally the situation is
> very similar. I do not think disallowing mbind specifically is solving a
> real problem.
How would you recommend addressing this more effectively?
--
Regards
Yafang
next prev parent reply other threads:[~2023-11-14 12:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20231112073424.4216-1-laoar.shao@gmail.com>
2023-11-12 16:45 ` Casey Schaufler
2023-11-13 3:15 ` Yafang Shao
2023-11-13 8:50 ` Ondrej Mosnacek
2023-11-13 21:23 ` Casey Schaufler
2023-11-14 2:30 ` Yafang Shao
2023-11-14 10:15 ` Michal Hocko
2023-11-14 11:59 ` Yafang Shao [this message]
2023-11-14 16:57 ` Casey Schaufler
2023-11-15 1:52 ` Yafang Shao
2023-11-15 8:45 ` Michal Hocko
2023-11-15 9:33 ` Yafang Shao
2023-11-15 14:26 ` Yafang Shao
2023-11-15 17:09 ` Casey Schaufler
2023-11-16 1:41 ` Yafang Shao
2023-11-15 17:00 ` Michal Hocko
2023-11-16 2:22 ` Yafang Shao
2023-11-12 20:32 ` Paul Moore
2023-11-13 3:17 ` Yafang Shao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALOAHbDi_8ERHdtPB6sJdv=qewoAfGkheCfriW+QLoN0rLUQAw@mail.gmail.com' \
--to=laoar.shao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bpf@vger.kernel.org \
--cc=casey@schaufler-ca.com \
--cc=jmorris@namei.org \
--cc=ligang.bdlg@bytedance.com \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mhocko@suse.com \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox