Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4149951imu; Sat, 24 Nov 2018 20:10:55 -0800 (PST) X-Google-Smtp-Source: AFSGD/VmpbMcRAIS1iz/n2orq18o61dseDy//7rRe8yel9ckIumYJSJhr0gTERWaoJ+zy5EkcOlq X-Received: by 2002:a17:902:2887:: with SMTP id f7mr21642694plb.176.1543119055466; Sat, 24 Nov 2018 20:10:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543119055; cv=none; d=google.com; s=arc-20160816; b=b2Nw0CAL/Ha7fNaucrGxOMdgqKmS6a7hDxv5EOuinvZ7nHRzZeNTD+x8+AGQbkiYg7 VF0eqG5IbsgZ1WrHQpXJzBlQ+qsPergQXJFjBOIIgnReQwirRprymWw4dYDYM47Sddca k0Q2fAke474qBBdVjK2I0aHX2SgDpIQYqf11zsVLHSG+m1KOJvZJIN5s23QmH0gCkmo/ TlpUu7cAyIY9J+3QLoh8IlApbEFoayQlW3KbNb+xT+afE/80XyJzHO7pQ/gnMO9GEclg unK9aiI1dR4gaWbGTN4qENqvDi9F+GQFIf1zkWUGiN7a/EOTj12WlChPMU5dpNKScwPM lvZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=xRDjjwy8+7SPe2G7Q1AsZZwbVfFAhHQGoh+OCrTqT44=; b=qehp4rzV1uqxtM06sbPrDQvjAqJNC/RjTSITSg6FjiZVHx+sDEKwOB2CPc38ncW3W9 kePcIBYTuZpN2mZR83S686ic8mk+BAaUnxw0rIiIigjyz1WyAwReioEMB4hR9qAELVq5 xVLR5HRSvXBXnlL7cp6gl0236eXZ+iFD8psK7tlLvj+rj37IR+ek4MZbRXzCEtWZqKlh lMAqPvsSfbxMCJZjIDmyqWjh19hpaOlON9ug5jleVuGBvsrMG/IxmxAaWiTArhTCFcZn 4qVsF7DIlgMorDePwiEkWWyWfctvTx/9dc+SnwlDnt1rMW+mNe0df176aay5goflaswn o84Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f81si47348716pfh.33.2018.11.24.20.10.40; Sat, 24 Nov 2018 20:10:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727155AbeKYPAN (ORCPT + 99 others); Sun, 25 Nov 2018 10:00:13 -0500 Received: from vmicros1.altlinux.org ([194.107.17.57]:40178 "EHLO vmicros1.altlinux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726540AbeKYPAN (ORCPT ); Sun, 25 Nov 2018 10:00:13 -0500 Received: from mua.local.altlinux.org (mua.local.altlinux.org [192.168.1.14]) by vmicros1.altlinux.org (Postfix) with ESMTP id 817B872CC61; Sun, 25 Nov 2018 07:10:03 +0300 (MSK) Received: by mua.local.altlinux.org (Postfix, from userid 508) id 719397CD0D5; Sun, 25 Nov 2018 07:10:03 +0300 (MSK) Date: Sun, 25 Nov 2018 07:10:03 +0300 From: "Dmitry V. Levin" To: Andy Lutomirski Cc: Elvira Khabirova , Kees Cook , Linux API , Jann Horn , Oleg Nesterov , Steven Rostedt , Ingo Molnar , LKML , Eugene Syromiatnikov , strace-devel@lists.strace.io Subject: Re: [RFC PATCH v2] ptrace: add PTRACE_GET_SYSCALL_INFO request Message-ID: <20181125041003.GA3258@altlinux.org> References: <20181121165806.07da7c98@akathisia> <20181121235634.GA14146@altlinux.org> <20181122191504.GB27204@altlinux.org> <20181123040139.GB2572@altlinux.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: <20181123040139.GB2572@altlinux.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 23, 2018 at 07:01:39AM +0300, Dmitry V. Levin wrote: > On Thu, Nov 22, 2018 at 04:19:10PM -0800, Andy Lutomirski wrote: > > On Thu, Nov 22, 2018 at 11:15 AM Dmitry V. Levin wrote: > > > On Thu, Nov 22, 2018 at 06:55:29AM -0800, Andy Lutomirski wrote: > > > > On Wed, Nov 21, 2018 at 3:56 PM Dmitry V. Levin wrote: > > > > > On Wed, Nov 21, 2018 at 02:56:57PM -0800, Andy Lutomirski wrote: > > > > > > Please cc linux-api@vger.kernel.org for future versions. > > > > > > > > > > > > On Wed, Nov 21, 2018 at 7:58 AM Elvira Khabirova wrote: > > > > > > > > > > > > > > struct ptrace_syscall_info { > > > > > > > __u8 op; /* 0 for entry, 1 for exit */ > > > > > > > > > > > > Can you add proper defines, like: > > > > > > > > > > > > #define PTRACE_SYSCALL_ENTRY 0 > > > > > > #define PTRACE_SYSCALL_EXIT 1 > > > > > > #define PTRACE_SYSCALL_SECCOMP 2 > > > > > > > > > > > > and make seccomp work from the start? I'd rather we don't merg= e an > > > > > > implementation that doesn't work for seccomp and then have to r= ework > > > > > > it later. > > > > > > > > > > What's the difference between PTRACE_EVENT_SECCOMP and syscall-en= try-stop > > > > > with regards to PTRACE_GET_SYSCALL_INFO request? At least they h= ave the > > > > > same entry_info to return. > > > > > > > > I'm not sure there's any material difference. > > > > > > In that case we don't really need PTRACE_SYSCALL_SECCOMP: op field > > > describes the structure inside the union to use, not the ptrace stop. > >=20 > > Unless we think the structures might diverge in the future. >=20 > If these structures ever diverge, then a seccomp structure will be added > to the union, and a portable userspace code will likely look this way: >=20 > #include > ... > struct ptrace_syscall_info info; > long rc =3D ptrace(PTRACE_GET_SYSCALL_INFO, pid, (void *) sizeof(info), &= info); > ... > switch (info.op) { > case PTRACE_SYSCALL_INFO_ENTRY: > /* handle info.entry */ > case PTRACE_SYSCALL_INFO_EXIT: > /* handle info.exit */ > #ifdef PTRACE_SYSCALL_INFO_SECCOMP > case PTRACE_SYSCALL_INFO_SECCOMP: > /* handle info.seccomp */ > #endif > default: > /* handle unknown info.op */ > } >=20 > In other words, it would be better if PTRACE_SYSCALL_INFO_* selector > constants were introduced along with corresponding structures in the > union. However, the approach I suggested doesn't provide forward compatibility: if userspace is compiled with kernel headers that don't define PTRACE_SYSCALL_INFO_SECCOMP, it will break when the kernel starts to use PTRACE_SYSCALL_INFO_SECCOMP instead of PTRACE_SYSCALL_INFO_ENTRY for PTRACE_EVENT_SECCOMP support in PTRACE_GET_SYSCALL_INFO. The solution is to introduce PTRACE_SYSCALL_INFO_SECCOMP and struct ptrace_syscall_info.seccomp along with PTRACE_EVENT_SECCOMP support in PTRACE_GET_SYSCALL_INFO. The initial revision of the seccomp structure could be made the same as the entry structure, or it can diverge from the beginning, e.g., by adding ret_data field containing SECCOMP_RET_DATA return value stored in ptrace_message, this would save ptracers an extra PTRACE_GETEVENTMSG call currently required to obtain it. --=20 ldv --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJb+iCbAAoJEAVFT+BVnCUIS3MQAKeeh/Bd9DjwDYgYnBn54D86 QBdDnegpvIpajluY994tUaCT3vgNamR+SmwRmi8ED7IXsLD6oImZR6ctmN42HSaM t7SJc82r6p0yQJ7H/7c78jmlMIQFSGmnCM4H69AUkxYdoDQ3ehSRXPN2w0g5+y1u r6F2XAUGgNi9jnwJmz57kkD4qVw32rVfNSWhCl7XxT5aJznozUJk8JRDVk2dbmMw vg/WHD47HFcBKkkEPUH9edzFqzHdZcbwqIYQBaAbJpbkxexGIEVF5o26g/kC1Mts UL4mmy0LfAsf8GGjomuLsRsGKEEs58oiRdmKWqGmeKi0l0EPCBo+1e1Rb9UbDs9p Mepp7tvbh3T/BjS7rBmNgEK7mXUEV4prJq6Os6TJs4mTptaisYRZX+MNYNEahLRg +c/RGFO5gnsulYoWv+HrTkGjv44MoiespBAwkHIPh873inpcGM4SnMO8nZW0PsDE mL7Wei96TDkv1db8Q8dAIz3fb+c9S4uEli+Q2vtGIAc/2bjK1+VL7ZXra0uJCAdT Xz3aiQPVZ5Ie65f2rVoLTwr/QlujImY6k64vfRxQrwM9BQei7859QStHr7PtAi8V 4Gt23TfCWgxg9Lw/Zk8TRY3g9UUc2TsuWQQJ2CikQFkh+sKVpKb2hbe7t12+nWOJ fV3T2OM5XZn6FHDXmA8i =y+u9 -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ--