Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <0d95a96b-dd49-db45-ab3c-1d9cee51381d@gmail.com>
Date:   Fri, 14 Apr 2023 21:53:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.1
Subject: Re: Checking for support of ptrace(PTRACE_SEIZE,...) on older kernels
Content-Language: en-US
To:     Sergei Zhirikov <sfzhi@yahoo.com>, Oleg Nesterov <oleg@redhat.com>
Cc:     linux-man@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
References: <997950238.3486335.1681414225118.ref@mail.yahoo.com>
 <997950238.3486335.1681414225118@mail.yahoo.com>
From:   Alejandro Colomar <alx.manpages@gmail.com>
In-Reply-To: <997950238.3486335.1681414225118@mail.yahoo.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------RgM6wphRtTIER0lTot2cUfDu"
Precedence: bulk

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------RgM6wphRtTIER0lTot2cUfDu
Content-Type: multipart/mixed; boundary="------------voYPYiFG8IDLaQduQaOQE9xm";
 protected-headers="v1"
From: Alejandro Colomar <alx.manpages@gmail.com>
To: Sergei Zhirikov <sfzhi@yahoo.com>, Oleg Nesterov <oleg@redhat.com>
Cc: linux-man@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Message-ID: <0d95a96b-dd49-db45-ab3c-1d9cee51381d@gmail.com>
Subject: Re: Checking for support of ptrace(PTRACE_SEIZE,...) on older kernels
References: <997950238.3486335.1681414225118.ref@mail.yahoo.com>
 <997950238.3486335.1681414225118@mail.yahoo.com>
In-Reply-To: <997950238.3486335.1681414225118@mail.yahoo.com>

--------------voYPYiFG8IDLaQduQaOQE9xm
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Sergei,

On 4/13/23 21:30, Sergei Zhirikov wrote:
> Hello,
>=20
> I've been studying the ptrace(2) man page and experimenting with ptrace=
() recently and came across this unexpected aspect of its behavior that I=
 think would be good to have documented.
>=20
> I would like to use PTRACE_SEIZE in my project because of the advantage=
s it offers, but I would also like to support kernels older than 3.4 (whe=
re it was fully introduced). My thinking was that I would call ptrace(PTR=
ACE_SEIZE, ...) and if it fails with the appropriate error code indicatin=
g that it's not supported I would fall back to PTRACE_ATTACH. That is whe=
re a little surprise was waiting for me. According to the man page, ptrac=
e will fail with errno=3DEIO if called with an invalid request code. Logi=
cally, that was the error code I expected to get when PTRACE_SEIZE is not=
 supported. In reality I got ESRCH instead. In my attempts to make sense =
of it I had to resort to reading the kernel source. Apparently, the logic=
 in the kernel (=C2=A0https://elixir.bootlin.com/linux/v3.0.101/source/ke=
rnel/ptrace.c#L944=C2=A0) seems to assume that any request other than PTR=
ACE_ATTACH must come for an already existing tracee. So it proceeds to lo=
ok for such a tracee (by calling ptrace_check_attach) before trying to in=
terpret the request code. Obviously, in case of PTRACE_SEIZE, the target =
process/thread is not being traced yet, so ESRCH is returned. As far as I=
 can tell by looking at the source code, that will happen for any request=
 code (with a couple of exceptions), valid or otherwise. The relevant pie=
ce of logic seems to remain unchanged to this day, so this isn't just a p=
roblem with an ancient kernel that nobody cares about. I am not sure whet=
her this behavior is intentional (I would guess it's not), but in any cas=
e it's probably good to have it documented in the man page.

I've added some CCs.  Feel free to send a patch.

Cheers,
Alex

>=20
> Thanks and regards,
> Sergei.

--=20
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

--------------voYPYiFG8IDLaQduQaOQE9xm--

--------------RgM6wphRtTIER0lTot2cUfDu
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmQ5rzIACgkQnowa+77/
2zK1lQ//d/swWXkNyq0QLyf0fKC7PMLwdxy/ZP4ZOesekitkafRYOsirR0XYdObK
rVMWll3kHOx3MqIPQ0w5iwDVCXOzlPGlqM32MycHvK6byP/p6n4/TXVwz1NyjiwO
M9KDK0MXkEBq52QR7G0WqJhIbpuPi40uDVdUEl61tVQZQBvasM2dXWAlBzjW5/QN
uXHKmwHoJPoI4RQ//t2WimKD6eZHcX2TY9mKzprZ0aHuoOAld7/POLn8v6OtwBCx
1sqDx6fJFW5Lop8kvpNJxXF8JDGYcxfqaUwsGSFZTP4ou3qIqjzieGShXwvQ1GSZ
GNq4zATnyVz/l8QGhZIuG8KKFfkvJ1xAet8q9f7KRPWZ8mt6jvyQJAFNWdOJ7X/m
2s5T6aBtjbZZ4BR9eRROk+ngOcsqjySn4VoBmT74qm1vUCo/e9xQ843pQiCxOGQb
4BLpBN3dYfzig2ybT1jiJZS7LzW56ab2wIjfQuPc/DiZPEtYEGq0JZF2KqKBCsDD
F2aFCl4e4/HZj/Gth3ySXwPpnKXG72aKunP5s7YpYzuoFx6ZssPCMd82KN3ICL0l
VQppmv9kb5y9vh13QjjrD8dZ+xhlRka7q3KlvApxkx190oWEdueI/o8SoQX3cM9O
PnK4Ws6D2HfK/XTh8YrIPxbspAAga/73buRGnKJFH46kuJP41cA=
=Qc0s
-----END PGP SIGNATURE-----

--------------RgM6wphRtTIER0lTot2cUfDu--