linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: syzkaller <syzkaller@googlegroups.com>,
	Linux API <linux-api@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Michael Kerrisk-manpages <mtk.manpages@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Sasha Levin <levinsasha928@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	scientist@fb.com, Arnd Bergmann <arnd@arndb.de>,
	Carlos O'Donell <carlos@redhat.com>,
	Kostya Serebryany <kcc@google.com>,
	Mike Frysinger <vapier@google.com>,
	Dave Jones <davej@codemonkey.org.uk>,
	Tavis Ormandy <taviso@google.com>
Subject: Re: Formal description of system call interface
Date: Mon, 21 Nov 2016 17:58:53 +0100	[thread overview]
Message-ID: <20161121165853.GC27353@rei.lan> (raw)
In-Reply-To: <CACT4Y+Z4a08puQsxDyCQGuWwmqgnW5aCYDDQecqtY7NTMj4mVA@mail.gmail.com>

Hi!
> > Looking ahead into the future, I was also thinking that if this becomes
> > robust, we could also start an integration specification, that could
> > describe how different system calls interact with each other. Like
> > open() to read(), write() and close().
> >
> > But this is just an idea that popped in my head while reading this
> > thread. We want to start small first, but still could keep this in the
> > back of our minds for future enhancements.
> 
> 
> FWIW syzkaller does something along these lines.
> It has notion of 'resources' and of input/output arguments.
> Then it can figure out that e.g. open creates fd's, so it should be called
> before any reads/writes (provided that we want to pass in valid fd's).
> It does not have notion of "destructors" for resources (e.g. close
> destroys the passed in resource). But it should be easy to describe.

Logical extension would be to teach it that creat(), for instance,
returns file descriptor and creates a file as a side effect. That file
then could be used for a stat() or unlink() concurently, etc. But we
should also consider that not all file descriptors or files are equal,
so we may end up with some classes of files and file descriptors
some of them suitable for different subsets of operations.

I think that defining classes of objects and defining how syscalls
transform their state may yield something usable. But that would require
some serious thinking and a few trial and error implementations.

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2016-11-21 16:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-06 22:39 Formal description of system call interface Dmitry Vyukov
     [not found] ` <CACT4Y+YYgs43nJnyg3B9cHWOue62iMW3ZgXQKiKG12A1NVMgtg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-11-07  0:28   ` Szabolcs Nagy
2016-11-21 15:03     ` Dmitry Vyukov
     [not found]       ` <CACT4Y+bq97OPqW9nUoQWDdVfeCv6oOYT0=GeFmOu2rosBz4s2Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-11-22 13:07         ` Szabolcs Nagy
2016-11-07 10:38   ` Cyril Hrubis
     [not found]     ` <20161107103819.GA11374-2UyX9mZUyMU@public.gmane.org>
2016-11-21 15:14       ` Dmitry Vyukov
     [not found]         ` <CACT4Y+aUzdX8NqMu+Y3s53vEmoBw7KysB3g2PEjZ6MyJimki1Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-11-21 15:34           ` Tavis Ormandy
2016-11-21 16:10           ` Cyril Hrubis
2016-11-21 15:37     ` Steven Rostedt
     [not found]       ` <20161121103752.70ad1418-f9ZlEuEWxVcJvu8Pb33WZ0EMvNT87kid@public.gmane.org>
2016-11-21 15:48         ` Dmitry Vyukov
2016-11-21 16:58           ` Cyril Hrubis [this message]
2017-04-21 15:14   ` Carlos O'Donell
2016-11-11 17:10 ` Andy Lutomirski
2016-11-21 15:17   ` Dmitry Vyukov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161121165853.GC27353@rei.lan \
    --to=chrubis@suse.cz \
    --cc=arnd@arndb.de \
    --cc=carlos@redhat.com \
    --cc=davej@codemonkey.org.uk \
    --cc=dvyukov@google.com \
    --cc=kcc@google.com \
    --cc=levinsasha928@gmail.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mtk.manpages@gmail.com \
    --cc=scientist@fb.com \
    --cc=syzkaller@googlegroups.com \
    --cc=taviso@google.com \
    --cc=tglx@linutronix.de \
    --cc=vapier@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).