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 30BC8385DC38 for ; Thu, 1 Feb 2024 20:16:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 30BC8385DC38 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 30BC8385DC38 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=1706818585; cv=none; b=CWuSxylqX59j0oah9pp0vNIVjEj5FEr6oS0aAISCjKyNcMEgs5vgdEmkQaJsEYaNwu8v4xIqOkn/WRjMeahRjrUwktuZ/Cu7cwqwyjVBKrK1JckoxtJSu8umU5t7wDukZTd/3SBiP36i6d2Q6URzfKkRQIWnzJPpZBa+NSBMCEQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706818585; c=relaxed/simple; bh=2cQAZwea62rduQSgZoFrNONRBDfBENWFabEZYOBJ4so=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=unWzREZyDjU2aDKNdvzotRSsp2813NiBQ8qVU2TDqvaXGJ66QPBslwsoRkngBZx3nnCTTJxrrHB/b55qjRJPp/OglR81s9zus/qH5PflLXQ26FDMztsEsmYYKUEmOvw5G/oIdi4G9GZt0iRHqqQ2lOaSTTAcVopKX40W2PI8cRc= ARC-Authentication-Results: i=1; server2.sourceware.org Date: Thu, 1 Feb 2024 15:16:38 -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: <20240201201638.GG22081@brightrain.aerifal.cx> References: <20240128163958.17421-1-safinaskar@zohomail.com> <380959fd-3414-4fc6-ae3f-85abdee2a9a0@linaro.org> <18d6628ba70.12a99fe2719939.4022957090731865688@zohomail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18d6628ba70.12a99fe2719939.4022957090731865688@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 Thu, Feb 01, 2024 at 11:32:41PM +0400, Askar Safin wrote: > Hi, Rich and Adhemerval! > > ---- On Thu, 01 Feb 2024 21:53:44 +0400 Adhemerval Zanella Netto wrote --- > > 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. > It *is* one of them! > > Keep in mind that Linux supports 32-bit uids. > > Run this code as root as 32-bit i386 binary (my letter continues > after code). It is okay to run it on 64-bit amd64 kernel, you just > have to make sure the binary itself is compiled as i386 > =*=*=*=*= > #if !defined(__i386__) > #error > #endif > > #include > #include > #include > #include > > int > main (void) > { > // 4294967286 is (2^32)-10 > uint32_t a = 4294967286U; > if (syscall (SYS_setuid32, a) == -1) > { > perror("setuid"); > return 1; > } > > uint32_t b = syscall (SYS_getuid32); > > // Now b is equal to (uint32_t)-1 instead of wanted 4294967286 (i. e. (uint32_t)-10) > printf("%u (wanted)\n", a); > printf("%u (got)\n", b); > return 0; > } > =*=*=*=*= > > (Also, when I said "getuid", I meant "SYS_getuid32".) > > I see this output: > =*=*=*=*= > 4294967286 (wanted) > 4294967295 (got) > =*=*=*=*= > > So, yes, function "syscall" is incompatible with SYS_getuid32. OK, but this falls under "poking around behind libc's back". If you call getuid() you'll find you get the right answer (at least on musl; not sure about glibc). > I'm nearly sure the same is true about getpid. It's not. PIDs are a 29- or 30-bit space (which is a matter of a bug I currently have open) on Linux. At least the high two bits are banned from ever being usable as a consequence of the futex interface. > Rich: > > If someone really wants to write code that's > > independent of libc -- like to run in a vforked child or CLONE_VM > > This is another use case I want to support. I. e. I want to > have portable function (i. e. independent of arch) for issuing > syscall in such case. And I don't > want to write assembly. 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. > > but might inspect TLS to > > determine how to make the syscall > > Okay, so syscall_no_errno should not do this. I. e. it should > always do some way to make syscall, which always works, > even if it is slow. For i386 it is "int 0x80" as well as I understand. > > Also, even if we read TLS to determine how to make syscall, > what will go wrong? Child shares TLS with its parent after CLONE_VM, > so we simply will read parent's TLS At least on glibc, you can pass clone flags that setup a new thread pointer in the child, which you may be intending to use for your own purposes in 'bare, no libc' code in the child. On musl this is not possible; the flags are rejected and you have to write your own asm to call clone if you want that. In any case, "what will go wrong?" is not the right question. The question is whether there's a contract for the thing you want to do to work, and there isn't. Rich