From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BBBFBC433B4 for ; Thu, 22 Apr 2021 19:07:22 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EEB19613DB for ; Thu, 22 Apr 2021 19:07:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EEB19613DB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=altlinux.org Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=linux-audit-bounces@redhat.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-460-6oOtN2KvPfqMLyspeysKzg-1; Thu, 22 Apr 2021 15:07:19 -0400 X-MC-Unique: 6oOtN2KvPfqMLyspeysKzg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0EF5B8542C0; Thu, 22 Apr 2021 19:07:16 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8F5555C3E0; Thu, 22 Apr 2021 19:07:14 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id CA0371806D0F; Thu, 22 Apr 2021 19:07:12 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 13MJ7Aig023225 for ; Thu, 22 Apr 2021 15:07:10 -0400 Received: by smtp.corp.redhat.com (Postfix) id E7E8510A7E26; Thu, 22 Apr 2021 19:07:09 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast06.extmail.prod.ext.rdu2.redhat.com [10.11.55.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E381910A7E39 for ; Thu, 22 Apr 2021 19:07:07 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6A35B185A79C for ; Thu, 22 Apr 2021 19:07:07 +0000 (UTC) Received: from vmicros1.altlinux.org (vmicros1.altlinux.org [194.107.17.57]) by relay.mimecast.com with ESMTP id us-mta-272-Kao5tJyBOJOrzOlN6g0zPw-1; Thu, 22 Apr 2021 15:07:05 -0400 X-MC-Unique: Kao5tJyBOJOrzOlN6g0zPw-1 Received: from mua.local.altlinux.org (mua.local.altlinux.org [192.168.1.14]) by vmicros1.altlinux.org (Postfix) with ESMTP id 3CB5672C8B5; Thu, 22 Apr 2021 21:57:43 +0300 (MSK) Received: by mua.local.altlinux.org (Postfix, from userid 508) id 2EEC27CC69B; Thu, 22 Apr 2021 21:57:43 +0300 (MSK) Date: Thu, 22 Apr 2021 21:57:43 +0300 From: "Dmitry V. Levin" To: Mark Rutland Subject: Re: [PATCH 1/3] arm64: ptrace: Add is_syscall_success to handle compat Message-ID: <20210422185743.GC12226@altlinux.org> References: <20210416075533.7720-1-zhe.he@windriver.com> <20210416123322.GA23184@arm.com> <20210416133431.GA2303@C02TD0UTHF1T.local> <20210419121932.GA30004@willie-the-truck> <20210421171005.GA46949@C02TD0UTHF1T.local> <20210422160752.GA2214@willie-the-truck> <20210422164228.GD66392@C02TD0UTHF1T.local> MIME-Version: 1.0 In-Reply-To: <20210422164228.GD66392@C02TD0UTHF1T.local> X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-loop: linux-audit@redhat.com Cc: He Zhe , Catalin Marinas , oleg@redhat.com, linux-kernel@vger.kernel.org, linux-audit@redhat.com, Will Deacon , linux-arm-kernel@lists.infradead.org X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=linux-audit-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Apr 22, 2021 at 05:42:28PM +0100, Mark Rutland wrote: > On Thu, Apr 22, 2021 at 05:07:53PM +0100, Will Deacon wrote: > > On Wed, Apr 21, 2021 at 06:10:05PM +0100, Mark Rutland wrote: > > > On Mon, Apr 19, 2021 at 01:19:33PM +0100, Will Deacon wrote: > > > > On Fri, Apr 16, 2021 at 02:34:41PM +0100, Mark Rutland wrote: > > > > > I think this is a problem we created for ourselves back in commit: > > > > > > > > > > 15956689a0e60aa0 ("arm64: compat: Ensure upper 32 bits of x0 are zero on syscall return) > > > > > > > > > > AFAICT, the perf regs samples are the only place this matters, since for > > > > > ptrace the compat regs are implicitly truncated to compat_ulong_t, and > > > > > audit expects the non-truncated return value. Other architectures don't > > > > > truncate here, so I think we're setting ourselves up for a game of > > > > > whack-a-mole to truncate and extend wherever we need to. > > > > > > > > > > Given that, I suspect it'd be better to do something like the below. > > > > > > > > > > Will, thoughts? > > > > > > > > I think perf is one example, but this is also visible to userspace via the > > > > native ptrace interface and I distinctly remember needing this for some > > > > versions of arm64 strace to work correctly when tracing compat tasks. > > > > > > FWIW, you've convinced me on your approach (more on that below), but > > > when I went digging here this didn't seem to be exposed via ptrace -- > > > for any task tracing a compat task, the GPRs are exposed via > > > compat_gpr_{get,set}(), which always truncate to compat_ulong_t, giving > > > the lower 32 bits. See task_user_regset_view() for where we get the > > > regset. > > > > > > Am I missing something, or are you thinking of another issue you fixed > > > at the same time? > > > > I think it may depend on whether strace pokes at the GPRs or instead issues > > a PTRACE_GET_SYSCALL_INFO request but I've forgotten the details, > > unfortunately. I do remember seeing an issue though, and it was only last > > year. > > Ah; I hadn't spotted PTRACE_GET_SYSCALL_INFO, thanks for the pointer. I > see that gets at the regs via syscall_get_arguments(), which doesn't > truncate them. > > That makes me wonder whether x86 and others do the right thing here... Yes, some architectures had to be fixed, but they mostly do the right thing nowadays. Feel free to use tools/testing/selftests/ptrace/get_syscall_info.c for testing, or indeed use strace test suite. -- ldv -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4A6BAC433ED for ; Thu, 22 Apr 2021 18:59:55 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D0EC761405 for ; Thu, 22 Apr 2021 18:59:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D0EC761405 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=altlinux.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=8gG6bTXbkk7Ov3tP6rGht3tDx2XmWDf8TUprSwFUMuk=; b=jyub8AZeqizZt7BE8QPSduEGC FIum2ndET39bvY8+jxK6A8gsZtKX94HLmbkrJgkGf07VKJJ1I53hB4p2uL+Lc0eRV+ElYHG/NR7fL dw8bSyeJSNG5na+42C20PVXF1CE9qjGzh0b7nPQWIPNZu3HaRT4fSvCbhzETE9ZpvxxBHLPVqyJ73 v4K3QjzZ39neoP1OP8+t9sE/llOxjEI90ylFUcgMqwpyDDmNtAgkLxvba7/ptLWFg7IrRPj6WS863 svizrx+pniKCUBxBQltiaF9mK/DYDk/1Ph6PS8aKFfpgsMfhfsNg+hc5Ir7WzS+r2RUt/jkOAD68Y XoDoQy22w==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lZeWQ-00HHYs-CX; Thu, 22 Apr 2021 18:57:54 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lZeWO-00HHYi-0X for linux-arm-kernel@desiato.infradead.org; Thu, 22 Apr 2021 18:57:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=I1bHCgSFujSa2xfrDDd1DRRAhS0PDtjH+qVfb+Ojq88=; b=kHiRT3ax8QLstMnx6es4TpqAfS e6qaiFG/wN9zG8i3e6nnQKkcd+AbLj81UBJQx5xrWbVZpee5Fi0uWeAYxrco6hKJffN7CNoRUmHx0 jN/avxH2VV54j9to7/NdsgI/tvJ8ZjIkiCPr4w+7N1GFitaGcXbUxfU4rkLfC/fidjsGo0iCz2ik0 e3iLiIOHboynf5Jt6GSWf9YQWhcTcYo/vJ2mRq9ebaHzNHCOFqVwcGTp+NHcK9YjjeEp4GxA4eJJn qnQJWyIFLdE97r4mJhbIjK2tdvBa9AbNwNFXXa4ejBLWW/DjAEXTj0JgjA/6enhOXsETE6xgk0Pkd oZfMEmFg==; Received: from vmicros1.altlinux.org ([194.107.17.57]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lZeWK-00Dvtz-UK for linux-arm-kernel@lists.infradead.org; Thu, 22 Apr 2021 18:57:50 +0000 Received: from mua.local.altlinux.org (mua.local.altlinux.org [192.168.1.14]) by vmicros1.altlinux.org (Postfix) with ESMTP id 3CB5672C8B5; Thu, 22 Apr 2021 21:57:43 +0300 (MSK) Received: by mua.local.altlinux.org (Postfix, from userid 508) id 2EEC27CC69B; Thu, 22 Apr 2021 21:57:43 +0300 (MSK) Date: Thu, 22 Apr 2021 21:57:43 +0300 From: "Dmitry V. Levin" To: Mark Rutland Cc: Will Deacon , Catalin Marinas , He Zhe , oleg@redhat.com, linux-arm-kernel@lists.infradead.org, paul@paul-moore.com, eparis@redhat.com, linux-audit@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] arm64: ptrace: Add is_syscall_success to handle compat Message-ID: <20210422185743.GC12226@altlinux.org> References: <20210416075533.7720-1-zhe.he@windriver.com> <20210416123322.GA23184@arm.com> <20210416133431.GA2303@C02TD0UTHF1T.local> <20210419121932.GA30004@willie-the-truck> <20210421171005.GA46949@C02TD0UTHF1T.local> <20210422160752.GA2214@willie-the-truck> <20210422164228.GD66392@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210422164228.GD66392@C02TD0UTHF1T.local> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210422_115749_192406_517A087F X-CRM114-Status: GOOD ( 26.84 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Apr 22, 2021 at 05:42:28PM +0100, Mark Rutland wrote: > On Thu, Apr 22, 2021 at 05:07:53PM +0100, Will Deacon wrote: > > On Wed, Apr 21, 2021 at 06:10:05PM +0100, Mark Rutland wrote: > > > On Mon, Apr 19, 2021 at 01:19:33PM +0100, Will Deacon wrote: > > > > On Fri, Apr 16, 2021 at 02:34:41PM +0100, Mark Rutland wrote: > > > > > I think this is a problem we created for ourselves back in commit: > > > > > > > > > > 15956689a0e60aa0 ("arm64: compat: Ensure upper 32 bits of x0 are zero on syscall return) > > > > > > > > > > AFAICT, the perf regs samples are the only place this matters, since for > > > > > ptrace the compat regs are implicitly truncated to compat_ulong_t, and > > > > > audit expects the non-truncated return value. Other architectures don't > > > > > truncate here, so I think we're setting ourselves up for a game of > > > > > whack-a-mole to truncate and extend wherever we need to. > > > > > > > > > > Given that, I suspect it'd be better to do something like the below. > > > > > > > > > > Will, thoughts? > > > > > > > > I think perf is one example, but this is also visible to userspace via the > > > > native ptrace interface and I distinctly remember needing this for some > > > > versions of arm64 strace to work correctly when tracing compat tasks. > > > > > > FWIW, you've convinced me on your approach (more on that below), but > > > when I went digging here this didn't seem to be exposed via ptrace -- > > > for any task tracing a compat task, the GPRs are exposed via > > > compat_gpr_{get,set}(), which always truncate to compat_ulong_t, giving > > > the lower 32 bits. See task_user_regset_view() for where we get the > > > regset. > > > > > > Am I missing something, or are you thinking of another issue you fixed > > > at the same time? > > > > I think it may depend on whether strace pokes at the GPRs or instead issues > > a PTRACE_GET_SYSCALL_INFO request but I've forgotten the details, > > unfortunately. I do remember seeing an issue though, and it was only last > > year. > > Ah; I hadn't spotted PTRACE_GET_SYSCALL_INFO, thanks for the pointer. I > see that gets at the regs via syscall_get_arguments(), which doesn't > truncate them. > > That makes me wonder whether x86 and others do the right thing here... Yes, some architectures had to be fixed, but they mostly do the right thing nowadays. Feel free to use tools/testing/selftests/ptrace/get_syscall_info.c for testing, or indeed use strace test suite. -- ldv _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3C35FC433ED for ; Thu, 22 Apr 2021 18:57:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EA66361424 for ; Thu, 22 Apr 2021 18:57:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238547AbhDVS6U (ORCPT ); Thu, 22 Apr 2021 14:58:20 -0400 Received: from vmicros1.altlinux.org ([194.107.17.57]:41380 "EHLO vmicros1.altlinux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236058AbhDVS6U (ORCPT ); Thu, 22 Apr 2021 14:58:20 -0400 Received: from mua.local.altlinux.org (mua.local.altlinux.org [192.168.1.14]) by vmicros1.altlinux.org (Postfix) with ESMTP id 3CB5672C8B5; Thu, 22 Apr 2021 21:57:43 +0300 (MSK) Received: by mua.local.altlinux.org (Postfix, from userid 508) id 2EEC27CC69B; Thu, 22 Apr 2021 21:57:43 +0300 (MSK) Date: Thu, 22 Apr 2021 21:57:43 +0300 From: "Dmitry V. Levin" To: Mark Rutland Cc: Will Deacon , Catalin Marinas , He Zhe , oleg@redhat.com, linux-arm-kernel@lists.infradead.org, paul@paul-moore.com, eparis@redhat.com, linux-audit@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] arm64: ptrace: Add is_syscall_success to handle compat Message-ID: <20210422185743.GC12226@altlinux.org> References: <20210416075533.7720-1-zhe.he@windriver.com> <20210416123322.GA23184@arm.com> <20210416133431.GA2303@C02TD0UTHF1T.local> <20210419121932.GA30004@willie-the-truck> <20210421171005.GA46949@C02TD0UTHF1T.local> <20210422160752.GA2214@willie-the-truck> <20210422164228.GD66392@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210422164228.GD66392@C02TD0UTHF1T.local> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 22, 2021 at 05:42:28PM +0100, Mark Rutland wrote: > On Thu, Apr 22, 2021 at 05:07:53PM +0100, Will Deacon wrote: > > On Wed, Apr 21, 2021 at 06:10:05PM +0100, Mark Rutland wrote: > > > On Mon, Apr 19, 2021 at 01:19:33PM +0100, Will Deacon wrote: > > > > On Fri, Apr 16, 2021 at 02:34:41PM +0100, Mark Rutland wrote: > > > > > I think this is a problem we created for ourselves back in commit: > > > > > > > > > > 15956689a0e60aa0 ("arm64: compat: Ensure upper 32 bits of x0 are zero on syscall return) > > > > > > > > > > AFAICT, the perf regs samples are the only place this matters, since for > > > > > ptrace the compat regs are implicitly truncated to compat_ulong_t, and > > > > > audit expects the non-truncated return value. Other architectures don't > > > > > truncate here, so I think we're setting ourselves up for a game of > > > > > whack-a-mole to truncate and extend wherever we need to. > > > > > > > > > > Given that, I suspect it'd be better to do something like the below. > > > > > > > > > > Will, thoughts? > > > > > > > > I think perf is one example, but this is also visible to userspace via the > > > > native ptrace interface and I distinctly remember needing this for some > > > > versions of arm64 strace to work correctly when tracing compat tasks. > > > > > > FWIW, you've convinced me on your approach (more on that below), but > > > when I went digging here this didn't seem to be exposed via ptrace -- > > > for any task tracing a compat task, the GPRs are exposed via > > > compat_gpr_{get,set}(), which always truncate to compat_ulong_t, giving > > > the lower 32 bits. See task_user_regset_view() for where we get the > > > regset. > > > > > > Am I missing something, or are you thinking of another issue you fixed > > > at the same time? > > > > I think it may depend on whether strace pokes at the GPRs or instead issues > > a PTRACE_GET_SYSCALL_INFO request but I've forgotten the details, > > unfortunately. I do remember seeing an issue though, and it was only last > > year. > > Ah; I hadn't spotted PTRACE_GET_SYSCALL_INFO, thanks for the pointer. I > see that gets at the regs via syscall_get_arguments(), which doesn't > truncate them. > > That makes me wonder whether x86 and others do the right thing here... Yes, some architectures had to be fixed, but they mostly do the right thing nowadays. Feel free to use tools/testing/selftests/ptrace/get_syscall_info.c for testing, or indeed use strace test suite. -- ldv