lkml.org 
[lkml]   [2024]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Chromium sandbox on LoongArch and statx -- seccomp deep argument inspection again?
    On Mon, Feb 26, 2024 at 02:46:49PM +0100, Arnd Bergmann wrote:
    > On Mon, Feb 26, 2024, at 14:32, Christian Brauner wrote:
    > > On Mon, Feb 26, 2024 at 10:20:23AM +0100, Arnd Bergmann wrote:
    > >> On Mon, Feb 26, 2024, at 08:09, Xi Ruoyao wrote:
    > >
    > > What this tells me without knowing the exact reason is that they thought
    > > "Oh, if we just return ENOSYS then the workload or glibc will just
    > > always be able to fallback to fstat() or fstatat()". Which ultimately is
    > > the exact same thing that containers often assume.
    > >
    > > So really, just skipping on various system calls isn't going to work.
    > > You can't just implement new system calls and forget about the rest
    > > unless you know exactly what workloads your architecure will run on.
    > >
    > > Please implement fstat() or fstatat() and stop inventing hacks for
    > > statx() to make weird sandboxing rules work, please.
    >
    > Do you mean we should add fstat64_time64() for all architectures
    > then? Would use use the same structure layout as statx for this,
    > the 64-bit version of the 'struct stat' layout from
    > include/uapi/asm-generic/stat.h, or something new that solves
    > the same problems?
    >
    > 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.

    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.

    And fwiw, once mseal() lands seccomp should be a lot easier to get deep
    argument inspection.

    \
     
     \ /
      Last update: 2024-05-27 15:22    [W:5.112 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site