[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 11 Nov 2016 09:10:45 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: Linux API <linux-api@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Michael Kerrisk <mtk.manpages@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Sasha Levin <levinsasha928@...il.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
scientist@...com, Steven Rostedt <rostedt@...dmis.org>,
Arnd Bergmann <arnd@...db.de>,
"Carlos O'Donell" <carlos@...hat.com>,
syzkaller <syzkaller@...glegroups.com>,
Kostya Serebryany <kcc@...gle.com>,
Mike Frysinger <vapier@...gle.com>,
Dave Jones <davej@...emonkey.org.uk>,
Tavis Ormandy <taviso@...gle.com>
Subject: Re: Formal description of system call interface
On Sun, Nov 6, 2016 at 2:39 PM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
> Hello,
>
> This is notes from the discussion we had at Linux Plumbers this week
> regarding providing a formal description of system calls (user API).
>
> The idea come up in the context of syzkaller, syscall fuzzer, which
> has descriptions for 1000+ syscalls mostly concentrating on types of
> arguments and return values. However, problems are that a small group
> of people can't write descriptions for all syscalls; can't keep them
> up-to-date and doesn't have necessary domain expertise to do correct
> descriptions in some cases.
>
> We identified a surprisingly large number of potential users for such
> descriptions:
Let me add one more: consolidation of all the incompatible arch
syscall tables. A sufficiently descriptive format should be parseable
at build time to generate the syscall tables.
Powered by blists - more mailing lists