From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Xi Ruoyao <xry111@xry111.site>
Cc: Huacai Chen <chenhuacai@kernel.org>,
Huacai Chen <chenhuacai@loongson.cn>,
loongarch@lists.linux.dev, Sasha Levin <sashal@kernel.org>,
stable@vger.kernel.org
Subject: Re: [PATCH for-stable] LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h
Date: Thu, 15 Aug 2024 10:22:14 +0200 [thread overview]
Message-ID: <2024081509-hurry-subsonic-466d@gregkh> (raw)
In-Reply-To: <5aa26f6b0365ebf6b7e3c5b3d1c0a345b46431d3.camel@xry111.site>
On Wed, Aug 14, 2024 at 05:18:29PM +0800, Xi Ruoyao wrote:
> On Sun, 2024-08-11 at 17:42 +0200, Greg Kroah-Hartman wrote:
> > On Wed, Jul 31, 2024 at 09:06:56AM +0800, Huacai Chen wrote:
> > > On Tue, Jul 30, 2024 at 10:24 PM Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Tue, Jul 30, 2024 at 10:25:42AM +0800, Huacai Chen wrote:
> > > > > Chromium sandbox apparently wants to deny statx [1] so it could properly
> > > > > inspect arguments after the sandboxed process later falls back to fstat.
> > > > > Because there's currently not a "fd-only" version of statx, so that the
> > > > > sandbox has no way to ensure the path argument is empty without being
> > > > > able to peek into the sandboxed process's memory. For architectures able
> > > > > to do newfstatat though, glibc falls back to newfstatat after getting
> > > > > -ENOSYS for statx, then the respective SIGSYS handler [2] takes care of
> > > > > inspecting the path argument, transforming allowed newfstatat's into
> > > > > fstat instead which is allowed and has the same type of return value.
> > > > >
> > > > > But, as LoongArch is the first architecture to not have fstat nor
> > > > > newfstatat, the LoongArch glibc does not attempt falling back at all
> > > > > when it gets -ENOSYS for statx -- and you see the problem there!
> > > > >
> > > > > Actually, back when the LoongArch port was under review, people were
> > > > > aware of the same problem with sandboxing clone3 [3], so clone was
> > > > > eventually kept. Unfortunately it seemed at that time no one had noticed
> > > > > statx, so besides restoring fstat/newfstatat to LoongArch uapi (and
> > > > > postponing the problem further), it seems inevitable that we would need
> > > > > to tackle seccomp deep argument inspection.
> > > > >
> > > > > However, this is obviously a decision that shouldn't be taken lightly,
> > > > > so we just restore fstat/newfstatat by defining __ARCH_WANT_NEW_STAT
> > > > > in unistd.h. This is the simplest solution for now, and so we hope the
> > > > > community will tackle the long-standing problem of seccomp deep argument
> > > > > inspection in the future [4][5].
> > > > >
> > > > > More infomation please reading this thread [6].
> > > > >
> > > > > [1] https://chromium-review.googlesource.com/c/chromium/src/+/2823150
> > > > > [2] https://chromium.googlesource.com/chromium/src/sandbox/+/c085b51940bd/linux/seccomp-bpf-helpers/sigsys_handlers.cc#355
> > > > > [3] https://lore.kernel.org/linux-arch/20220511211231.GG7074@brightrain.aerifal.cx/
> > > > > [4] https://lwn.net/Articles/799557/
> > > > > [5] https://lpc.events/event/4/contributions/560/attachments/397/640/deep-arg-inspection.pdf
> > > > > [6] https://lore.kernel.org/loongarch/20240226-granit-seilschaft-eccc2433014d@brauner/T/#t
> > > > >
> > > > > Cc: stable@vger.kernel.org
> > > > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > > > ---
> > > > > arch/loongarch/include/uapi/asm/unistd.h | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/arch/loongarch/include/uapi/asm/unistd.h b/arch/loongarch/include/uapi/asm/unistd.h
> > > > > index fcb668984f03..b344b1f91715 100644
> > > > > --- a/arch/loongarch/include/uapi/asm/unistd.h
> > > > > +++ b/arch/loongarch/include/uapi/asm/unistd.h
> > > > > @@ -1,4 +1,5 @@
> > > > > /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> > > > > +#define __ARCH_WANT_NEW_STAT
> > > > > #define __ARCH_WANT_SYS_CLONE
> > > > > #define __ARCH_WANT_SYS_CLONE3
> > > > >
> > > > > --
> > > > > 2.43.5
> > > > >
> > > > >
> > > >
> > > > What kernel branch(s) is this for?
> > > For 6.1~6.10.
> >
> > What is the git id of this change in Linus's tree?
>
> https://git.kernel.org/torvalds/c/7697a0fe0154
Thanks, now queued up.
greg k-h
prev parent reply other threads:[~2024-08-15 8:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-29 12:15 FAILED: patch "[PATCH] LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h" failed to apply to 6.10-stable tree gregkh
2024-07-29 14:36 ` Huacai Chen
2024-07-29 15:14 ` Greg KH
2024-07-30 2:25 ` [PATCH for-stable] LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h Huacai Chen
2024-07-30 14:24 ` Greg Kroah-Hartman
2024-07-31 1:06 ` Huacai Chen
2024-08-11 15:42 ` Greg Kroah-Hartman
2024-08-14 9:18 ` Xi Ruoyao
2024-08-15 8:22 ` Greg Kroah-Hartman [this message]
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=2024081509-hurry-subsonic-466d@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=chenhuacai@kernel.org \
--cc=chenhuacai@loongson.cn \
--cc=loongarch@lists.linux.dev \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=xry111@xry111.site \
/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