From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [IPv6:2001:19f0:5:42::1]) by sourceware.org (Postfix) with ESMTPS id 1CBBA3858C66 for ; Wed, 7 Feb 2024 20:58:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1CBBA3858C66 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=aerifal.cx ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1CBBA3858C66 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:19f0:5:42::1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707339537; cv=none; b=feIkjT9euIwUSbCacM+f3wAO8FJRKNn9MwspbSAvXxYGzmwScsxU+WwJEFt3MVsxkd6aX9+bLxMHTdnrC3LNqJ1wJvHltGfn7Pd57jj9l7mddFNGXGH7ojXz4/5k2hq9DpGvmT2TpjLsyIkHUoBbwKFiNMYaBcRZRT3cYucoyxM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707339537; c=relaxed/simple; bh=poomE6CjV6tWFJxeCUVhW2Qqjpj/49/3GER4Iufcyos=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=A5tdmj3grwJgxmm7NlE0FrlXun2wstGA9QItqHCGq163QMwErPVKKRYztWkAhGBJpn7MxBfQ9wjn5FiIk4sqg+lRi3QiYvxqoHAgvCSiVljosO3UIaRZyKO7nkAi6XlkWanIxWG+7QUE/hSHx6DI0AsoPyYOeLtJWJsVIVuv9+M= ARC-Authentication-Results: i=1; server2.sourceware.org Date: Wed, 7 Feb 2024 15:59:09 -0500 From: dalias To: Askar Safin Cc: Adhemerval Zanella Netto , libc-alpha , carlos Subject: Re: [PATCH, RFC] Add public function syscall_no_errno Message-ID: <20240207205908.GJ22081@brightrain.aerifal.cx> References: <20240128163958.17421-1-safinaskar@zohomail.com> <380959fd-3414-4fc6-ae3f-85abdee2a9a0@linaro.org> <18d6628ba70.12a99fe2719939.4022957090731865688@zohomail.com> <20240201201638.GG22081@brightrain.aerifal.cx> <18d81141715.113eab5157547.6554800058266941170@zohomail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18d81141715.113eab5157547.6554800058266941170@zohomail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Feb 07, 2024 at 04:59:54AM +0400, Askar Safin wrote: > Hi, Rich and Adhemerval! > > ---- On Fri, 02 Feb 2024 00:16:26 +0400 dalias wrote --- > > OK, but this falls under "poking around behind libc's back". > > Function "syscall" exists in glibc. So it is assumed to be useful. > Thus it is okay to have "syscall_no_errno", too. "syscall" in > its current form has a problem: you cannot correctly call > SYS_getuid32. Thus there is need for "syscall_no_errno". > > So I will write next version of my patch. I hope in several days, > when I have time. > "syscall_no_errno" will be simple wrapper for "INTERNAL_SYSCALL_NCS_CALL". > > > Well that's not something syscall() gives you and it's not something > > syscall_no_errno() would reliably give you either unless it was > > specifically documented to be callable from such a context. If that's > > what you want, maybe that's what should be discussed. > > I did some research. I have read all places where glibc calls "clone". > And I see that in all these places if CLONE_VM specified, then > CLONE_SETTLS or CLONE_VFORK is specified. > > In fact, there is 2 places only, where glibc calls clone (in Linux x86_64). > > One is implementation of pthread_create. We pass CLONE_VM and > CLONE_SETTLS. Thus (as well as I understand) TLS is set up > in child right from the beginning. > There is no time gap, when TLS is not initialized yet. > > Second place is implementation of posix_spawn. We pass CLONE_VM > and CLONE_VFORK. CLONE_VFORK means that parent is suspended, > and thus it is okay to access its TLS. > > Thus glibc absolutely always (even internally!) maintains invariant > "TLS is safe to access". I. e. glibc itself does not need a way to perform > syscalls when TLS is not set up. You're missing the point. Of course glibc maintains that invariant because it's providing a consistent platform to applications. If you have application code that uses clone() itself, it may not be meeting those invariants necessary to be able to call into libc. > In fact my original use case is so: I want to parse true kernel ABI > from files /sys/kernel/debug/tracing/events/syscalls/sys_enter_*/format > and then generate a library based on the ABI. > > Such library will provide syscall wrappers with correct types. These > wrappers will call functions "syscall" and "syscall_no_errno". > > (In fact, this will be Rust library, not C one, but I don't think > this is important for our discussion. You may say: "Then why > you want to add syscall_no_errno to upstream glibc?" > Well, because I want it to be available to everyone. To Rust > programmers, to C programmers and to everyone else. > Without the need to write assembly.) > > So, I will read proper kernel ABI from /sys/kernel/..., so > I will get ABI right. Can you clarify *why* you want to do that? Making raw syscalls like this is ill-advised and *will* run into mismatched ABI for certain types (where the kernel and user types differ), poor compatibility with kernel versions that aren't the same you expected, time64 issues on 32-bit archs, etc. Based on our conversations in this thread, I do not think you're prepared to handle all that right. It most certainly cannot be handled in an automated way by parsing the data you have in mind; doing it right requires knowing semantic relationships between syscalls. It sounds like you plan to hand Rust programmers a big footgun. Rich