Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Florian Weimer <fweimer@redhat.com>
To:     Christian Brauner <brauner@kernel.org>
Cc:     Arnd Bergmann <arnd@arndb.de>, Huacai Chen <chenhuacai@gmail.com>,
        Huacai Chen <chenhuacai@loongson.cn>,
        Andy Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <peterz@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        David Airlie <airlied@linux.ie>,
        Jonathan Corbet <corbet@lwn.net>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        linux-arch <linux-arch@vger.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Xuefeng Li <lixuefeng@loongson.cn>,
        Yanteng Si <siyanteng@loongson.cn>,
        Guo Ren <guoren@kernel.org>, Xuerui Wang <kernel@xen0n.name>,
        Jiaxun Yang <jiaxun.yang@flygoat.com>,
        Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH V9 13/24] LoongArch: Add system call support
References: <20220430090518.3127980-1-chenhuacai@loongson.cn>
        <20220430090518.3127980-14-chenhuacai@loongson.cn>
        <CAK8P3a0A9dW4mwJ6JHDiJxizL7vWfr4r4c5KhbjtAY0sWbZJVA@mail.gmail.com>
        <CAAhV-H4te_+AS69viO4eBz=abBUm5oQ6AfoY1Cb+nOCZyyeMdA@mail.gmail.com>
        <CAK8P3a0DqQcApv8aa2dgBS5At=tEkN7cnaskoUeXDi2-Bu9Rnw@mail.gmail.com>
        <20220507121104.7soocpgoqkvwv3gc@wittgenstein>
        <20220509100058.vmrgn5fkk3ayt63v@wittgenstein>
Date:   Wed, 11 May 2022 18:17:09 +0200
In-Reply-To: <20220509100058.vmrgn5fkk3ayt63v@wittgenstein> (Christian
        Brauner's message of "Mon, 9 May 2022 12:00:58 +0200")
Message-ID: <87bkw4doxm.fsf@oldenburg.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

* Christian Brauner:

> Without an approach like this certain sandboxes will fallback to
> ENOSYSing system calls they can't filter. This is a generic problem
> though with clone3() being one promiment example.

Furthermore, for glibc (and I believe musl as well), the trick with
in-process emulation of clone3 using SIGSYS does not work here because
we must inhibit delivery of signals on the nascent thread, before it is
fully set up.  This means that we have to block signals around the
clone/clone3 system call, so that the new thread is created with all
signals blocked.  This means that instead of calling the SIGSYS handler,
the filtered system call simply terminates the process.

(I think there have been discussions of using out-of-process filtering,
but I don't know where we are with that.)

Thanks,
Florian