From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id B8DA0385B835 for ; Thu, 16 Apr 2020 16:42:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B8DA0385B835 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fw@deneb.enyo.de Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jP7az-0003ic-3t; Thu, 16 Apr 2020 16:42:33 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1jP7ay-0001zp-VH; Thu, 16 Apr 2020 18:42:32 +0200 From: Florian Weimer To: Rich Felker Cc: Nicholas Piggin , libc-alpha@sourceware.org, musl@lists.openwall.com, linuxppc-dev@lists.ozlabs.org, libc-dev@lists.llvm.org Subject: Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2 References: <1586931450.ub4c8cq8dj.astroid@bobo.none> <20200415225539.GL11469@brightrain.aerifal.cx> <87k12gf32r.fsf@mid.deneb.enyo.de> <20200416153509.GT11469@brightrain.aerifal.cx> Date: Thu, 16 Apr 2020 18:42:32 +0200 In-Reply-To: <20200416153509.GT11469@brightrain.aerifal.cx> (Rich Felker's message of "Thu, 16 Apr 2020 11:35:09 -0400") Message-ID: <87sgh3e613.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-9.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_NUMSUBJECT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 16:42:39 -0000 * Rich Felker: > On Thu, Apr 16, 2020 at 06:48:44AM +0200, Florian Weimer wrote: >> * Rich Felker: >> >> > My preference would be that it work just like the i386 AT_SYSINFO >> > where you just replace "int $128" with "call *%%gs:16" and the kernel >> > provides a stub in the vdso that performs either scv or the old >> > mechanism with the same calling convention. >> >> The i386 mechanism has received some criticism because it provides an >> effective means to redirect execution flow to anyone who can write to >> the TCB. I am not sure if it makes sense to copy it. > > Indeed that's a good point. Do you have ideas for making it equally > efficient without use of a function pointer in the TCB? We could add a shared non-writable mapping at a 64K offset from the thread pointer and store the function pointer or the code there. Then it would be safe. However, since this is apparently tied to POWER9 and we already have a POWER9 multilib, and assuming that we are going to backport the kernel change, I would tweak the selection criterion for that multilib to include the new HWCAP2 flag. If a user runs this glibc on a kernel which does not have support, they will get set baseline (POWER8) multilib, which still works. This way, outside the dynamic loader, no run-time dispatch is needed at all. I guess this is not at all the answer you were looking for. 8-) If a single binary is needed, I would perhaps follow what Arm did for -moutline-atomics: lay out the code so that its easy to execute for the non-POWER9 case, assuming that POWER9 machines will be better at predicting things than their predecessors. Or you could also put the function pointer into a RELRO segment. Then there's overlap with the __libc_single_threaded discussion, where people objected to this kind of optimization (although I did not propose to change the TCB ABI, that would be required for __libc_single_threaded because it's an external interface).