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 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24356 invoked from network); 19 May 2021 10:24:17 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 19 May 2021 10:24:17 -0000 Received: (qmail 21578 invoked by uid 550); 19 May 2021 10:24:15 -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 21548 invoked from network); 19 May 2021 10:24:15 -0000 Date: Wed, 19 May 2021 13:24:03 +0300 From: "Dmitry V. Levin" To: Nicholas Piggin Cc: Michael Ellerman , libc-dev@lists.llvm.org, linux-api@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, musl@lists.openwall.com, Matheus Castanho , libc-alpha@sourceware.org Message-ID: <20210519102403.GA15207@altlinux.org> References: <20200611081203.995112-1-npiggin@gmail.com> <20210518231331.GA8464@altlinux.org> <1621385544.nttlk5qugb.astroid@bobo.none> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1621385544.nttlk5qugb.astroid@bobo.none> Subject: [musl] Re: Linux powerpc new system call instruction and ABI On Wed, May 19, 2021 at 12:50:24PM +1000, Nicholas Piggin wrote: [...] > With this patch, I think the ptrace ABI should mostly be fixed. I think > a problem remains with applications that look at system call return > registers directly and have powerpc specific error cases. Those probably > will just need to be updated unfortunately. Michael thought it might be > possible to return an indication via ptrace somehow that the syscall is > using a new ABI, so such apps can be updated to test for it. I don't > know how that would be done. Is there any sane way for these applications to handle the scv case? How can they tell that the scv semantics is being used for the given syscall invocation? Can this information be obtained e.g. from struct pt_regs? For example, in strace we have the following powerpc-specific code used for syscall tampering: $ cat src/linux/powerpc/set_error.c /* * Copyright (c) 2016-2021 The strace developers. * All rights reserved. * * SPDX-License-Identifier: LGPL-2.1-or-later */ static int arch_set_r3_ccr(struct tcb *tcp, const unsigned long r3, const unsigned long ccr_set, const unsigned long ccr_clear) { if (ptrace_syscall_info_is_valid() && upeek(tcp, sizeof(long) * PT_CCR, &ppc_regs.ccr)) return -1; const unsigned long old_ccr = ppc_regs.ccr; ppc_regs.gpr[3] = r3; ppc_regs.ccr |= ccr_set; ppc_regs.ccr &= ~ccr_clear; if (ppc_regs.ccr != old_ccr && upoke(tcp, sizeof(long) * PT_CCR, ppc_regs.ccr)) return -1; return upoke(tcp, sizeof(long) * (PT_R0 + 3), ppc_regs.gpr[3]); } static int arch_set_error(struct tcb *tcp) { return arch_set_r3_ccr(tcp, tcp->u_error, 0x10000000, 0); } static int arch_set_success(struct tcb *tcp) { return arch_set_r3_ccr(tcp, tcp->u_rval, 0, 0x10000000); } -- ldv