Re: sys_exit: NR -1

Re: sys_exit: NR -1

[Naveen N. Rao]

Paul Clarke wrote:
> What are the circumstances in which raw_syscalls:sys_exit reports "-1" for the syscall ID?
> 
>     perf  5375 [007] 59632.478528:   raw_syscalls:sys_enter: NR 1 (3, 9fb888, 8, 2d83740, 1, 7ffff)
>     perf  5375 [007] 59632.478532:    raw_syscalls:sys_exit: NR 1 = 8
>     perf  5375 [007] 59632.478538:   raw_syscalls:sys_enter: NR 15 (11, 7ffffca734b0, 7ffffca73380, 2d83740, 1, 7ffff)
>     perf  5375 [007] 59632.478539:    raw_syscalls:sys_exit: NR -1 = 8
>     perf  5375 [007] 59632.478543:   raw_syscalls:sys_enter: NR 16 (4, 2401, 0, 2d83740, 1, 0)
>     perf  5375 [007] 59632.478551:    raw_syscalls:sys_exit: NR 16 = 0

Which architecture?
For powerpc, see:

static inline int syscall_get_nr(struct task_struct *task, struct pt_regs *regs)
{
	/*
	 * Note that we are returning an int here. That means 0xffffffff, ie.
	 * 32-bit negative 1, will be interpreted as -1 on a 64-bit kernel.
	 * This is important for seccomp so that compat tasks can set r0 = -1
	 * to reject the syscall.
	 */
	return TRAP(regs) == 0xc00 ? regs->gpr[0] : -1;
}


- Naveen

Re: sys_exit: NR -1

[Paul Clarke]

On 6/12/19 1:32 AM, Naveen N. Rao wrote:
> Paul Clarke wrote:
>> What are the circumstances in which raw_syscalls:sys_exit reports "-1" for the syscall ID?
>>
>>     perf  5375 [007] 59632.478528:   raw_syscalls:sys_enter: NR 1 (3, 9fb888, 8, 2d83740, 1, 7ffff)
>>     perf  5375 [007] 59632.478532:    raw_syscalls:sys_exit: NR 1 = 8
>>     perf  5375 [007] 59632.478538:   raw_syscalls:sys_enter: NR 15 (11, 7ffffca734b0, 7ffffca73380, 2d83740, 1, 7ffff)
>>     perf  5375 [007] 59632.478539:    raw_syscalls:sys_exit: NR -1 = 8
>>     perf  5375 [007] 59632.478543:   raw_syscalls:sys_enter: NR 16 (4, 2401, 0, 2d83740, 1, 0)
>>     perf  5375 [007] 59632.478551:    raw_syscalls:sys_exit: NR 16 = 0
> 
> Which architecture?
> For powerpc, see:
> 
> static inline int syscall_get_nr(struct task_struct *task, struct pt_regs *regs)
> {
>     /*
>      * Note that we are returning an int here. That means 0xffffffff, ie.
>      * 32-bit negative 1, will be interpreted as -1 on a 64-bit kernel.
>      * This is important for seccomp so that compat tasks can set r0 = -1
>      * to reject the syscall.
>      */
>     return TRAP(regs) == 0xc00 ? regs->gpr[0] : -1;
> }

So, that's intentional?  And has some special meaning?  (I confess I don't understand what the comment is saying exactly.)

Is this documented?  Does something depend on this ABI?

To me, it just makes parsing more difficult, both by humans and machines.

PC

Re: sys_exit: NR -1

[Paul Clarke]

On 6/13/19 4:00 PM, Paul Clarke wrote:
> On 6/12/19 1:32 AM, Naveen N. Rao wrote:
>> Paul Clarke wrote:
>>> What are the circumstances in which raw_syscalls:sys_exit reports "-1" for the syscall ID?
>>>
>>>     perf  5375 [007] 59632.478528:   raw_syscalls:sys_enter: NR 1 (3, 9fb888, 8, 2d83740, 1, 7ffff)
>>>     perf  5375 [007] 59632.478532:    raw_syscalls:sys_exit: NR 1 = 8
>>>     perf  5375 [007] 59632.478538:   raw_syscalls:sys_enter: NR 15 (11, 7ffffca734b0, 7ffffca73380, 2d83740, 1, 7ffff)
>>>     perf  5375 [007] 59632.478539:    raw_syscalls:sys_exit: NR -1 = 8
>>>     perf  5375 [007] 59632.478543:   raw_syscalls:sys_enter: NR 16 (4, 2401, 0, 2d83740, 1, 0)
>>>     perf  5375 [007] 59632.478551:    raw_syscalls:sys_exit: NR 16 = 0
>>
>> Which architecture?
>> For powerpc, see:
>>
>> static inline int syscall_get_nr(struct task_struct *task, struct pt_regs *regs)
>> {
>>     /*
>>      * Note that we are returning an int here. That means 0xffffffff, ie.
>>      * 32-bit negative 1, will be interpreted as -1 on a 64-bit kernel.
>>      * This is important for seccomp so that compat tasks can set r0 = -1
>>      * to reject the syscall.
>>      */
>>     return TRAP(regs) == 0xc00 ? regs->gpr[0] : -1;
>> }
> 
> So, that's intentional?  And has some special meaning?  (I confess I don't understand what the comment is saying exactly.)
> 
> Is this documented?  Does something depend on this ABI?
> 
> To me, it just makes parsing more difficult, both by humans and machines.

I should've noted that the instance I encountered was on x86.

PC

sys_exit: NR 0 (was "sys_exit: NR -1")

[Paul Clarke]

I'm seeing another asymmetry, this one is on powerpc:
--
  perf 30179 [001] 10374622.667436: raw_syscalls:sys_enter: NR 11 (3fffe16ef55e, [...])
    ls 30179 [002] 10374622.667921:  raw_syscalls:sys_exit: NR 0 = 0
--

Syscall "11" is "execve", but is it expected that the sys_exit will report the ID as 0?  Is that because of the nature of "execve", to overlay the entire contents of the process?

This does not seem to occur on x86.

PC