On Tue, Aug 30, 2016 at 3:30 PM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > On Tue, 30 Aug 2016 15:08:19 -0700 > Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > >> On Tue, Aug 30, 2016 at 3:03 PM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: >> > On Tue, 30 Aug 2016 14:45:05 -0700 >> > Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> > >> >> I wonder: could more of it be dynamically allocated? I.e. statically >> >> generate metadata with args and name and whatever but without any nr. >> >> Then dynamically allocate the map from nr to metadata? >> > >> > Any ideas on how to do that? >> >> This might be as simple as dropping the syscall_nr field from >> syscall_metadata. I admit I'm not familiar with this code at all, but >> I'm not really sure why that field is needed. init_ftrace_syscalls is >> already dynamically allocating an array that maps nr to metadata, and >> I don't see what in the code actually needs that mapping to be >> one-to-one or needs the reverse mapping. > > The issue is that the syscall trace points are called by a single > location, that passes in the syscall_nr, and we need a way to map that > syscall_nr to the metadata. > > System calls are really a meta tracepoint. They share a single real > tracepoint called raw_syscalls:sys_enter and raw_syscalls:sys_exit. > When you enable a system call like sys_enter_read, what really happens > is that the sys_enter tracepoint is attached with a function called > ftrace_syscall_enter(). > > This calls trace_get_syscall_nr(current, regs), to extract the actual > syscall_nr that was called. This is used to find the "file" that is > mapped to the system call (the tracefs file that enabled the system > call). > > trace_file = tr->enter_syscall_files[syscall_nr]; > > And the meta data (what is used to tell us what to save) is found with > the syscall_nr_to_meta() function. > > Now the metadata is used to extract the arguments of the system call: > > syscall_get_arguments(current, regs, 0, sys_data->nb_args, > etnry->args); > > As well as the size needed. > > There's no need to map syscall meta to nr, we need a way to map the nr > to the syscall metadata, and when there's more than a one to one > mapping, we need a way to differentiate that in the raw syscall > tracepoints. But none of this should be a problem at all for MIPS, right? AFAICT the only problem for MIPS is that there *is* a mapping from metadata to nr. If that mapping got removed, MIPS should just work, right? For x86 compat, I think that adding arch should be sufficient. Specifically, rather than having just one enter_syscall_files array, have one per audit arch. Then call syscall_get_arch() as well as syscall_get_nr() and use both to lookup the metadata. AFAIK this should work on all architectures, although you might need some arch helpers to enumerate all the arches and their respective syscall tables (and max syscall nrs). --Andy -- 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
