[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161121161032.GB27353@rei.lan>
Date: Mon, 21 Nov 2016 17:10:33 +0100
From: Cyril Hrubis <chrubis@...e.cz>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: linux-api@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Michael Kerrisk-manpages <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@...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
Hi!
> Description of "returns fd or this set of errors" looks simple and useful.
> Any test system or fuzzer will be able to verify that kernel actually returns
> claimed return values. Also Carlos expressed interested in errno values
> in the context of glibc.
> I would do it from day one.
>
> Re more complex side effects. I always feared that a description suitable
> for automatic verification (i.e. zero false positives, otherwise it is useless)
> may be too difficult to achieve.
I'm afraid it may be as well. I would expect that we will end up with
something quite complex with a large set of exceptions from the rules.
> Cyril, Tavis, can you come up with some set of predicates that can be
> checked automatically yet still useful?
> We can start small, e.g. "must not alter virtual address space".
I will try to thing about this a bit.
--
Cyril Hrubis
chrubis@...e.cz
Powered by blists - more mailing lists