linux-kernel - Re: [PATCH 1/2] tracing/syscalls: allow multiple syscall numbers per 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]

Date:   Tue, 30 Aug 2016 18:30:30 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Andy Lutomirski <luto@...capital.net>
Cc:     Linux API <linux-api@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        open list <linux-kernel@...r.kernel.org>,
        Linux MIPS Mailing List <linux-mips@...ux-mips.org>,
        Marcin Nowakowski <marcin.nowakowski@...tec.com>
Subject: Re: [PATCH 1/2] tracing/syscalls: allow multiple syscall numbers
 per syscall

On Tue, 30 Aug 2016 15:08:19 -0700
Andy Lutomirski <luto@...capital.net> wrote:

> On Tue, Aug 30, 2016 at 3:03 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
> > On Tue, 30 Aug 2016 14:45:05 -0700
> > Andy Lutomirski <luto@...capital.net> 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.

-- Steve