Re: [PATCH 1/2] tracing/syscalls: allow multiple syscall numbers per syscall

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 30.08.2016 01:55, Andy Lutomirski wrote:
On Aug 29, 2016 11:30 AM, "Marcin Nowakowski"
<marcin.nowakowski@xxxxxxxxxx> wrote:

Syscall metadata makes an assumption that only a single syscall number
corresponds to a given method. This is true for most archs, but
can break tracing otherwise.

For MIPS platforms, depending on the choice of supported ABIs, up to 3
system call numbers can correspond to the same call - depending on which
ABI the userspace app uses.

MIPS isn't special here.  x86 does the same thing.  Why isn't this a
problem on x86?


Hi Andy,

My understanding is that MIPS is quite different to what most other architectures do ... First of all x86 disables tracing of compat syscalls as that didn't work properly because of wrong mapping of syscall numbers to syscalls:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f431b634f

Moreover, when trace_syscalls is initialised, the syscall metadata is updated to include the right syscall numbers. That uses arch_syscall_addr method, which has a default implementation in kernel/trace/trace_syscalls.c:

unsigned long __init __weak arch_syscall_addr(int nr)
{
        return (unsigned long)sys_call_table[nr];
}

that works for x86 and only uses 'native' syscalls, ie. for x86_64 will not map any of the ia32_sys_call_table entries. So on one hand we have the code that disables tracing for x86_64 compat, on the other we only ensure that the native calls are mapped. It is quite different for MIPS where syscall numbers for different ABIs have distinct call numbers, so the following code maps the syscalls
(for O32 -> 4xxx, N64 -> 5xxx, N32 -> 6xxx):

unsigned long __init arch_syscall_addr(int nr)
{
if (nr >= __NR_N32_Linux && nr <= __NR_N32_Linux + __NR_N32_Linux_syscalls) return (unsigned long)sysn32_call_table[nr - __NR_N32_Linux]; if (nr >= __NR_64_Linux && nr <= __NR_64_Linux + __NR_64_Linux_syscalls)
                return (unsigned long)sys_call_table[nr - __NR_64_Linux];
if (nr >= __NR_O32_Linux && nr <= __NR_O32_Linux + __NR_O32_Linux_syscalls) return (unsigned long)sys32_call_table[nr - __NR_O32_Linux];
        return (unsigned long) &sys_ni_syscall;
}

As a result when init_ftrace_syscalls() loops through all the possible syscall numbers, it first finds an O32 implementation, then N64 and finally N32. As the current code doesn't expect multiple references to a given syscall number, it always overrides the metadata with the last found - as a result only N32 syscalls are mapped. This is generally unexpected and wrong behaviour, and to makes things worse - since when N32 support is enabled, it overwrites N64 entries, it becomes impossible to trace native syscalls.

> Also, you seem to be partially reinventing AUDIT_ARCH here.  Can you
> use that and integrate with syscall_get_arch()?

Please correct me if I don't understand what you meant here, but I don't see how these can be integrated ... For MIPS syscall_get_arch() properly determines arch type and calling convention, but that information is not enough to determine what call was made and how to map it to syscall metadata from another calling convention.

Marcin

--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux