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 82722385801D for ; Thu, 1 Feb 2024 18:18:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 82722385801D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=libc.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 82722385801D 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=1706811502; cv=none; b=MhC1ndIUo9SAtZTNBfGFwSVGcvJc6GxGSRA7+mPLPE+qoY+7QeDQrKXtIyrXcVhXl3rKFmEIex3tV+tWDKWj21q4m9Fwy7ohb7YjugSD2gG9yMmVAAI2yR8RWNv0QvDUbIyBh4s+xYvPL89/z4I5Ez4axkTkF9tArdKEY4HREaA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706811502; c=relaxed/simple; bh=OTyAmc9zGskgD6pluNhEQvZrbw8oP8MamWneB0BIogU=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=Cp97v2772CaQ0MKfsziwogWZFdEosv3rfC7gsKoRsPxnwmzlmzUmaKgSK+Xi31zKwIr2KBZZNJJq7I8/yunD81Snw2m7sRs4NZGJc75f/MeNlTStTO9fgOkB4CvBO02K7/UocuLN8D59GBMR3KInc6/M6nnqJDLNjB03USJGIqI= ARC-Authentication-Results: i=1; server2.sourceware.org Date: Thu, 1 Feb 2024 13:18:35 -0500 From: Rich Felker To: Adhemerval Zanella Netto Cc: Askar Safin , libc-alpha@sourceware.org, carlos@redhat.com Subject: Re: [PATCH, RFC] Add public function syscall_no_errno Message-ID: <20240201181835.GC22081@brightrain.aerifal.cx> References: <20240128163958.17421-1-safinaskar@zohomail.com> <380959fd-3414-4fc6-ae3f-85abdee2a9a0@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <380959fd-3414-4fc6-ae3f-85abdee2a9a0@linaro.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham 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 Thu, Feb 01, 2024 at 02:53:44PM -0300, Adhemerval Zanella Netto wrote: > > > On 28/01/24 13:39, Askar Safin wrote: > > Hi! I want glibc to have function "syscall_no_errno" on Linux. > > It should do the same "syscall" does, but it should not interpret > > return value and set errno. This is useful for calling syscalls > > such as getuid. I. e. now the user can call directly all syscalls > > including getuid and similar. > > > > I add example patch. It is quick-and-dirty. I was unable to figure out > > how to add function to headers. So, please, don't apply it as-is. > > > > I just want to know do you agree with my proposal. If yes, I will try > > to write better patch. > > > > I will repeat: currently glibc is simply incomplete, because it > > does not provide a way to call directly syscalls, such as getuid. > > So the user have to craft assembly, which is very difficult. > > Indeed there some old syscalls where trying to issue them directly with > syscall is problematic (like 'time' and 'brk' for some ABIs), but getuid > is not one of them. Also, recent Linux kABI is trying to avoid such > problematic interfaces to return the value as the return code and make > the invalid value similar to all cases. So these are not very compeling > reason to add a non-standard symbol to issue syscalls. > > CCing Rich, maybe he has a different view about this. That would be my view too. In general, it's rarely useful to make a raw syscall() to begin with. For the majority of syscalls that are ingredients in implementing standard or almost-standard functions provided by libc, going around libc to call it directly risks creating inconsistent state (brk), having inconsistent types (stat, etc.), missing fallback cases (direct use of time64 syscalls), etc. and really should not be encouraged by making unneeded new ways to do it. Indeed the only syscalls I'm aware of for which there's ambiguity about the result are of this sort. I don't even think brk is an affected one; values >=4095UL are not valid brk boundaries. Similarly, I don't think Linux supports setting system clock to before the epoch (and doing so would not be accurate anyway), so time is arguably not affected either. Even if it were, it's superseded by clock_gettime or gettimeofday, which don't have the problem, and might not even be available on future archs. There is also fcntl with F_GETOWN, which was not mentioned above, but it is superseded by F_GETOWN_EX, which the libc fcntl function automatically uses when available instead of using F_GETOWN directly. So I don't think it has modern relevance either. In any case, back to my original point, the use case for syscall() should be seen as calling newly-added extensions that don't yet have, or that aren't suitable to have, libc functions for them. Use of it as a means to "poke behind libc" should not be encouraged, as that tends to break things. If someone really wants to write code that's independent of libc -- like to run in a vforked child or CLONE_VM context or something without a valid thread pointer/TLS state/etc. -- it can't be using libc at all, and that includes the libc syscall() function (which not only may write errno, but might inspect TLS to determine how to make the syscall). For this level of "raw" syscall access, you need to write your own asm. Rich