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 15:08:19 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Steven Rostedt <rostedt@...dmis.org>
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, 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.

>
>>
>> > >
>> > > Could we at least have an array of (arch, nr) instead of just an array
>> > > of nrs in the metadata?
>> >
>> > I guess I'm not following you on what would be used for "arch".
>>
>> Whatever syscall_get_arch() would return for the syscall.  For x86,
>> for example, most syscalls have a compat nr and a non-compat nr.  How
>> does tracing currently handle that?
>
> We currently disable tracing compat syscalls.
>
> What the current code does, is that the macro and linker magic creates
> a list of meta data structures, that have a name attached to them.
>
> Then on boot up, we scan the list of syscall numbers and then ask the
> arch for the system call they represent to get the actual function
> itself:
>
>         addr = arch_syscall_addr(i);
>
> where 'i' is the system call nr.
>
> Then the find_syscall_meta(addr) will do a ksyms_lookup to convert the
> addr into the system call name, and then search the meta data for one
> that has that name attached to it.
>
> Yes it is ugly. But we don't currently have a method to automatically
> match the meta data with the system call numbers. The system call
> macros only have access to the names and the parameters, not the
> numbers that are associated with them.
>

Yeah, I think I get it now.  But I think my suggestion of removing
syscall_nr entirely might actually work.  You'd have to initialize
more than one syscalls_metadata array, but they could share the
underlying metadata objects.

--Andy


-- 
Andy Lutomirski
AMA Capital Management, LLC