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]

Message-ID: <20160901112428.7c05dede@gandalf.local.home>
Date:   Thu, 1 Sep 2016 11:24:28 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Marcin Nowakowski <marcin.nowakowski@...tec.com>,
        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>
Subject: Re: [PATCH 1/2] tracing/syscalls: allow multiple syscall numbers
 per syscall

On Wed, 31 Aug 2016 10:24:56 +0200
Arnd Bergmann <arnd@...db.de> wrote:

> On Tuesday, August 30, 2016 12:53:53 PM CEST Andy Lutomirski wrote:
> > Egads!  OK, I see why this is a mess.
> > 
> > I guess we should be creating the metadata from the syscall tables
> > instead of from the syscall definitions, but I guess that's currently
> > a nasty per-arch mess.
> >   
> 
> I've been thinking for a while about how to improve the situation
> around adding new syscalls, which currently involves adding a number
> and an entry in a .S file on most architectures (some already have
> their own method to simplify it, and others using a shared table
> in asm-generic).
> 
> I was thinking of extending the x86 way of doing this to all
> architectures, and adding a way to have all future syscalls require
> only one addition in a single file that gets included by the
> architecture specific files for the existing syscalls.
> 
> Assuming we do this, would that work for generating the metadata
> from the same file like we do with
> arch/x86/entry/syscalls/syscall{tbl,hdr}.sh ?

I can't answer this because I'm not sure exactly how you would do this.
Perhaps you could give it a try and code will be the answer to all my
questions ;-)

-- Steve