[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAADnVQLo0z9OOr6QOwU_+2480DaK8HT+Nu=OcMDG-PDptk44Zg@mail.gmail.com>
Date: Mon, 30 Dec 2024 11:23:57 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Daniel Xu <dxu@...uu.xyz>
Cc: Alexei Starovoitov <ast@...nel.org>, Andrii Nakryiko <andrii@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>, Eddy Z <eddyz87@...il.com>,
Martin KaFai Lau <martin.lau@...ux.dev>, Song Liu <song@...nel.org>,
Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>,
Jiri Olsa <jolsa@...nel.org>, bpf <bpf@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH bpf-next] libbpf: Set MFD_NOEXEC_SEAL when creating memfd
On Sun, Dec 29, 2024 at 1:44 PM Daniel Xu <dxu@...uu.xyz> wrote:
>
> Since 105ff5339f49 ("mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC"), the
> kernel has started printing a warning if neither MFD_NOEXEC_SEAL nor
> MFD_EXEC is set in memfd_create().
Except that the code is different now:
if (!(*flags & (MFD_EXEC | MFD_NOEXEC_SEAL))) {
if (sysctl >= MEMFD_NOEXEC_SCOPE_NOEXEC_SEAL)
*flags |= MFD_NOEXEC_SEAL;
else
*flags |= MFD_EXEC;
}
if (!(*flags & MFD_NOEXEC_SEAL) && sysctl >=
MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED) {
pr_err_ratelimited(
"%s[%d]: memfd_create() requires
MFD_NOEXEC_SEAL with vm.memfd_noexec=%d\n",
current->comm, task_pid_nr(current), sysctl);
return -EACCES;
}
Since libbpf doesn't specify either the EXEC or NOEXEC will be
applied automatically depending on the value of sysctl vm.memfd_noexec.
And it will warn only if EXEC flag is used with sysctl == 2.
So the patch helps libbpf avoid the warn on somewhat old kernels,
but not strictly necessary on the new kernels.
This patch is relevant too:
commit 202e14222fad ("memfd: do not -EACCES old memfd_create() users
with vm.memfd_noexec=2")
It has Fixes tag and it should have been backported
to the "somewhat old kernels".
So if the kernel backport process was perfect there would be no kernels
at all where current libbbpf code would cause a warn.
Pls add these details to the commit log and respin.
bpf-next is fine. This isn't really a must-have fix for libbpf,
more nice-to-have behavior.
Powered by blists - more mailing lists