From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32076 invoked from network); 11 May 2022 21:12:49 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 11 May 2022 21:12:49 -0000 Received: (qmail 24264 invoked by uid 550); 11 May 2022 21:12:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 24232 invoked from network); 11 May 2022 21:12:45 -0000 Date: Wed, 11 May 2022 17:12:32 -0400 From: Rich Felker To: Arnd Bergmann Cc: Christian Brauner , Huacai Chen , Huacai Chen , Andy Lutomirski , Thomas Gleixner , Peter Zijlstra , Andrew Morton , David Airlie , Jonathan Corbet , Linus Torvalds , linux-arch , "open list:DOCUMENTATION" , Linux Kernel Mailing List , Xuefeng Li , Yanteng Si , Guo Ren , Xuerui Wang , Jiaxun Yang , Linux API , GNU C Library , musl@lists.openwall.com Message-ID: <20220511211231.GG7074@brightrain.aerifal.cx> References: <20220430090518.3127980-1-chenhuacai@loongson.cn> <20220430090518.3127980-14-chenhuacai@loongson.cn> <20220507121104.7soocpgoqkvwv3gc@wittgenstein> <20220509100058.vmrgn5fkk3ayt63v@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re: [PATCH V9 13/24] LoongArch: Add system call support On Wed, May 11, 2022 at 09:11:56AM +0200, Arnd Bergmann wrote: > On Mon, May 9, 2022 at 12:00 PM Christian Brauner wrote: > ..... > > I can try and move a poc for this up the todo list. > > > > 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. > > Thank you for the detailed reply. It sounds to me like this will eventually have > to get solved anyway, so we could move ahead without clone() on loongarch, > and just not have support for Chrome until this is fully solved. > > As both the glibc and musl ports are being proposed for inclusion right > now, we should try to come to a decision so the libc ports can adjust if > necessary. Adding both mailing lists to Cc here, the discussion is archived > at [1]. > > Arnd > > [1] https://lore.kernel.org/linux-arch/20220509100058.vmrgn5fkk3ayt63v@wittgenstein/ Having read about the seccomp issue, I think it's a very strong argument that __NR_clone should be kept permanently for all future archs. Otherwise, at least AIUI, it's impossible to seccomp-sandbox multithreaded programs (since you can't allow the creation of threads without also allowing other unwanted use of clone3). It sounds like there's some interest in extending seccomp to allow filtering of argument blocks like clone3 uses, but some of what I read about was checksum-based (thus a weak hardening measure at best, not a hard privilege boundary) and even if something is eventually created that works, it won't be available right away, and it won't be nearly as easy to use as just allowing thread-creating clone syscalls on existing archs. Rich