From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.virtlab.unibo.it (mail.virtlab.unibo.it [130.136.161.50]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8295735AC09 for ; Sun, 5 Jul 2026 06:41:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=130.136.161.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783233677; cv=none; b=LkL9gnkBvbyeCzYVUs+H8FCTcxeMxqhyKszV69xfm4fvyh4EthAEDyQvNKsqXMGO1rtR4FXdNC1bXv+N6mt7mOyftmftt2pHu+LwbthB0tJB6m/ilkCW2izXLxWNIXMLWchZcEvGWP89RYZaPhWjsNqC9zoGHCoRGEtyNaoe4lA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783233677; c=relaxed/simple; bh=D0axbq9LtaBDOLEXCc70B1Sk4qMqsfmXfaMIgUnusjU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LQOqJuFBOeL5HGtWAT79iccW2DO+OOlgJ9hATaDgoAMBUgy+w7zDWxd3O6Yq5TXbpFHF7N+UyrKr4+hcsMJ3zmFhtT6XOCQXDRkS3foWFV+33TFMp216f5gWcBIYhxfGCzlTP+QX0xV66MIcIMEHGneyEFGgpOMHDA5GfTA/5qY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cs.unibo.it; spf=pass smtp.mailfrom=cs.unibo.it; dkim=pass (1024-bit key) header.d=cs.unibo.it header.i=@cs.unibo.it header.b=GMpvCRoE; arc=none smtp.client-ip=130.136.161.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cs.unibo.it Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cs.unibo.it Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=cs.unibo.it header.i=@cs.unibo.it header.b="GMpvCRoE" Received: from cs.unibo.it (unknown [94.32.99.206]) by mail.virtlab.unibo.it (Postfix) with ESMTPSA id 726441C0143; Sun, 5 Jul 2026 08:41:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.unibo.it; s=virtlab; t=1783233669; bh=D0axbq9LtaBDOLEXCc70B1Sk4qMqsfmXfaMIgUnusjU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GMpvCRoEog0JBJqQO2BeFfkFVCZZYTzvq1iroX02zcPX2ZC/t4KYsAVXjt1+KWmA4 8JQtVBw87en9Dv7GdBUTIKKAIYASTViHurnMdrYypa0c4qq79FfXibA7qPMnoZoIGp yUJNUPgQyJJtx84fmEORR/drQSqGnGom0QfmcI90= Date: Sun, 5 Jul 2026 08:41:07 +0200 From: Renzo Davoli To: linux-kernel@vger.kernel.org Cc: Andrew Morton , Oleg Nesterov , Shuah Khan , Alexey Gladkov , Eugene Syromyatnikov , Davide Berardi , strace-devel@lists.strace.io, "Dmitry V . Levin" Subject: Re: [PATCH v2 1/2] ptrace: PTRACE_SET_SYSCALL_INFO syscall skipping support Message-ID: References: <20260704142643.692754-1-renzo@cs.unibo.it> <20260704142643.692754-2-renzo@cs.unibo.it> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260704142643.692754-2-renzo@cs.unibo.it> There is a problem on MIPS: https://sashiko.dev/#/patchset/20260704142643.692754-1-renzo%40cs.unibo.it It appears that on MIPS the feature of skipping a system call by setting its number to -1 does not work correctly when transitioning from _ENTRY to _EXIT: the system call return value is overwritten. PTRACE_EVENT_SECCOMP, however, has an explicit UAPI specification stating that setting the system call number to a negative value suppresses the system call. Moreover, kernel/ptrace.c contains the following comment: /* * If the syscall number is set to -1, setting syscall arguments is not * just pointless, it would also clobber the syscall return value on * those architectures that share the same register both for the first * argument of syscall and its return value. */ Thus, PTRACE_EVENT_SECCOMP is explicitly designed to preserve the system call return value when the system call is skipped. By contrast, for PTRACE_SYSCALL syscall-entry stops, the man page only states that the tracer may modify the system call number. It does not specify that assigning a negative value must suppress the system call and preserve the return value across all architectures, even though many architectures implement exactly this behavior. At this point I see two possible approaches: * fix the MIPS implementation (and audit, and possibly fix, the other architectures as well); * revert to the original proposal and allow the "skip syscall" feature only for PTRACE_EVENT_SECCOMP, i.e. permit PTRACE_SET_SYSCALL_INFO to transform only PTRACE_SYSCALL_INFO_SECCOMP stops into PTRACE_SYSCALL_INFO_EXIT stops. I would prefer the latter approach. I am concerned that changing the ptrace implementation in each architecture may introduce subtle regressions or other unintended side effects. In my opinion, seccomp-based syscall tracing is also the more powerful and flexible model compared to the traditional PTRACE_SYSCALL entry/exit mechanism. Support for system call suppression from PTRACE_SYSCALL_INFO_ENTRY can always be added later if and when a real use case arises. That would also provide an opportunity to audit the behavior of all supported architectures and, if necessary, make the semantics of negative system call numbers consistent across architectures. renzo