[PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Fotios Valasiadis]

From: Fotios Valasiadis <fvalasiad@csd.auth.gr>

Fixed incomplete doc. PTRACE_GET_SYSCALL_INFO's description wouldn't inform the user that they need to enable PTRACE_O_TRACESYSGOOD to get detailed information from said operation.

Came upon this bug after writing a test program using PTRACE_O_TRACESYSGOOD. After failing to find what's wrong I posted a stackoverflow question which you can find right here: https://stackoverflow.com/questions/72410182/ptrace-get-syscall-info-always-returns-info-op-as-ptrace-syscall-info-none

Nate Eldredge found out what's wrong by looking into the kernel's source code, here is a link to the relevant part https://github.com/torvalds/linux/blob/8291eaafed36f575f23951f3ce18407f480e9ecf/kernel/ptrace.c#L1018

In the code it can be seen that the union is filled if and only if the signal matches "SIGTRAP | 0x80", a signal which is only sent if the PTRACE_O_TRACESYSGOOD option is set. You can read about that in the PTRACE_O_TRACESYSGOOD section of ptrace.2 's manual.

I am unaware if Nate wants to be included as a co-author of this commit, nor am I aware of any way to contact him.

Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
---
 man2/ptrace.2 | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/man2/ptrace.2 b/man2/ptrace.2
index 55d9fd36d..b437b4f44 100644
--- a/man2/ptrace.2
+++ b/man2/ptrace.2
@@ -1033,6 +1033,11 @@ If the size of the data to be written by the kernel exceeds the size
 specified by the
 .I addr
 argument, the output data is truncated.
+To obtain complete information during system call entry or exit stops,
+you should enable the
+.B PTRACE_O_TRACESYSGOOD
+option using
+.B PTRACE_SETOPTIONS.
 .IP
 The
 .I ptrace_syscall_info
-- 
2.39.2

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Dmitry V. Levin]

On Fri, Feb 24, 2023 at 06:31:42PM +0200, Fotios Valasiadis wrote:
> From: Fotios Valasiadis <fvalasiad@csd.auth.gr>
> 
> Fixed incomplete doc. PTRACE_GET_SYSCALL_INFO's description wouldn't inform the user that they need to enable PTRACE_O_TRACESYSGOOD to get detailed information from said operation.
> 
> Came upon this bug after writing a test program using PTRACE_O_TRACESYSGOOD. After failing to find what's wrong I posted a stackoverflow question which you can find right here: https://stackoverflow.com/questions/72410182/ptrace-get-syscall-info-always-returns-info-op-as-ptrace-syscall-info-none
> 
> Nate Eldredge found out what's wrong by looking into the kernel's source code, here is a link to the relevant part https://github.com/torvalds/linux/blob/8291eaafed36f575f23951f3ce18407f480e9ecf/kernel/ptrace.c#L1018
> 
> In the code it can be seen that the union is filled if and only if the signal matches "SIGTRAP | 0x80", a signal which is only sent if the PTRACE_O_TRACESYSGOOD option is set. You can read about that in the PTRACE_O_TRACESYSGOOD section of ptrace.2 's manual.
> 
> I am unaware if Nate wants to be included as a co-author of this commit, nor am I aware of any way to contact him.

Cc'ed Nate just in case.

> Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
> ---
>  man2/ptrace.2 | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/man2/ptrace.2 b/man2/ptrace.2
> index 55d9fd36d..b437b4f44 100644
> --- a/man2/ptrace.2
> +++ b/man2/ptrace.2
> @@ -1033,6 +1033,11 @@ If the size of the data to be written by the kernel exceeds the size
>  specified by the
>  .I addr
>  argument, the output data is truncated.
> +To obtain complete information during system call entry or exit stops,
> +you should enable the
> +.B PTRACE_O_TRACESYSGOOD
> +option using
> +.B PTRACE_SETOPTIONS.
>  .IP
>  The
>  .I ptrace_syscall_info

I suggest the following wording:

diff --git a/man2/ptrace.2 b/man2/ptrace.2
index 55d9fd36d..496d8fae0 100644
--- a/man2/ptrace.2
+++ b/man2/ptrace.2
@@ -1111,6 +1111,15 @@ stop.
 .B PTRACE_SYSCALL_INFO_NONE
 No component of the union contains relevant information.
 .RE
+.IP
+Note that the data returned by
+.B PTRACE_GET_SYSCALL_INFO
+is limited to type
+.B
+PTRACE_SYSCALL_INFO_NONE
+unless
+.B PTRACE_O_TRACESYSGOOD
+option is set before the corresponding ptrace stop has occurred.
 .\"
 .SS Death under ptrace
 When a (possibly multithreaded) process receives a killing signal

As written in the manual page, using the PTRACE_O_TRACESYSGOOD option is
the recommended method to distinguish syscall-stops from other kinds of
ptrace-stops, since it is reliable and does not incur a performance
penalty.  In other words, if you use ptrace(2) at all, please consider
using PTRACE_O_TRACESYSGOOD option.


-- 
ldv

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Φώτης Βαλασιάδης]

This was during the early days of the program I was implementing, I 
later found out I needed PTRACE_O_TRACESYSGOOD anyways as the manual 
suggests. Still it's something that should be documented! Caused a lot 
of frustration.

Regarding your suggestion, it's great but I have something to point out. 
In the case of PTRACE_EVENT_SECCOMP the union is filled normally, 
without any need for the PTRACE_O_TRACESYSGOOD option to be set. So 
unless I am missing something, please consider including that!

On 24/2/23 20:53, Dmitry V. Levin wrote:
> On Fri, Feb 24, 2023 at 06:31:42PM +0200, Fotios Valasiadis wrote:
>> From: Fotios Valasiadis <fvalasiad@csd.auth.gr>
>>
>> Fixed incomplete doc. PTRACE_GET_SYSCALL_INFO's description wouldn't inform the user that they need to enable PTRACE_O_TRACESYSGOOD to get detailed information from said operation.
>>
>> Came upon this bug after writing a test program using PTRACE_O_TRACESYSGOOD. After failing to find what's wrong I posted a stackoverflow question which you can find right here: https://stackoverflow.com/questions/72410182/ptrace-get-syscall-info-always-returns-info-op-as-ptrace-syscall-info-none
>>
>> Nate Eldredge found out what's wrong by looking into the kernel's source code, here is a link to the relevant part https://github.com/torvalds/linux/blob/8291eaafed36f575f23951f3ce18407f480e9ecf/kernel/ptrace.c#L1018
>>
>> In the code it can be seen that the union is filled if and only if the signal matches "SIGTRAP | 0x80", a signal which is only sent if the PTRACE_O_TRACESYSGOOD option is set. You can read about that in the PTRACE_O_TRACESYSGOOD section of ptrace.2 's manual.
>>
>> I am unaware if Nate wants to be included as a co-author of this commit, nor am I aware of any way to contact him.
> Cc'ed Nate just in case.
>
>> Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
>> ---
>>   man2/ptrace.2 | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/man2/ptrace.2 b/man2/ptrace.2
>> index 55d9fd36d..b437b4f44 100644
>> --- a/man2/ptrace.2
>> +++ b/man2/ptrace.2
>> @@ -1033,6 +1033,11 @@ If the size of the data to be written by the kernel exceeds the size
>>   specified by the
>>   .I addr
>>   argument, the output data is truncated.
>> +To obtain complete information during system call entry or exit stops,
>> +you should enable the
>> +.B PTRACE_O_TRACESYSGOOD
>> +option using
>> +.B PTRACE_SETOPTIONS.
>>   .IP
>>   The
>>   .I ptrace_syscall_info
> I suggest the following wording:
>
> diff --git a/man2/ptrace.2 b/man2/ptrace.2
> index 55d9fd36d..496d8fae0 100644
> --- a/man2/ptrace.2
> +++ b/man2/ptrace.2
> @@ -1111,6 +1111,15 @@ stop.
>   .B PTRACE_SYSCALL_INFO_NONE
>   No component of the union contains relevant information.
>   .RE
> +.IP
> +Note that the data returned by
> +.B PTRACE_GET_SYSCALL_INFO
> +is limited to type
> +.B
> +PTRACE_SYSCALL_INFO_NONE
> +unless
> +.B PTRACE_O_TRACESYSGOOD
> +option is set before the corresponding ptrace stop has occurred.
>   .\"
>   .SS Death under ptrace
>   When a (possibly multithreaded) process receives a killing signal
>
> As written in the manual page, using the PTRACE_O_TRACESYSGOOD option is
> the recommended method to distinguish syscall-stops from other kinds of
> ptrace-stops, since it is reliable and does not incur a performance
> penalty.  In other words, if you use ptrace(2) at all, please consider
> using PTRACE_O_TRACESYSGOOD option.
>
>

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Dmitry V. Levin]

On Fri, Feb 24, 2023 at 09:11:55PM +0200, Φώτης Βαλασιάδης wrote:
> This was during the early days of the program I was implementing, I 
> later found out I needed PTRACE_O_TRACESYSGOOD anyways as the manual 
> suggests. Still it's something that should be documented! Caused a lot 
> of frustration.
> 
> Regarding your suggestion, it's great but I have something to point out. 
> In the case of PTRACE_EVENT_SECCOMP the union is filled normally, 
> without any need for the PTRACE_O_TRACESYSGOOD option to be set. So 
> unless I am missing something, please consider including that!

Correct, to get PTRACE_SYSCALL_INFO_SECCOMP
one has to set PTRACE_O_TRACESECCOMP option, and to get
PTRACE_SYSCALL_INFO_ENTRY/PTRACE_SYSCALL_INFO_EXIT
one has to set PTRACE_O_TRACESYSGOOD option.

> On 24/2/23 20:53, Dmitry V. Levin wrote:
> > On Fri, Feb 24, 2023 at 06:31:42PM +0200, Fotios Valasiadis wrote:
> >> From: Fotios Valasiadis <fvalasiad@csd.auth.gr>
> >>
> >> Fixed incomplete doc. PTRACE_GET_SYSCALL_INFO's description wouldn't inform the user that they need to enable PTRACE_O_TRACESYSGOOD to get detailed information from said operation.
> >>
> >> Came upon this bug after writing a test program using PTRACE_O_TRACESYSGOOD. After failing to find what's wrong I posted a stackoverflow question which you can find right here: https://stackoverflow.com/questions/72410182/ptrace-get-syscall-info-always-returns-info-op-as-ptrace-syscall-info-none
> >>
> >> Nate Eldredge found out what's wrong by looking into the kernel's source code, here is a link to the relevant part https://github.com/torvalds/linux/blob/8291eaafed36f575f23951f3ce18407f480e9ecf/kernel/ptrace.c#L1018
> >>
> >> In the code it can be seen that the union is filled if and only if the signal matches "SIGTRAP | 0x80", a signal which is only sent if the PTRACE_O_TRACESYSGOOD option is set. You can read about that in the PTRACE_O_TRACESYSGOOD section of ptrace.2 's manual.
> >>
> >> I am unaware if Nate wants to be included as a co-author of this commit, nor am I aware of any way to contact him.
> > Cc'ed Nate just in case.
> >
> >> Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
> >> ---
> >>   man2/ptrace.2 | 5 +++++
> >>   1 file changed, 5 insertions(+)
> >>
> >> diff --git a/man2/ptrace.2 b/man2/ptrace.2
> >> index 55d9fd36d..b437b4f44 100644
> >> --- a/man2/ptrace.2
> >> +++ b/man2/ptrace.2
> >> @@ -1033,6 +1033,11 @@ If the size of the data to be written by the kernel exceeds the size
> >>   specified by the
> >>   .I addr
> >>   argument, the output data is truncated.
> >> +To obtain complete information during system call entry or exit stops,
> >> +you should enable the
> >> +.B PTRACE_O_TRACESYSGOOD
> >> +option using
> >> +.B PTRACE_SETOPTIONS.
> >>   .IP
> >>   The
> >>   .I ptrace_syscall_info
> > I suggest the following wording:
> >
> > diff --git a/man2/ptrace.2 b/man2/ptrace.2
> > index 55d9fd36d..496d8fae0 100644
> > --- a/man2/ptrace.2
> > +++ b/man2/ptrace.2
> > @@ -1111,6 +1111,15 @@ stop.
> >   .B PTRACE_SYSCALL_INFO_NONE
> >   No component of the union contains relevant information.
> >   .RE
> > +.IP
> > +Note that the data returned by
> > +.B PTRACE_GET_SYSCALL_INFO
> > +is limited to type
> > +.B
> > +PTRACE_SYSCALL_INFO_NONE
> > +unless
> > +.B PTRACE_O_TRACESYSGOOD
> > +option is set before the corresponding ptrace stop has occurred.
> >   .\"
> >   .SS Death under ptrace
> >   When a (possibly multithreaded) process receives a killing signal
> >
> > As written in the manual page, using the PTRACE_O_TRACESYSGOOD option is
> > the recommended method to distinguish syscall-stops from other kinds of
> > ptrace-stops, since it is reliable and does not incur a performance
> > penalty.  In other words, if you use ptrace(2) at all, please consider
> > using PTRACE_O_TRACESYSGOOD option.
> >
> >

-- 
ldv

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Φώτης Βαλασιάδης]

So, what about this?

diff --git a/man2/ptrace.2 b/man2/ptrace.2
index 55d9fd36d..e5f49c289 100644
--- a/man2/ptrace.2
+++ b/man2/ptrace.2
@@ -1111,6 +1111,16 @@ stop.
  .B PTRACE_SYSCALL_INFO_NONE
  No component of the union contains relevant information.
  .RE
+.IP
+Note that in case of
+.B PTRACE_SYSCALL
+syscall entry or exit stops, the data returned by
+.B PTRACE_GET_SYSCALL_INFO
+is limited to type
+.B PTRACE_SYSCALL_INFO_NONE
+unless
+.B PTRACE_O_TRACESYSGOOD
+option is set before the corresponding ptrace stop has occurred.
  .\"
  .SS Death under ptrace
  When a (possibly multithreaded) process receives a killing signal

On 25/2/23 00:05, Dmitry V. Levin wrote:

> On Fri, Feb 24, 2023 at 09:11:55PM +0200, Φώτης Βαλασιάδης wrote:
>> This was during the early days of the program I was implementing, I
>> later found out I needed PTRACE_O_TRACESYSGOOD anyways as the manual
>> suggests. Still it's something that should be documented! Caused a lot
>> of frustration.
>>
>> Regarding your suggestion, it's great but I have something to point out.
>> In the case of PTRACE_EVENT_SECCOMP the union is filled normally,
>> without any need for the PTRACE_O_TRACESYSGOOD option to be set. So
>> unless I am missing something, please consider including that!
> Correct, to get PTRACE_SYSCALL_INFO_SECCOMP
> one has to set PTRACE_O_TRACESECCOMP option, and to get
> PTRACE_SYSCALL_INFO_ENTRY/PTRACE_SYSCALL_INFO_EXIT
> one has to set PTRACE_O_TRACESYSGOOD option.
>
>> On 24/2/23 20:53, Dmitry V. Levin wrote:
>>> On Fri, Feb 24, 2023 at 06:31:42PM +0200, Fotios Valasiadis wrote:
>>>> From: Fotios Valasiadis <fvalasiad@csd.auth.gr>
>>>>
>>>> Fixed incomplete doc. PTRACE_GET_SYSCALL_INFO's description wouldn't inform the user that they need to enable PTRACE_O_TRACESYSGOOD to get detailed information from said operation.
>>>>
>>>> Came upon this bug after writing a test program using PTRACE_O_TRACESYSGOOD. After failing to find what's wrong I posted a stackoverflow question which you can find right here: https://stackoverflow.com/questions/72410182/ptrace-get-syscall-info-always-returns-info-op-as-ptrace-syscall-info-none
>>>>
>>>> Nate Eldredge found out what's wrong by looking into the kernel's source code, here is a link to the relevant part https://github.com/torvalds/linux/blob/8291eaafed36f575f23951f3ce18407f480e9ecf/kernel/ptrace.c#L1018
>>>>
>>>> In the code it can be seen that the union is filled if and only if the signal matches "SIGTRAP | 0x80", a signal which is only sent if the PTRACE_O_TRACESYSGOOD option is set. You can read about that in the PTRACE_O_TRACESYSGOOD section of ptrace.2 's manual.
>>>>
>>>> I am unaware if Nate wants to be included as a co-author of this commit, nor am I aware of any way to contact him.
>>> Cc'ed Nate just in case.
>>>
>>>> Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
>>>> ---
>>>>    man2/ptrace.2 | 5 +++++
>>>>    1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/man2/ptrace.2 b/man2/ptrace.2
>>>> index 55d9fd36d..b437b4f44 100644
>>>> --- a/man2/ptrace.2
>>>> +++ b/man2/ptrace.2
>>>> @@ -1033,6 +1033,11 @@ If the size of the data to be written by the kernel exceeds the size
>>>>    specified by the
>>>>    .I addr
>>>>    argument, the output data is truncated.
>>>> +To obtain complete information during system call entry or exit stops,
>>>> +you should enable the
>>>> +.B PTRACE_O_TRACESYSGOOD
>>>> +option using
>>>> +.B PTRACE_SETOPTIONS.
>>>>    .IP
>>>>    The
>>>>    .I ptrace_syscall_info
>>> I suggest the following wording:
>>>
>>> diff --git a/man2/ptrace.2 b/man2/ptrace.2
>>> index 55d9fd36d..496d8fae0 100644
>>> --- a/man2/ptrace.2
>>> +++ b/man2/ptrace.2
>>> @@ -1111,6 +1111,15 @@ stop.
>>>    .B PTRACE_SYSCALL_INFO_NONE
>>>    No component of the union contains relevant information.
>>>    .RE
>>> +.IP
>>> +Note that the data returned by
>>> +.B PTRACE_GET_SYSCALL_INFO
>>> +is limited to type
>>> +.B
>>> +PTRACE_SYSCALL_INFO_NONE
>>> +unless
>>> +.B PTRACE_O_TRACESYSGOOD
>>> +option is set before the corresponding ptrace stop has occurred.
>>>    .\"
>>>    .SS Death under ptrace
>>>    When a (possibly multithreaded) process receives a killing signal
>>>
>>> As written in the manual page, using the PTRACE_O_TRACESYSGOOD option is
>>> the recommended method to distinguish syscall-stops from other kinds of
>>> ptrace-stops, since it is reliable and does not incur a performance
>>> penalty.  In other words, if you use ptrace(2) at all, please consider
>>> using PTRACE_O_TRACESYSGOOD option.
>>>
>>>

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Dmitry V. Levin]

On Sat, Feb 25, 2023 at 01:05:24AM +0200, Φώτης Βαλασιάδης wrote:
> So, what about this?
> 
> diff --git a/man2/ptrace.2 b/man2/ptrace.2
> index 55d9fd36d..e5f49c289 100644
> --- a/man2/ptrace.2
> +++ b/man2/ptrace.2
> @@ -1111,6 +1111,16 @@ stop.
>   .B PTRACE_SYSCALL_INFO_NONE
>   No component of the union contains relevant information.
>   .RE
> +.IP
> +Note that in case of
> +.B PTRACE_SYSCALL
> +syscall entry or exit stops, the data returned by

I'm not sure about mentioning PTRACE_SYSCALL in this context as it's not
the only way to have the tracee stopped at a syscall stop.

> +.B PTRACE_GET_SYSCALL_INFO
> +is limited to type
> +.B PTRACE_SYSCALL_INFO_NONE
> +unless
> +.B PTRACE_O_TRACESYSGOOD
> +option is set before the corresponding ptrace stop has occurred.
>   .\"
>   .SS Death under ptrace
>   When a (possibly multithreaded) process receives a killing signal

-- 
ldv

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Φώτης Βαλασιάδης]

Better?

diff --git a/man2/ptrace.2 b/man2/ptrace.2
index 55d9fd36d..ad0543b0b 100644
--- a/man2/ptrace.2
+++ b/man2/ptrace.2
@@ -1111,6 +1111,15 @@ stop.
  .B PTRACE_SYSCALL_INFO_NONE
  No component of the union contains relevant information.
  .RE
+.IP
+Note that in case of
+syscall entry or exit stops, the data returned by
+.B PTRACE_GET_SYSCALL_INFO
+is limited to type
+.B PTRACE_SYSCALL_INFO_NONE
+unless
+.B PTRACE_O_TRACESYSGOOD
+option is set before the corresponding ptrace stop has occurred.
  .\"
  .SS Death under ptrace
  When a (possibly multithreaded) process receives a killing signal

On 25/2/23 01:31, Dmitry V. Levin wrote:
> On Sat, Feb 25, 2023 at 01:05:24AM +0200, Φώτης Βαλασιάδης wrote:
>> So, what about this?
>>
>> diff --git a/man2/ptrace.2 b/man2/ptrace.2
>> index 55d9fd36d..e5f49c289 100644
>> --- a/man2/ptrace.2
>> +++ b/man2/ptrace.2
>> @@ -1111,6 +1111,16 @@ stop.
>>    .B PTRACE_SYSCALL_INFO_NONE
>>    No component of the union contains relevant information.
>>    .RE
>> +.IP
>> +Note that in case of
>> +.B PTRACE_SYSCALL
>> +syscall entry or exit stops, the data returned by
> I'm not sure about mentioning PTRACE_SYSCALL in this context as it's not
> the only way to have the tracee stopped at a syscall stop.
>
>> +.B PTRACE_GET_SYSCALL_INFO
>> +is limited to type
>> +.B PTRACE_SYSCALL_INFO_NONE
>> +unless
>> +.B PTRACE_O_TRACESYSGOOD
>> +option is set before the corresponding ptrace stop has occurred.
>>    .\"
>>    .SS Death under ptrace
>>    When a (possibly multithreaded) process receives a killing signal

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Dmitry V. Levin]

On Sat, Feb 25, 2023 at 01:43:18AM +0200, Φώτης Βαλασιάδης wrote:
> Better?
> 
> diff --git a/man2/ptrace.2 b/man2/ptrace.2
> index 55d9fd36d..ad0543b0b 100644
> --- a/man2/ptrace.2
> +++ b/man2/ptrace.2
> @@ -1111,6 +1111,15 @@ stop.
>   .B PTRACE_SYSCALL_INFO_NONE
>   No component of the union contains relevant information.
>   .RE
> +.IP
> +Note that in case of
> +syscall entry or exit stops, the data returned by
> +.B PTRACE_GET_SYSCALL_INFO
> +is limited to type
> +.B PTRACE_SYSCALL_INFO_NONE
> +unless
> +.B PTRACE_O_TRACESYSGOOD
> +option is set before the corresponding ptrace stop has occurred.
>   .\"
>   .SS Death under ptrace
>   When a (possibly multithreaded) process receives a killing signal

LGTM, thanks.


-- 
ldv

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Alex Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 1108 bytes --]

Hi Dmitry!

On 2/25/23 01:08, Dmitry V. Levin wrote:
> On Sat, Feb 25, 2023 at 01:43:18AM +0200, Φώτης Βαλασιάδης wrote:
>> Better?
>>
>> diff --git a/man2/ptrace.2 b/man2/ptrace.2
>> index 55d9fd36d..ad0543b0b 100644
>> --- a/man2/ptrace.2
>> +++ b/man2/ptrace.2
>> @@ -1111,6 +1111,15 @@ stop.
>>    .B PTRACE_SYSCALL_INFO_NONE
>>    No component of the union contains relevant information.
>>    .RE
>> +.IP
>> +Note that in case of
>> +syscall entry or exit stops, the data returned by
>> +.B PTRACE_GET_SYSCALL_INFO
>> +is limited to type
>> +.B PTRACE_SYSCALL_INFO_NONE
>> +unless
>> +.B PTRACE_O_TRACESYSGOOD
>> +option is set before the corresponding ptrace stop has occurred.
>>    .\"
>>    .SS Death under ptrace
>>    When a (possibly multithreaded) process receives a killing signal
> 
> LGTM, thanks.

Ahh, I see you already CCd Nate.  Thanks!

Thanks for the review!  I should take that as an Acked-by?

Cheers,

Alex

> 
> 

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Dmitry V. Levin]

Hi Alex,

On Sat, Feb 25, 2023 at 02:21:51AM +0100, Alex Colomar wrote:
> Hi Dmitry!
> 
> On 2/25/23 01:08, Dmitry V. Levin wrote:
> > On Sat, Feb 25, 2023 at 01:43:18AM +0200, Φώτης Βαλασιάδης wrote:
> >> Better?
> >>
> >> diff --git a/man2/ptrace.2 b/man2/ptrace.2
> >> index 55d9fd36d..ad0543b0b 100644
> >> --- a/man2/ptrace.2
> >> +++ b/man2/ptrace.2
> >> @@ -1111,6 +1111,15 @@ stop.
> >>    .B PTRACE_SYSCALL_INFO_NONE
> >>    No component of the union contains relevant information.
> >>    .RE
> >> +.IP
> >> +Note that in case of
> >> +syscall entry or exit stops, the data returned by
> >> +.B PTRACE_GET_SYSCALL_INFO
> >> +is limited to type
> >> +.B PTRACE_SYSCALL_INFO_NONE
> >> +unless
> >> +.B PTRACE_O_TRACESYSGOOD
> >> +option is set before the corresponding ptrace stop has occurred.
> >>    .\"
> >>    .SS Death under ptrace
> >>    When a (possibly multithreaded) process receives a killing signal
> > 
> > LGTM, thanks.
> 
> Ahh, I see you already CCd Nate.  Thanks!
> 
> Thanks for the review!  I should take that as an Acked-by?

Sure, feel free to add:

Reviewed-by: Dmitry V. Levin <ldv@strace.io>


-- 
ldv

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Alex Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2155 bytes --]

On 2/24/23 17:31, Fotios Valasiadis wrote:
> From: Fotios Valasiadis <fvalasiad@csd.auth.gr>
> 
> Fixed incomplete doc. PTRACE_GET_SYSCALL_INFO's description wouldn't inform the user that they need to enable PTRACE_O_TRACESYSGOOD to get detailed information from said operation.
> 
> Came upon this bug after writing a test program using PTRACE_O_TRACESYSGOOD. After failing to find what's wrong I posted a stackoverflow question which you can find right here: https://stackoverflow.com/questions/72410182/ptrace-get-syscall-info-always-returns-info-op-as-ptrace-syscall-info-none
> 
> Nate Eldredge found out what's wrong by looking into the kernel's source code, here is a link to the relevant part https://github.com/torvalds/linux/blob/8291eaafed36f575f23951f3ce18407f480e9ecf/kernel/ptrace.c#L1018
> 
> In the code it can be seen that the union is filled if and only if the signal matches "SIGTRAP | 0x80", a signal which is only sent if the PTRACE_O_TRACESYSGOOD option is set. You can read about that in the PTRACE_O_TRACESYSGOOD section of ptrace.2 's manual.
> 
> I am unaware if Nate wants to be included as a co-author of this commit, nor am I aware of any way to contact him.

Hello Fotios,

I found his address in a kernel commit:

Nate Eldredge <nate@thatsmathematics.com>

I'm CCing him in case he wants to review.

Thanks for the patch!

Alex

> 
> Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
> ---
>   man2/ptrace.2 | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/man2/ptrace.2 b/man2/ptrace.2
> index 55d9fd36d..b437b4f44 100644
> --- a/man2/ptrace.2
> +++ b/man2/ptrace.2
> @@ -1033,6 +1033,11 @@ If the size of the data to be written by the kernel exceeds the size
>   specified by the
>   .I addr
>   argument, the output data is truncated.
> +To obtain complete information during system call entry or exit stops,
> +you should enable the
> +.B PTRACE_O_TRACESYSGOOD
> +option using
> +.B PTRACE_SETOPTIONS.
>   .IP
>   The
>   .I ptrace_syscall_info

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Φώτης Βαλασιάδης]

Hello Alex!

Good! I will wait a day or two before submitting a new patch the way we 
agreed with Dmitry! In case Nate responds!

On 25/2/23 03:18, Alex Colomar wrote:
> On 2/24/23 17:31, Fotios Valasiadis wrote:
>> From: Fotios Valasiadis <fvalasiad@csd.auth.gr>
>>
>> Fixed incomplete doc. PTRACE_GET_SYSCALL_INFO's description wouldn't 
>> inform the user that they need to enable PTRACE_O_TRACESYSGOOD to get 
>> detailed information from said operation.
>>
>> Came upon this bug after writing a test program using 
>> PTRACE_O_TRACESYSGOOD. After failing to find what's wrong I posted a 
>> stackoverflow question which you can find right here: 
>> https://stackoverflow.com/questions/72410182/ptrace-get-syscall-info-always-returns-info-op-as-ptrace-syscall-info-none
>>
>> Nate Eldredge found out what's wrong by looking into the kernel's 
>> source code, here is a link to the relevant part 
>> https://github.com/torvalds/linux/blob/8291eaafed36f575f23951f3ce18407f480e9ecf/kernel/ptrace.c#L1018
>>
>> In the code it can be seen that the union is filled if and only if 
>> the signal matches "SIGTRAP | 0x80", a signal which is only sent if 
>> the PTRACE_O_TRACESYSGOOD option is set. You can read about that in 
>> the PTRACE_O_TRACESYSGOOD section of ptrace.2 's manual.
>>
>> I am unaware if Nate wants to be included as a co-author of this 
>> commit, nor am I aware of any way to contact him.
>
> Hello Fotios,
>
> I found his address in a kernel commit:
>
> Nate Eldredge <nate@thatsmathematics.com>
>
> I'm CCing him in case he wants to review.
>
> Thanks for the patch!
>
> Alex
>
>>
>> Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
>> ---
>>   man2/ptrace.2 | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/man2/ptrace.2 b/man2/ptrace.2
>> index 55d9fd36d..b437b4f44 100644
>> --- a/man2/ptrace.2
>> +++ b/man2/ptrace.2
>> @@ -1033,6 +1033,11 @@ If the size of the data to be written by the 
>> kernel exceeds the size
>>   specified by the
>>   .I addr
>>   argument, the output data is truncated.
>> +To obtain complete information during system call entry or exit stops,
>> +you should enable the
>> +.B PTRACE_O_TRACESYSGOOD
>> +option using
>> +.B PTRACE_SETOPTIONS.
>>   .IP
>>   The
>>   .I ptrace_syscall_info
>

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Nate Eldredge]

On Sat, 25 Feb 2023, Alex Colomar wrote:

> On 2/24/23 17:31, Fotios Valasiadis wrote:
>> From: Fotios Valasiadis <fvalasiad@csd.auth.gr>
>> 
>> Fixed incomplete doc. PTRACE_GET_SYSCALL_INFO's description wouldn't inform 
>> the user that they need to enable PTRACE_O_TRACESYSGOOD to get detailed 
>> information from said operation.
>> 
>> Came upon this bug after writing a test program using 
>> PTRACE_O_TRACESYSGOOD. After failing to find what's wrong I posted a 
>> stackoverflow question which you can find right here: 
>> https://stackoverflow.com/questions/72410182/ptrace-get-syscall-info-always-returns-info-op-as-ptrace-syscall-info-none
>> 
>> Nate Eldredge found out what's wrong by looking into the kernel's source 
>> code, here is a link to the relevant part 
>> https://github.com/torvalds/linux/blob/8291eaafed36f575f23951f3ce18407f480e9ecf/kernel/ptrace.c#L1018
>> 
>> In the code it can be seen that the union is filled if and only if the 
>> signal matches "SIGTRAP | 0x80", a signal which is only sent if the 
>> PTRACE_O_TRACESYSGOOD option is set. You can read about that in the 
>> PTRACE_O_TRACESYSGOOD section of ptrace.2 's manual.
>> 
>> I am unaware if Nate wants to be included as a co-author of this commit, 
>> nor am I aware of any way to contact him.
>
> Hello Fotios,
>
> I found his address in a kernel commit:
>
> Nate Eldredge <nate@thatsmathematics.com>
>
> I'm CCing him in case he wants to review.

Hi everyone, I think it's a good clear explanation.  Thanks for taking the 
time to write the patch!  No need to include me as coauthor.

> Thanks for the patch!
>
> Alex
>
>> 
>> Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
>> ---
>>   man2/ptrace.2 | 5 +++++
>>   1 file changed, 5 insertions(+)
>> 
>> diff --git a/man2/ptrace.2 b/man2/ptrace.2
>> index 55d9fd36d..b437b4f44 100644
>> --- a/man2/ptrace.2
>> +++ b/man2/ptrace.2
>> @@ -1033,6 +1033,11 @@ If the size of the data to be written by the kernel 
>> exceeds the size
>>   specified by the
>>   .I addr
>>   argument, the output data is truncated.
>> +To obtain complete information during system call entry or exit stops,
>> +you should enable the
>> +.B PTRACE_O_TRACESYSGOOD
>> +option using
>> +.B PTRACE_SETOPTIONS.
>>   .IP
>>   The
>>   .I ptrace_syscall_info
>
> -- 
> <http://www.alejandro-colomar.es/>
> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
>
>

-- 
Nate Eldredge
nate@thatsmathematics.com

[PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Fotios Valasiadis]

Fixed incomplete doc. PTRACE_GET_SYSCALL_INFO wouldn't inform the user that they need to enable PTRACE_O_TRACESYSGOOD to get detailed information from said operation.

Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
Cowritten-by: Dmitry V. Levin <ldv@strace.io>
---
 man2/ptrace.2 | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/man2/ptrace.2 b/man2/ptrace.2
index 55d9fd36d..ad0543b0b 100644
--- a/man2/ptrace.2
+++ b/man2/ptrace.2
@@ -1111,6 +1111,15 @@ stop.
 .B PTRACE_SYSCALL_INFO_NONE
 No component of the union contains relevant information.
 .RE
+.IP
+Note that in case of
+syscall entry or exit stops, the data returned by
+.B PTRACE_GET_SYSCALL_INFO
+is limited to type
+.B PTRACE_SYSCALL_INFO_NONE
+unless
+.B PTRACE_O_TRACESYSGOOD
+option is set before the corresponding ptrace stop has occurred.
 .\"
 .SS Death under ptrace
 When a (possibly multithreaded) process receives a killing signal
-- 
2.39.2

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Dmitry V . Levin]

On Sat, Feb 25, 2023 at 04:42:12AM +0200, Fotios Valasiadis wrote:
> Fixed incomplete doc. PTRACE_GET_SYSCALL_INFO wouldn't inform the user that they need to enable PTRACE_O_TRACESYSGOOD to get detailed information from said operation.

I'm not sure about the word "fix" in this context as we are not
correcting some wrong information but simply extending the documentation.

How about the following wording:

Document the role of PTRACE_O_TRACESYSGOOD option in connection with
PTRACE_GET_SYSCALL_INFO.

> Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
> Cowritten-by: Dmitry V. Levin <ldv@strace.io>

Feel free to add
Complements: fc91449cb "ptrace.2: Document PTRACE_GET_SYSCALL_INFO"

> ---
>  man2/ptrace.2 | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/man2/ptrace.2 b/man2/ptrace.2
> index 55d9fd36d..ad0543b0b 100644
> --- a/man2/ptrace.2
> +++ b/man2/ptrace.2
> @@ -1111,6 +1111,15 @@ stop.
>  .B PTRACE_SYSCALL_INFO_NONE
>  No component of the union contains relevant information.
>  .RE
> +.IP
> +Note that in case of
> +syscall entry or exit stops, the data returned by
> +.B PTRACE_GET_SYSCALL_INFO
> +is limited to type
> +.B PTRACE_SYSCALL_INFO_NONE
> +unless
> +.B PTRACE_O_TRACESYSGOOD
> +option is set before the corresponding ptrace stop has occurred.
>  .\"
>  .SS Death under ptrace
>  When a (possibly multithreaded) process receives a killing signal
> -- 
> 2.39.2

-- 
ldv

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Φώτης Βαλασιάδης]

On 25/2/23 12:10, Dmitry V . Levin wrote:
> I'm not sure about the word "fix" in this context as we are not
> correcting some wrong information but simply extending the documentation.
>
> How about the following wording:
>
> Document the role of PTRACE_O_TRACESYSGOOD option in connection with
> PTRACE_GET_SYSCALL_INFO.

Sure! Do I use Cowritten-by, Acked-by or Reviewed-by?

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Dmitry V . Levin]

On Sat, Feb 25, 2023 at 12:33:15PM +0200, Φώτης Βαλασιάδης wrote:
> On 25/2/23 12:10, Dmitry V . Levin wrote:
> > I'm not sure about the word "fix" in this context as we are not
> > correcting some wrong information but simply extending the documentation.
> >
> > How about the following wording:
> >
> > Document the role of PTRACE_O_TRACESYSGOOD option in connection with
> > PTRACE_GET_SYSCALL_INFO.
> 
> Sure! Do I use Cowritten-by, Acked-by or Reviewed-by?

Cowritten-by seems to suit better in this case.


-- 
ldv

[PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Fotios Valasiadis]

Document the role of PTRACE_O_TRACESYSGOOD option in connection with PTRACE_GET_SYSCALL_INFO.

Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
Cowritten-by: Dmitry V. Levin <ldv@strace.io>
Complements: fc91449cb "ptrace.2: Document PTRACE_GET_SYSCALL_INFO"
---
 man2/ptrace.2 | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/man2/ptrace.2 b/man2/ptrace.2
index 55d9fd36d..ad0543b0b 100644
--- a/man2/ptrace.2
+++ b/man2/ptrace.2
@@ -1111,6 +1111,15 @@ stop.
 .B PTRACE_SYSCALL_INFO_NONE
 No component of the union contains relevant information.
 .RE
+.IP
+Note that in case of
+syscall entry or exit stops, the data returned by
+.B PTRACE_GET_SYSCALL_INFO
+is limited to type
+.B PTRACE_SYSCALL_INFO_NONE
+unless
+.B PTRACE_O_TRACESYSGOOD
+option is set before the corresponding ptrace stop has occurred.
 .\"
 .SS Death under ptrace
 When a (possibly multithreaded) process receives a killing signal
-- 
2.39.2

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2057 bytes --]

Hi Fotios,

On 2/25/23 11:56, Fotios Valasiadis wrote:
> Document the role of PTRACE_O_TRACESYSGOOD option in connection with PTRACE_GET_SYSCALL_INFO.
> 
> Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
> Cowritten-by: Dmitry V. Levin <ldv@strace.io>
> Complements: fc91449cb "ptrace.2: Document PTRACE_GET_SYSCALL_INFO"
> ---
>  man2/ptrace.2 | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/man2/ptrace.2 b/man2/ptrace.2
> index 55d9fd36d..ad0543b0b 100644
> --- a/man2/ptrace.2
> +++ b/man2/ptrace.2
> @@ -1111,6 +1111,15 @@ stop.
>  .B PTRACE_SYSCALL_INFO_NONE
>  No component of the union contains relevant information.
>  .RE
> +.IP
> +Note that in case of

"Note that" is usually redundant.
See:
<https://lore.kernel.org/linux-man/20210729223535.qvyomfqvvahzmu5w@localhost.localdomain/>
<https://lore.kernel.org/linux-man/20230105225235.6cjtz6orjzxzvo6v@illithid/>

> +syscall entry or exit stops, the data returned by

Please use semantic newlines.  See man-pages(7):

   Use semantic newlines
       In  the source of a manual page, new sentences should be started on new
       lines, long sentences should be split into lines at clause breaks (com‐
       mas, semicolons, colons, and so on), and long clauses should  be  split
       at  phrase  boundaries.   This convention, sometimes known as "semantic
       newlines", makes it easier to see the effect of  patches,  which  often
       operate at the level of individual sentences, clauses, or phrases.


> +.B PTRACE_GET_SYSCALL_INFO
> +is limited to type
> +.B PTRACE_SYSCALL_INFO_NONE
> +unless
> +.B PTRACE_O_TRACESYSGOOD
> +option is set before the corresponding ptrace stop has occurred.

You should say
.BR ptrace ()
right?
Or is unformatted ptrace common in this page?

Cheers,

Alex

>  .\"
>  .SS Death under ptrace
>  When a (possibly multithreaded) process receives a killing signal

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Dmitry V . Levin]

On Sun, Feb 26, 2023 at 10:58:02PM +0100, Alejandro Colomar wrote:
[...]
> > +.B PTRACE_GET_SYSCALL_INFO
> > +is limited to type
> > +.B PTRACE_SYSCALL_INFO_NONE
> > +unless
> > +.B PTRACE_O_TRACESYSGOOD
> > +option is set before the corresponding ptrace stop has occurred.
> 
> You should say
> .BR ptrace ()
> right?
> Or is unformatted ptrace common in this page?

Or just say "syscall stop".


-- 
ldv

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 759 bytes --]

Hi Dmitry,

On 2/26/23 23:03, Dmitry V . Levin wrote:
> On Sun, Feb 26, 2023 at 10:58:02PM +0100, Alejandro Colomar wrote:
> [...]
>>> +.B PTRACE_GET_SYSCALL_INFO
>>> +is limited to type
>>> +.B PTRACE_SYSCALL_INFO_NONE
>>> +unless
>>> +.B PTRACE_O_TRACESYSGOOD
>>> +option is set before the corresponding ptrace stop has occurred.
>>
>> You should say
>> .BR ptrace ()
>> right?
>> Or is unformatted ptrace common in this page?
> 
> Or just say "syscall stop".

Sure, that would work.  BTW, se prefer system call over syscall
(there's not much consistency regarding that, but let's try to achieve it).

Thanks,

Alex

> 
> 

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Φώτης Βαλασιάδης]

Ahhhh hello everyone! Give me 20 minutes and I will make the changes as 
requested!

By the way this patch is the very first patch I do through emails! I am 
using git format-patch and git send-email, is it okay for me to be 
opening a new thread for each change you request? Or should I send the 
new patches in the same thread as responses?

Is there a universal standard or is it per project? Any guidance shall 
be greatly appreciated!

Thanks!

-- fvalasiad --

On 27/2/23 00:05, Alejandro Colomar wrote:
> Hi Dmitry,
>
> On 2/26/23 23:03, Dmitry V . Levin wrote:
>> On Sun, Feb 26, 2023 at 10:58:02PM +0100, Alejandro Colomar wrote:
>> [...]
>>>> +.B PTRACE_GET_SYSCALL_INFO
>>>> +is limited to type
>>>> +.B PTRACE_SYSCALL_INFO_NONE
>>>> +unless
>>>> +.B PTRACE_O_TRACESYSGOOD
>>>> +option is set before the corresponding ptrace stop has occurred.
>>> You should say
>>> .BR ptrace ()
>>> right?
>>> Or is unformatted ptrace common in this page?
>> Or just say "syscall stop".
> Sure, that would work.  BTW, se prefer system call over syscall
> (there's not much consistency regarding that, but let's try to achieve it).
>
> Thanks,
>
> Alex
>
>>

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2443 bytes --]

Hi Φώτης,

On 2/26/23 23:14, Φώτης Βαλασιάδης wrote:
> Ahhhh hello everyone! Give me 20 minutes and I will make the changes as 
> requested!
> 
> By the way this patch is the very first patch I do through emails! I am 
> using git format-patch and git send-email, is it okay for me to be 
> opening a new thread for each change you request? Or should I send the 
> new patches in the same thread as responses?

It is good to keep them in the same thread,
which you can do with --in-reply-to= in git-format-patch(1).
In that case, I usually make it a reply of the previous patch
(not replies to it), or of the cover letter for patch sets.

That makes it easy for someone in the future to find stuff in
the mailing list.  For me right now it's not so much of a
problem, and I usually don't even check if someone made it a
reply or not; it's just a matter of how useful it will be in
the future (for insignificant patches I just send new threads).

> 
> Is there a universal standard or is it per project? Any guidance shall 
> be greatly appreciated!

I'd say there's no standards, but if you reply to the old thread
by default, it will be better than starting a new thread.  I can't
imagine why some project would want to avoid that.  It's more work
on your side though, so for small patches that just fix a typo,
you may not want to do it.

> 
> Thanks!

Cheers,

Alex

> 
> -- fvalasiad --

P.S.:  If you want to sign the patch with your name in non-Latin]
letters (is that Greek?), that's fine by me.  Whatever you prefer.  ;)

> 
> On 27/2/23 00:05, Alejandro Colomar wrote:
>> Hi Dmitry,
>>
>> On 2/26/23 23:03, Dmitry V . Levin wrote:
>>> On Sun, Feb 26, 2023 at 10:58:02PM +0100, Alejandro Colomar wrote:
>>> [...]
>>>>> +.B PTRACE_GET_SYSCALL_INFO
>>>>> +is limited to type
>>>>> +.B PTRACE_SYSCALL_INFO_NONE
>>>>> +unless
>>>>> +.B PTRACE_O_TRACESYSGOOD
>>>>> +option is set before the corresponding ptrace stop has occurred.
>>>> You should say
>>>> .BR ptrace ()
>>>> right?
>>>> Or is unformatted ptrace common in this page?
>>> Or just say "syscall stop".
>> Sure, that would work.  BTW, se prefer system call over syscall
>> (there's not much consistency regarding that, but let's try to achieve it).
>>
>> Thanks,
>>
>> Alex
>>
>>>

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Φώτης Βαλασιάδης]

Tried my best, hope I did it right!

Thanks for the assist!

And yes, it's Greek! Signing off with my github username most of the time.

Thanks again, here you go!

Βαλασιάδης Φώτιος

On 27/2/23 00:42, Alejandro Colomar wrote:
> Hi Φώτης,
>
> On 2/26/23 23:14, Φώτης Βαλασιάδης wrote:
>> Ahhhh hello everyone! Give me 20 minutes and I will make the changes as
>> requested!
>>
>> By the way this patch is the very first patch I do through emails! I am
>> using git format-patch and git send-email, is it okay for me to be
>> opening a new thread for each change you request? Or should I send the
>> new patches in the same thread as responses?
> It is good to keep them in the same thread,
> which you can do with --in-reply-to= in git-format-patch(1).
> In that case, I usually make it a reply of the previous patch
> (not replies to it), or of the cover letter for patch sets.
>
> That makes it easy for someone in the future to find stuff in
> the mailing list.  For me right now it's not so much of a
> problem, and I usually don't even check if someone made it a
> reply or not; it's just a matter of how useful it will be in
> the future (for insignificant patches I just send new threads).
>
>> Is there a universal standard or is it per project? Any guidance shall
>> be greatly appreciated!
> I'd say there's no standards, but if you reply to the old thread
> by default, it will be better than starting a new thread.  I can't
> imagine why some project would want to avoid that.  It's more work
> on your side though, so for small patches that just fix a typo,
> you may not want to do it.
>
>> Thanks!
> Cheers,
>
> Alex
>
>> -- fvalasiad --
> P.S.:  If you want to sign the patch with your name in non-Latin]
> letters (is that Greek?), that's fine by me.  Whatever you prefer.  ;)
>
>> On 27/2/23 00:05, Alejandro Colomar wrote:
>>> Hi Dmitry,
>>>
>>> On 2/26/23 23:03, Dmitry V . Levin wrote:
>>>> On Sun, Feb 26, 2023 at 10:58:02PM +0100, Alejandro Colomar wrote:
>>>> [...]
>>>>>> +.B PTRACE_GET_SYSCALL_INFO
>>>>>> +is limited to type
>>>>>> +.B PTRACE_SYSCALL_INFO_NONE
>>>>>> +unless
>>>>>> +.B PTRACE_O_TRACESYSGOOD
>>>>>> +option is set before the corresponding ptrace stop has occurred.
>>>>> You should say
>>>>> .BR ptrace ()
>>>>> right?
>>>>> Or is unformatted ptrace common in this page?
>>>> Or just say "syscall stop".
>>> Sure, that would work.  BTW, se prefer system call over syscall
>>> (there's not much consistency regarding that, but let's try to achieve it).
>>>
>>> Thanks,
>>>
>>> Alex
>>>

[PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Fotios Valasiadis]

Document the role of PTRACE_O_TRACESYSGOOD option in connection with PTRACE_GET_SYSCALL_INFO.

Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
Cowritten-by: Dmitry V. Levin <ldv@strace.io>
Complements: fc91449cb "ptrace.2: Document PTRACE_GET_SYSCALL_INFO"
---
 man2/ptrace.2 | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/man2/ptrace.2 b/man2/ptrace.2
index 55d9fd36d..9737b3825 100644
--- a/man2/ptrace.2
+++ b/man2/ptrace.2
@@ -1111,6 +1111,15 @@ stop.
 .B PTRACE_SYSCALL_INFO_NONE
 No component of the union contains relevant information.
 .RE
+.IP
+In case of system call entry or exit stops,
+the data returned by
+.B PTRACE_GET_SYSCALL_INFO
+is limited to type
+.B PTRACE_SYSCALL_INFO_NONE
+unless
+.B PTRACE_O_TRACESYSGOOD
+option is set before the corresponding system call stop has occurred.
 .\"
 .SS Death under ptrace
 When a (possibly multithreaded) process receives a killing signal
-- 
2.39.2

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 4519 bytes --]

Hi Βαλασιάδης Φώτιος,

(did I write your name correctly?
I've seen it previously in the reverse order)

On 2/27/23 00:22, Fotios Valasiadis wrote:
> Document the role of PTRACE_O_TRACESYSGOOD option in connection with PTRACE_GET_SYSCALL_INFO.
> 
> Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
> Cowritten-by: Dmitry V. Levin <ldv@strace.io>
> Complements: fc91449cb "ptrace.2: Document PTRACE_GET_SYSCALL_INFO"

Patch applied.  Thanks!

I tweaked the commit message to include the original one,
which was great.  I forgot to mention this, but please
keep the commit message for revisions of patches; it's
always easier to discard some information later if it's
unnecessary, but usually it's best to keep as much as
possible in the commit message.

> ---
>  man2/ptrace.2 | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/man2/ptrace.2 b/man2/ptrace.2
> index 55d9fd36d..9737b3825 100644
> --- a/man2/ptrace.2
> +++ b/man2/ptrace.2
> @@ -1111,6 +1111,15 @@ stop.
>  .B PTRACE_SYSCALL_INFO_NONE
>  No component of the union contains relevant information.
>  .RE
> +.IP
> +In case of system call entry or exit stops,
> +the data returned by
> +.B PTRACE_GET_SYSCALL_INFO
> +is limited to type
> +.B PTRACE_SYSCALL_INFO_NONE
> +unless
> +.B PTRACE_O_TRACESYSGOOD
> +option is set before the corresponding system call stop has occurred.
>  .\"
>  .SS Death under ptrace
>  When a (possibly multithreaded) process receives a killing signal

On 2/27/23 00:30, Φώτης Βαλασιάδης wrote:
> Tried my best, hope I did it right!
> 
> Thanks for the assist!
> 
> And yes, it's Greek!

:-)

> Signing off with my github username most of the time.

Okay.

> 
> Thanks again, here you go!
> 
> Βαλασιάδης Φώτιος

The applied patch is below:

$ git show
commit f04064d73b9f60f189c490e7ef5c3b9fa5498920 (HEAD -> master)
Author: Fotios Valasiadis <fvalasiad@gmail.com>
Date:   Mon Feb 27 01:22:01 2023 +0200

    ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO
    
    Document the role of PTRACE_O_TRACESYSGOOD option in connection with
    PTRACE_GET_SYSCALL_INFO.
    
    Fixed incomplete doc.  PTRACE_GET_SYSCALL_INFO's description wouldn't
    inform the user that they need to enable PTRACE_O_TRACESYSGOOD to get
    detailed information from said operation.
    
    Came upon this bug after writing a test program using
    PTRACE_O_TRACESYSGOOD.  After failing to find what's wrong I posted a
    stackoverflow question which you can find right here:
    <https://stackoverflow.com/questions/72410182/ptrace-get-syscall-info-always-returns-info-op-as-ptrace-syscall-info-none>
    
    Nate Eldredge found out what's wrong by looking into the kernel's source
    code, here is a link to the relevant part
    <https://github.com/torvalds/linux/blob/8291eaafed36f575f23951f3ce18407f480e9ecf/kernel/ptrace.c#L1018>
    
    In the code it can be seen that the union is filled if and only if the
    signal matches "SIGTRAP | 0x80", a signal which is only sent if the
    PTRACE_O_TRACESYSGOOD option is set.  You can read about that in the
    PTRACE_O_TRACESYSGOOD section of ptrace(2)'s manual.
    
    Complements: fc91449cb "ptrace.2: Document PTRACE_GET_SYSCALL_INFO"
    Cowritten-by: Dmitry V. Levin <ldv@strace.io>
    Signed-off-by: Dmitry V. Levin <ldv@strace.io>
    Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
    Acked-by: Nate Eldredge <nate@thatsmathematics.com>
    Cc: Elvira Khabirova <lineprinter0@gmail.com>
    Signed-off-by: Alejandro Colomar <alx@kernel.org>

diff --git a/man2/ptrace.2 b/man2/ptrace.2
index 55d9fd36d..9737b3825 100644
--- a/man2/ptrace.2
+++ b/man2/ptrace.2
@@ -1111,6 +1111,15 @@ .SH DESCRIPTION
 .B PTRACE_SYSCALL_INFO_NONE
 No component of the union contains relevant information.
 .RE
+.IP
+In case of system call entry or exit stops,
+the data returned by
+.B PTRACE_GET_SYSCALL_INFO
+is limited to type
+.B PTRACE_SYSCALL_INFO_NONE
+unless
+.B PTRACE_O_TRACESYSGOOD
+option is set before the corresponding system call stop has occurred.
 .\"
 .SS Death under ptrace
 When a (possibly multithreaded) process receives a killing signal



Please confirm if you want me to push it like that, or if there's anything
you'd like to tweak.

Cheers,

Alex

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Φώτης Βαλασιάδης]

Ah yes sorry for the confusion.

First name is Φώτιος, surname Βαλασιάδης,
just call me Fotis!

we use both formats in Greece, confusing i know . :D

It's fine by me, you know best! But if I have to point something it's 
that Dmitry didn't like the word "Fixed" and we in fact agreed to replace:

Fixed incomplete doc.  PTRACE_GET_SYSCALL_INFO's description wouldn't
     inform the user that they need to enable PTRACE_O_TRACESYSGOOD to get
     detailed information from said operation.

with:

Document the role of PTRACE_O_TRACESYSGOOD option in connection with
     PTRACE_GET_SYSCALL_INFO.

So perhaps you'd want to look into that? Can probably communicate on 
this with Dmitry so we can all agree to something.

I repeat though, from me it's all good, you know best!

Cheers!

-- fvalasiad --

On 27/2/23 02:19, Alejandro Colomar wrote:
> Hi Βαλασιάδης Φώτιος,
>
> (did I write your name correctly?
> I've seen it previously in the reverse order)
>
> On 2/27/23 00:22, Fotios Valasiadis wrote:
>> Document the role of PTRACE_O_TRACESYSGOOD option in connection with PTRACE_GET_SYSCALL_INFO.
>>
>> Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
>> Cowritten-by: Dmitry V. Levin <ldv@strace.io>
>> Complements: fc91449cb "ptrace.2: Document PTRACE_GET_SYSCALL_INFO"
> Patch applied.  Thanks!
>
> I tweaked the commit message to include the original one,
> which was great.  I forgot to mention this, but please
> keep the commit message for revisions of patches; it's
> always easier to discard some information later if it's
> unnecessary, but usually it's best to keep as much as
> possible in the commit message.
>
>> ---
>>   man2/ptrace.2 | 9 +++++++++
>>   1 file changed, 9 insertions(+)
>>
>> diff --git a/man2/ptrace.2 b/man2/ptrace.2
>> index 55d9fd36d..9737b3825 100644
>> --- a/man2/ptrace.2
>> +++ b/man2/ptrace.2
>> @@ -1111,6 +1111,15 @@ stop.
>>   .B PTRACE_SYSCALL_INFO_NONE
>>   No component of the union contains relevant information.
>>   .RE
>> +.IP
>> +In case of system call entry or exit stops,
>> +the data returned by
>> +.B PTRACE_GET_SYSCALL_INFO
>> +is limited to type
>> +.B PTRACE_SYSCALL_INFO_NONE
>> +unless
>> +.B PTRACE_O_TRACESYSGOOD
>> +option is set before the corresponding system call stop has occurred.
>>   .\"
>>   .SS Death under ptrace
>>   When a (possibly multithreaded) process receives a killing signal
> On 2/27/23 00:30, Φώτης Βαλασιάδης wrote:
>> Tried my best, hope I did it right!
>>
>> Thanks for the assist!
>>
>> And yes, it's Greek!
> :-)
>
>> Signing off with my github username most of the time.
> Okay.
>
>> Thanks again, here you go!
>>
>> Βαλασιάδης Φώτιος
> The applied patch is below:
>
> $ git show
> commit f04064d73b9f60f189c490e7ef5c3b9fa5498920 (HEAD -> master)
> Author: Fotios Valasiadis <fvalasiad@gmail.com>
> Date:   Mon Feb 27 01:22:01 2023 +0200
>
>      ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO
>      
>      Document the role of PTRACE_O_TRACESYSGOOD option in connection with
>      PTRACE_GET_SYSCALL_INFO.
>      
>      Fixed incomplete doc.  PTRACE_GET_SYSCALL_INFO's description wouldn't
>      inform the user that they need to enable PTRACE_O_TRACESYSGOOD to get
>      detailed information from said operation.
>      
>      Came upon this bug after writing a test program using
>      PTRACE_O_TRACESYSGOOD.  After failing to find what's wrong I posted a
>      stackoverflow question which you can find right here:
>      <https://stackoverflow.com/questions/72410182/ptrace-get-syscall-info-always-returns-info-op-as-ptrace-syscall-info-none>
>      
>      Nate Eldredge found out what's wrong by looking into the kernel's source
>      code, here is a link to the relevant part
>      <https://github.com/torvalds/linux/blob/8291eaafed36f575f23951f3ce18407f480e9ecf/kernel/ptrace.c#L1018>
>      
>      In the code it can be seen that the union is filled if and only if the
>      signal matches "SIGTRAP | 0x80", a signal which is only sent if the
>      PTRACE_O_TRACESYSGOOD option is set.  You can read about that in the
>      PTRACE_O_TRACESYSGOOD section of ptrace(2)'s manual.
>      
>      Complements: fc91449cb "ptrace.2: Document PTRACE_GET_SYSCALL_INFO"
>      Cowritten-by: Dmitry V. Levin <ldv@strace.io>
>      Signed-off-by: Dmitry V. Levin <ldv@strace.io>
>      Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
>      Acked-by: Nate Eldredge <nate@thatsmathematics.com>
>      Cc: Elvira Khabirova <lineprinter0@gmail.com>
>      Signed-off-by: Alejandro Colomar <alx@kernel.org>
>
> diff --git a/man2/ptrace.2 b/man2/ptrace.2
> index 55d9fd36d..9737b3825 100644
> --- a/man2/ptrace.2
> +++ b/man2/ptrace.2
> @@ -1111,6 +1111,15 @@ .SH DESCRIPTION
>   .B PTRACE_SYSCALL_INFO_NONE
>   No component of the union contains relevant information.
>   .RE
> +.IP
> +In case of system call entry or exit stops,
> +the data returned by
> +.B PTRACE_GET_SYSCALL_INFO
> +is limited to type
> +.B PTRACE_SYSCALL_INFO_NONE
> +unless
> +.B PTRACE_O_TRACESYSGOOD
> +option is set before the corresponding system call stop has occurred.
>   .\"
>   .SS Death under ptrace
>   When a (possibly multithreaded) process receives a killing signal
>
>
>
> Please confirm if you want me to push it like that, or if there's anything
> you'd like to tweak.
>
> Cheers,
>
> Alex
>

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2565 bytes --]

On 2/27/23 01:41, Φώτης Βαλασιάδης wrote:
> Ah yes sorry for the confusion.
> 
> First name is Φώτιος, surname Βαλασιάδης,
> just call me Fotis!

Hi Fotis,  :)

> 
> we use both formats in Greece, confusing i know . :D
> 
> It's fine by me, you know best! But if I have to point something it's 
> that Dmitry didn't like the word "Fixed" and we in fact agreed to replace:
> 
> Fixed incomplete doc.  PTRACE_GET_SYSCALL_INFO's description wouldn't
>      inform the user that they need to enable PTRACE_O_TRACESYSGOOD to get
>      detailed information from said operation.
> 
> with:
> 
> Document the role of PTRACE_O_TRACESYSGOOD option in connection with
>      PTRACE_GET_SYSCALL_INFO.
> 
> So perhaps you'd want to look into that? Can probably communicate on 
> this with Dmitry so we can all agree to something.
> 
> I repeat though, from me it's all good, you know best!

Ahh, sorry, I forgot about that.  I reworded it to the following:


    ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO
    
    Document the role of PTRACE_O_TRACESYSGOOD option in connection with
    PTRACE_GET_SYSCALL_INFO.
    
    Came upon this after writing a test program using PTRACE_O_TRACESYSGOOD.
    After failing to find what's wrong I posted a StackOverflow question
    which you can find right here:
    <https://stackoverflow.com/questions/72410182/ptrace-get-syscall-info-always-returns-info-op-as-ptrace-syscall-info-none>
    
    Nate Eldredge found out what happens by looking into the kernel's source
    code, here is a link to the relevant part
    <https://github.com/torvalds/linux/blob/8291eaafed36f575f23951f3ce18407f480e9ecf/kernel/ptrace.c#L1018>
    
    In the code it can be seen that the union is filled if and only if the
    signal matches "SIGTRAP | 0x80", a signal which is only sent if the
    PTRACE_O_TRACESYSGOOD option is set.  You can read about that in the
    PTRACE_O_TRACESYSGOOD section of ptrace(2)'s manual.
    
    Complements: fc91449cb "ptrace.2: Document PTRACE_GET_SYSCALL_INFO"
    Cowritten-by: Dmitry V. Levin <ldv@strace.io>
    Signed-off-by: Dmitry V. Levin <ldv@strace.io>
    Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
    Acked-by: Nate Eldredge <nate@thatsmathematics.com>
    Cc: Elvira Khabirova <lineprinter0@gmail.com>
    Signed-off-by: Alejandro Colomar <alx@kernel.org>

Cheers!

Alex


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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Dmitry V. Levin]

Hi,

On Mon, Feb 27, 2023 at 02:28:45PM +0100, Alejandro Colomar wrote:
[...]
> Ahh, sorry, I forgot about that.  I reworded it to the following:
> 
>     ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO
>     
>     Document the role of PTRACE_O_TRACESYSGOOD option in connection with
>     PTRACE_GET_SYSCALL_INFO.
>     
>     Came upon this after writing a test program using PTRACE_O_TRACESYSGOOD.

Just otherwise, PTRACE_O_TRACESYSGOOD was not used in that test,
otherwise there wouldn't be any question in the first place.
Did you mean PTRACE_GET_SYSCALL_INFO?

>     After failing to find what's wrong I posted a StackOverflow question
>     which you can find right here:
>     <https://stackoverflow.com/questions/72410182/ptrace-get-syscall-info-always-returns-info-op-as-ptrace-syscall-info-none>
>     
>     Nate Eldredge found out what happens by looking into the kernel's source
>     code, here is a link to the relevant part
>     <https://github.com/torvalds/linux/blob/8291eaafed36f575f23951f3ce18407f480e9ecf/kernel/ptrace.c#L1018>
>     
>     In the code it can be seen that the union is filled if and only if the
>     signal matches "SIGTRAP | 0x80", a signal which is only sent if the
>     PTRACE_O_TRACESYSGOOD option is set.  You can read about that in the
>     PTRACE_O_TRACESYSGOOD section of ptrace(2)'s manual.

Once again, this "if and only if" is confusing, as PTRACE_EVENT_SECCOMP
event that can happen when PTRACE_O_TRACESECCOMP option is enabled
fills the union with the data of type PTRACE_SYSCALL_INFO_SECCOMP.

PTRACE_EVENT_SECCOMP stop is similar to system call enter stop, but it's
not exactly the same kind of stop.

The note we're adding to the manual page is more correct in this regards.


-- 
ldv

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2118 bytes --]

Hi Dmitry,

On 2/27/23 16:33, Dmitry V. Levin wrote:
> Hi,
> 
> On Mon, Feb 27, 2023 at 02:28:45PM +0100, Alejandro Colomar wrote:
> [...]
>> Ahh, sorry, I forgot about that.  I reworded it to the following:
>>
>>     ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO
>>     
>>     Document the role of PTRACE_O_TRACESYSGOOD option in connection with
>>     PTRACE_GET_SYSCALL_INFO.
>>     
>>     Came upon this after writing a test program using PTRACE_O_TRACESYSGOOD.
> 
> Just otherwise, PTRACE_O_TRACESYSGOOD was not used in that test,
> otherwise there wouldn't be any question in the first place.
> Did you mean PTRACE_GET_SYSCALL_INFO?
> 
>>     After failing to find what's wrong I posted a StackOverflow question
>>     which you can find right here:
>>     <https://stackoverflow.com/questions/72410182/ptrace-get-syscall-info-always-returns-info-op-as-ptrace-syscall-info-none>
>>     
>>     Nate Eldredge found out what happens by looking into the kernel's source
>>     code, here is a link to the relevant part
>>     <https://github.com/torvalds/linux/blob/8291eaafed36f575f23951f3ce18407f480e9ecf/kernel/ptrace.c#L1018>
>>     
>>     In the code it can be seen that the union is filled if and only if the
>>     signal matches "SIGTRAP | 0x80", a signal which is only sent if the
>>     PTRACE_O_TRACESYSGOOD option is set.  You can read about that in the
>>     PTRACE_O_TRACESYSGOOD section of ptrace(2)'s manual.
> 
> Once again, this "if and only if" is confusing, as PTRACE_EVENT_SECCOMP
> event that can happen when PTRACE_O_TRACESECCOMP option is enabled
> fills the union with the data of type PTRACE_SYSCALL_INFO_SECCOMP.
> 
> PTRACE_EVENT_SECCOMP stop is similar to system call enter stop, but it's
> not exactly the same kind of stop.
> 
> The note we're adding to the manual page is more correct in this regards.

Okay, I'll let Fotios write the commit message, and will take it whatever it is :)

Cheers,

Alex

> 
> 

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 807 bytes --]

Hi Φώτης,

On 2/27/23 18:27, Φώτης Βαλασιάδης wrote:
>>>
> So with Dmitry we agreed on:
> 
>  1.
> 
>     Came upon this after writing a test program using PTRACE_GET_SYSCALL_INFO.
> 
>  2.
> 
>     In the code it can be seen that in case of system call entry or
>     exit stops, the union is filled if and only if the signal matches
>     "SIGTRAP | 0x80", a signal which is sent if the PTRACE_O_TRACESYSGOOD
>     option is set. You can read about that in the PTRACE_O_TRACESYSGOOD
>     section of ptrace(2)'s manual.
> 
> Replace these and we are set!

Would you mind sending the patch again with that text? :)

Thanks!

Alex

> 
> -- fvalasiad --

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Fotios Valasiadis]

Document the role of PTRACE_O_TRACESYSGOOD option in connection with
PTRACE_GET_SYSCALL_INFO.

Came upon this after writing a test program using PTRACE_GET_SYSCALL_INFO.
After failing to find what's wrong I posted a StackOverflow question
which you can find right here:
<https://stackoverflow.com/questions/72410182/ptrace-get-syscall-info-always-returns-info-op-as-ptrace-syscall-info-none>

Nate Eldredge found out what happens by looking into the kernel's source
code, here is a link to the relevant part
<https://github.com/torvalds/linux/blob/8291eaafed36f575f23951f3ce18407f480e9ecf/kernel/ptrace.c#L1018>

In the code it can be seen that in case of system call entry or
exit stops, the union is filled if and only if the signal matches
"SIGTRAP | 0x80", a signal which is only sent if the PTRACE_O_TRACESYSGOOD
option is set.  You can read about that in the PTRACE_O_TRACESYSGOOD
section of ptrace(2)'s manual.

Complements: fc91449cb "ptrace.2: Document PTRACE_GET_SYSCALL_INFO"
Cowritten-by: Dmitry V. Levin <ldv@strace.io>
Signed-off-by: Dmitry V. Levin <ldv@strace.io>
Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
Acked-by: Nate Eldredge <nate@thatsmathematics.com>
Cc: Elvira Khabirova <lineprinter0@gmail.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
---
 man2/ptrace.2 | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/man2/ptrace.2 b/man2/ptrace.2
index 55d9fd36d..9737b3825 100644
--- a/man2/ptrace.2
+++ b/man2/ptrace.2
@@ -1111,6 +1111,15 @@ stop.
 .B PTRACE_SYSCALL_INFO_NONE
 No component of the union contains relevant information.
 .RE
+.IP
+In case of system call entry or exit stops,
+the data returned by
+.B PTRACE_GET_SYSCALL_INFO
+is limited to type
+.B PTRACE_SYSCALL_INFO_NONE
+unless
+.B PTRACE_O_TRACESYSGOOD
+option is set before the corresponding system call stop has occurred.
 .\"
 .SS Death under ptrace
 When a (possibly multithreaded) process receives a killing signal
-- 
2.39.2

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Φώτης Βαλασιάδης]

Hi Alex!

Is that good enough?

-- fvalasiad --

On 27/2/23 21:17, Fotios Valasiadis wrote:
> Document the role of PTRACE_O_TRACESYSGOOD option in connection with
> PTRACE_GET_SYSCALL_INFO.
>
> Came upon this after writing a test program using PTRACE_GET_SYSCALL_INFO.
> After failing to find what's wrong I posted a StackOverflow question
> which you can find right here:
> <https://stackoverflow.com/questions/72410182/ptrace-get-syscall-info-always-returns-info-op-as-ptrace-syscall-info-none>
>
> Nate Eldredge found out what happens by looking into the kernel's source
> code, here is a link to the relevant part
> <https://github.com/torvalds/linux/blob/8291eaafed36f575f23951f3ce18407f480e9ecf/kernel/ptrace.c#L1018>
>
> In the code it can be seen that in case of system call entry or
> exit stops, the union is filled if and only if the signal matches
> "SIGTRAP | 0x80", a signal which is only sent if the PTRACE_O_TRACESYSGOOD
> option is set.  You can read about that in the PTRACE_O_TRACESYSGOOD
> section of ptrace(2)'s manual.
>
> Complements: fc91449cb "ptrace.2: Document PTRACE_GET_SYSCALL_INFO"
> Cowritten-by: Dmitry V. Levin <ldv@strace.io>
> Signed-off-by: Dmitry V. Levin <ldv@strace.io>
> Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
> Acked-by: Nate Eldredge <nate@thatsmathematics.com>
> Cc: Elvira Khabirova <lineprinter0@gmail.com>
> Signed-off-by: Alejandro Colomar <alx@kernel.org>
> ---
>   man2/ptrace.2 | 9 +++++++++
>   1 file changed, 9 insertions(+)
>
> diff --git a/man2/ptrace.2 b/man2/ptrace.2
> index 55d9fd36d..9737b3825 100644
> --- a/man2/ptrace.2
> +++ b/man2/ptrace.2
> @@ -1111,6 +1111,15 @@ stop.
>   .B PTRACE_SYSCALL_INFO_NONE
>   No component of the union contains relevant information.
>   .RE
> +.IP
> +In case of system call entry or exit stops,
> +the data returned by
> +.B PTRACE_GET_SYSCALL_INFO
> +is limited to type
> +.B PTRACE_SYSCALL_INFO_NONE
> +unless
> +.B PTRACE_O_TRACESYSGOOD
> +option is set before the corresponding system call stop has occurred.
>   .\"
>   .SS Death under ptrace
>   When a (possibly multithreaded) process receives a killing signal

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Φώτης Βαλασιάδης]

Hi yet again Alex!

You didn't confirm so I was wondering if you received my message!

Let me know if possible.

-- fvalasiad --

On 27/2/23 21:19, Φώτης Βαλασιάδης wrote:
> Hi Alex!
>
> Is that good enough?
>
> -- fvalasiad --
>
> On 27/2/23 21:17, Fotios Valasiadis wrote:
>> Document the role of PTRACE_O_TRACESYSGOOD option in connection with
>> PTRACE_GET_SYSCALL_INFO.
>>
>> Came upon this after writing a test program using 
>> PTRACE_GET_SYSCALL_INFO.
>> After failing to find what's wrong I posted a StackOverflow question
>> which you can find right here:
>> <https://stackoverflow.com/questions/72410182/ptrace-get-syscall-info-always-returns-info-op-as-ptrace-syscall-info-none> 
>>
>>
>> Nate Eldredge found out what happens by looking into the kernel's source
>> code, here is a link to the relevant part
>> <https://github.com/torvalds/linux/blob/8291eaafed36f575f23951f3ce18407f480e9ecf/kernel/ptrace.c#L1018> 
>>
>>
>> In the code it can be seen that in case of system call entry or
>> exit stops, the union is filled if and only if the signal matches
>> "SIGTRAP | 0x80", a signal which is only sent if the 
>> PTRACE_O_TRACESYSGOOD
>> option is set.  You can read about that in the PTRACE_O_TRACESYSGOOD
>> section of ptrace(2)'s manual.
>>
>> Complements: fc91449cb "ptrace.2: Document PTRACE_GET_SYSCALL_INFO"
>> Cowritten-by: Dmitry V. Levin <ldv@strace.io>
>> Signed-off-by: Dmitry V. Levin <ldv@strace.io>
>> Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
>> Acked-by: Nate Eldredge <nate@thatsmathematics.com>
>> Cc: Elvira Khabirova <lineprinter0@gmail.com>
>> Signed-off-by: Alejandro Colomar <alx@kernel.org>
>> ---
>>   man2/ptrace.2 | 9 +++++++++
>>   1 file changed, 9 insertions(+)
>>
>> diff --git a/man2/ptrace.2 b/man2/ptrace.2
>> index 55d9fd36d..9737b3825 100644
>> --- a/man2/ptrace.2
>> +++ b/man2/ptrace.2
>> @@ -1111,6 +1111,15 @@ stop.
>>   .B PTRACE_SYSCALL_INFO_NONE
>>   No component of the union contains relevant information.
>>   .RE
>> +.IP
>> +In case of system call entry or exit stops,
>> +the data returned by
>> +.B PTRACE_GET_SYSCALL_INFO
>> +is limited to type
>> +.B PTRACE_SYSCALL_INFO_NONE
>> +unless
>> +.B PTRACE_O_TRACESYSGOOD
>> +option is set before the corresponding system call stop has occurred.
>>   .\"
>>   .SS Death under ptrace
>>   When a (possibly multithreaded) process receives a killing signal

Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2394 bytes --]

Hi Fotios,

On 2/27/23 20:19, Φώτης Βαλασιάδης wrote:
> Hi Alex!
> 
> Is that good enough?
> 

Yep.  Patch applied.  Thanks!

Alex

On 2/27/23 20:17, Fotios Valasiadis wrote:
> Document the role of PTRACE_O_TRACESYSGOOD option in connection with
> PTRACE_GET_SYSCALL_INFO.
> 
> Came upon this after writing a test program using PTRACE_GET_SYSCALL_INFO.
> After failing to find what's wrong I posted a StackOverflow question
> which you can find right here:
> <https://stackoverflow.com/questions/72410182/ptrace-get-syscall-info-always-returns-info-op-as-ptrace-syscall-info-none>
> 
> Nate Eldredge found out what happens by looking into the kernel's source
> code, here is a link to the relevant part
> <https://github.com/torvalds/linux/blob/8291eaafed36f575f23951f3ce18407f480e9ecf/kernel/ptrace.c#L1018>
> 
> In the code it can be seen that in case of system call entry or
> exit stops, the union is filled if and only if the signal matches
> "SIGTRAP | 0x80", a signal which is only sent if the PTRACE_O_TRACESYSGOOD
> option is set.  You can read about that in the PTRACE_O_TRACESYSGOOD
> section of ptrace(2)'s manual.
> 
> Complements: fc91449cb "ptrace.2: Document PTRACE_GET_SYSCALL_INFO"
> Cowritten-by: Dmitry V. Levin <ldv@strace.io>
> Signed-off-by: Dmitry V. Levin <ldv@strace.io>
> Signed-off-by: Fotios Valasiadis <fvalasiad@gmail.com>
> Acked-by: Nate Eldredge <nate@thatsmathematics.com>
> Cc: Elvira Khabirova <lineprinter0@gmail.com>
> Signed-off-by: Alejandro Colomar <alx@kernel.org>
> ---
>  man2/ptrace.2 | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/man2/ptrace.2 b/man2/ptrace.2
> index 55d9fd36d..9737b3825 100644
> --- a/man2/ptrace.2
> +++ b/man2/ptrace.2
> @@ -1111,6 +1111,15 @@ stop.
>  .B PTRACE_SYSCALL_INFO_NONE
>  No component of the union contains relevant information.
>  .RE
> +.IP
> +In case of system call entry or exit stops,
> +the data returned by
> +.B PTRACE_GET_SYSCALL_INFO
> +is limited to type
> +.B PTRACE_SYSCALL_INFO_NONE
> +unless
> +.B PTRACE_O_TRACESYSGOOD
> +option is set before the corresponding system call stop has occurred.
>  .\"
>  .SS Death under ptrace
>  When a (possibly multithreaded) process receives a killing signal

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]