linux-kernel - Re: [PATCH] tracing: Add WARN_ON_ONCE for syscall

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f27c1cf8-4c00-44dc-80f2-a499cf83ea81@gmail.com>
Date: Fri, 29 Nov 2024 10:48:55 +0800
From: Tao Chen <chen.dylane@...il.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Steven Rostedt <rostedt@...dmis.org>
Cc: mhiramat@...nel.org, linux-kernel@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH] tracing: Add WARN_ON_ONCE for syscall_nr check

在 2024/11/28 22:27, Mathieu Desnoyers 写道:
> On 2024-11-28 08:15, Tao Chen wrote:
>> 在 2024/11/28 20:46, Steven Rostedt 写道:
>>> On Thu, 28 Nov 2024 19:53:19 +0800
>>> Tao Chen <chen.dylane@...il.com> wrote:
>>>
>>>> Now, x86_64 kernel not support to trace syscall for ia32 syscall.
>>>> As a result, there is no any trace output when tracing a ia32 task.
>>>> Like unreg_event_syscall_enter, add a WARN_ON_ONCE judgment for
>>>> syscall_nr in perf_syscall_enter and ftrace_syscall_enter to give
>>>> some message.
>>>
>>> So on a system that has "panic_on_warn" set and they trace a 32 bit
>>> system call, it will cause their system to crash. Is that the intended
>>> behavior?
>>>
>>> WARN*() is for self testing the kernel to detect real bugs, not to
>>> inform users that something isn't supported.
>>>
>>> BIG NAK!
>>>
>>> -- Steve
>>
>> Hi, Steve, thank you for your reply, as you say, so what about 
>> pr_warn_once api just to print something ?
>>
> 
> I understand that explicitly enabling a system call and observing
> that ia32 system calls are just not traced by ftrace and perf can
> be surprising for end users. But printing a warning on the tracing
> path for an unimplemented tracing feature is just wrong.
> 

The initial problem was that I used eBPF 
SEC("tp/syscalls/sys_enter_sendto") to capture system calls and found no 
results for i32 programs. So here, i just wanted to remind users that on 
a 64-bit system, i32 system calls are not supported, to avoid confusion.

> Also, AFAIU the warning will trigger if an ia32 program issues any
> system call when any unrelated system call tracing is enabled,
> including non-compat syscalls.
> 
> If you want to check something and return an error, it would
> be in tracefs where the users interact with files that represent
> ia32 system calls to try to list/enable them. However, given the
> exposed files have nothing that mention whether they apply to
> non-compat or compat system calls, it's understandable that an
> end user would think all system calls are traced, including
> compat system calls. So I'm not sure how to solve that in ftrace/perf
> without actually implementing the missing feature the way the
> tracefs ABI is exposed.
> 
> If your end goal is to trace ia32 system call, you may want to try the
> lttng-modules kernel tracer [1], which has supported compat system call
> tracing for the past 12 years (at least since lttng-modules 2.0).

Thank you for your recommendation. I'll take a look at how lttng 
implements it. Actually, SEC("tp/raw_syscall/sys_enter") can also
capure it.

> 
> Thanks,
> 
> Mathieu
> 
> [1] https://lttng.org/
> 


-- 
Best Regards
Dylane Chen