linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Xi Ruoyao <xry111@xry111.site>
To: Christian Brauner <brauner@kernel.org>, Arnd Bergmann <arnd@arndb.de>
Cc: Icenowy Zheng <uwu@icenowy.me>,
	Huacai Chen <chenhuacai@kernel.org>,
	 WANG Xuerui <kernel@xen0n.name>,
	linux-api@vger.kernel.org, Kees Cook <keescook@chromium.org>,
	Xuefeng Li <lixuefeng@loongson.cn>,
	Jianmin Lv <lvjianmin@loongson.cn>,
	Xiaotian Wu <wuxiaotian@loongson.cn>,
	WANG Rui <wangrui@loongson.cn>,
	Miao Wang <shankerwangmiao@gmail.com>,
	"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
	Linux-Arch <linux-arch@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Chromium sandbox on LoongArch and statx -- seccomp deep argument inspection again?
Date: Tue, 27 Feb 2024 00:49:51 +0800	[thread overview]
Message-ID: <8e5e31daa3b76dc80ff5ec6ad46191bfd87f7df7.camel@xry111.site> (raw)
In-Reply-To: <20240226-sandbank-bewerben-219120323e29@brauner>

On Mon, 2024-02-26 at 16:40 +0100, Christian Brauner wrote:

> > I definitely don't want to see a new time32 API added to
> > mips64 and the 32-bit architectures, so the existing stat64
> > interface won't work as a statx replacement.
> 
> I don't specifically care but the same way you don't want to see newer
> time32 apis added to architectures I don't want to have hacks in our
> system calls that aren't even a clear solution to the problem outlined
> in this thread.

So we should have a fstat_whatever64, IMO.

> Short of adding fstatx() the problem isn't solved by a new flag to
> statx() as explained in my other mails. But I'm probably missing
> something here because I find this notion of "design system calls for
> seccomp and the Chromium sandbox" to be an absurd notion and it makes me
> a bit impatient.

I'm sharing the feeling on seccomp and/or (mis)uses of it, but using
statx() or fstatat() for fstat() has a performance impact as they must
inspect path (do a uaccess) and make sure it's an empty string, and
Linus concluded "if the user want fstat, you should give the user fstat"
for this issue:

https://sourceware.org/pipermail/libc-alpha/2023-September/151365.html

If it was just seccomp I'd not comment on this topic at all.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

  reply	other threads:[~2024-02-26 16:50 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-21  6:09 Chromium sandbox on LoongArch and statx -- seccomp deep argument inspection again? WANG Xuerui
2024-02-21  6:31 ` Xi Ruoyao
2024-02-21 10:31   ` Xi Ruoyao
2024-02-21 10:49     ` WANG Xuerui
2024-02-21 12:03       ` Xi Ruoyao
2024-02-24 11:51 ` Huacai Chen
2024-02-25  6:51   ` Icenowy Zheng
2024-02-25  7:32     ` Xi Ruoyao
2024-02-26  6:03       ` Icenowy Zheng
2024-02-26  6:56         ` Arnd Bergmann
2024-02-26  7:09           ` Xi Ruoyao
2024-02-26  9:20             ` Arnd Bergmann
2024-02-26 11:57               ` Xi Ruoyao
2024-02-26 12:57                 ` Christian Brauner
2024-02-26 14:33                   ` Rich Felker
2024-02-26 13:32               ` Christian Brauner
2024-02-26 13:46                 ` Arnd Bergmann
2024-02-26 15:40                   ` Christian Brauner
2024-02-26 16:49                     ` Xi Ruoyao [this message]
2024-02-26 13:46                 ` Christian Brauner
2024-02-26 14:00                 ` WANG Xuerui
2024-02-26 15:35                   ` Christian Brauner
2024-02-26 17:38                     ` WANG Xuerui
2024-02-26  8:26         ` Christian Brauner

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=8e5e31daa3b76dc80ff5ec6ad46191bfd87f7df7.camel@xry111.site \
    --to=xry111@xry111.site \
    --cc=arnd@arndb.de \
    --cc=brauner@kernel.org \
    --cc=chenhuacai@kernel.org \
    --cc=keescook@chromium.org \
    --cc=kernel@xen0n.name \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lixuefeng@loongson.cn \
    --cc=loongarch@lists.linux.dev \
    --cc=lvjianmin@loongson.cn \
    --cc=shankerwangmiao@gmail.com \
    --cc=uwu@icenowy.me \
    --cc=wangrui@loongson.cn \
    --cc=wuxiaotian@loongson.cn \
    /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;
as well as URLs for NNTP newsgroup(s).