|
|
Message-ID: <20240910120937.GW10433@brightrain.aerifal.cx>
Date: Tue, 10 Sep 2024 08:09:38 -0400
From: Rich Felker <dalias@...c.org>
To: Xing Li <lixing@...ngson.cn>
Cc: musl@...ts.openwall.com, wanghongliang@...ngson.cn
Subject: Re: [PATCH] loongarch64: add fstat and newfstatat syscall
support
On Tue, Sep 10, 2024 at 05:41:12PM +0800, Xing Li wrote:
> linux kernel add fstat and newfstatat to solve the chromium sandbox, the link as follow:
> https://lore.kernel.org/loongarch/CAAhV-H7W-Ygn6tXySrip4k3P5xVbVf7GpjOzjXfQvCCbA4r5Wg@mail.gmail.com/T/#t
>
> So we add fstat and newfstatat as linux kernel.
> ---
> arch/loongarch64/bits/syscall.h.in | 2 ++
> arch/loongarch64/kstat.h | 21 +++++++++++++++++++++
> 2 files changed, 23 insertions(+)
> create mode 100644 arch/loongarch64/kstat.h
>
> diff --git a/arch/loongarch64/bits/syscall.h.in b/arch/loongarch64/bits/syscall.h.in
> index 2afb4ea1..43efb916 100644
> --- a/arch/loongarch64/bits/syscall.h.in
> +++ b/arch/loongarch64/bits/syscall.h.in
> @@ -76,6 +76,8 @@
> #define __NR_splice 76
> #define __NR_tee 77
> #define __NR_readlinkat 78
> +#define __NR_newfstatat 79
> +#define __NR_fstat 80
> #define __NR_sync 81
> #define __NR_fsync 82
> #define __NR_fdatasync 83
> diff --git a/arch/loongarch64/kstat.h b/arch/loongarch64/kstat.h
> new file mode 100644
> index 00000000..92625f36
> --- /dev/null
> +++ b/arch/loongarch64/kstat.h
> @@ -0,0 +1,21 @@
> +struct kstat {
> + dev_t st_dev;
> + ino_t st_ino;
> + mode_t st_mode;
> + nlink_t st_nlink;
> + uid_t st_uid;
> + gid_t st_gid;
> + dev_t st_rdev;
> + unsigned long __pad;
> + off_t st_size;
> + blksize_t st_blksize;
> + int __pad2;
> + blkcnt_t st_blocks;
> + long st_atime_sec;
> + long st_atime_nsec;
> + long st_mtime_sec;
> + long st_mtime_nsec;
> + long st_ctime_sec;
> + long st_ctime_nsec;
> + unsigned __unused[2];
> +};
> --
> 2.27.0
This can't be accepted as-is because it breaks execution of new
binaries on old kernels that lack the syscalls. We don't have a
fallback order that tries statx is legacy stat fails with ENOSYS.
I also don't think this was a good solution to the problem. The same
problem exists on riscv32 and any future 32-bit archs where legacy
stat syscalls can't be added (because they're time32-only). statx
should have just been updated to avoid the need to peek at memory to
do effective seccomp with it (e.g. by accepting a null pointer for the
empty path part).
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.