On 11/06/2016 05:39 PM, Dmitry Vyukov 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
On 11/06/2016 05:39 PM, Dmitry Vyukov 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
* Dmitry Vyukov [2016-11-21 16:03:04 +0100]:
> On Mon, Nov 7, 2016 at 1:28 AM, Szabolcs Nagy wrote:
> > * Dmitry Vyukov [2016-11-06 14:39:28 -0800]:
> >> For the reference, current syzkaller descriptions are in txt files here:
> >>
* Dmitry Vyukov [2016-11-21 16:03:04 +0100]:
> On Mon, Nov 7, 2016 at 1:28 AM, Szabolcs Nagy wrote:
> > * Dmitry Vyukov [2016-11-06 14:39:28 -0800]:
> >> For the reference, current syzkaller descriptions are in txt files here:
> >> https://github.com/google/syzkaller/tree/master/sys
> > ...
>
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
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
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.
>
>
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.
>
>
On Mon, Nov 21, 2016 at 4:37 PM, Steven Rostedt wrote:
> On Mon, 7 Nov 2016 11:38:20 +0100
> Cyril Hrubis wrote:
>
>
>> I'm not sure if something like this is really doable or in the scope of
>> this project, but it may be worth a try.
>>
>
> Looking ahead
On Mon, Nov 21, 2016 at 4:37 PM, Steven Rostedt wrote:
> On Mon, 7 Nov 2016 11:38:20 +0100
> Cyril Hrubis wrote:
>
>
>> I'm not sure if something like this is really doable or in the scope of
>> this project, but it may be worth a try.
>>
>
> Looking ahead into the future, I was also thinking
On Mon, 7 Nov 2016 11:38:20 +0100
Cyril Hrubis wrote:
> I'm not sure if something like this is really doable or in the scope of
> this project, but it may be worth a try.
>
Looking ahead into the future, I was also thinking that if this becomes
robust, we could also start an
On Mon, 7 Nov 2016 11:38:20 +0100
Cyril Hrubis wrote:
> I'm not sure if something like this is really doable or in the scope of
> this project, but it may be worth a try.
>
Looking ahead into the future, I was also thinking that if this becomes
robust, we could also start an integration
On Mon, Nov 21, 2016 at 7:14 AM, Dmitry Vyukov wrote:
>
>
> 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.
>
> Cyril, Tavis, can
On Mon, Nov 21, 2016 at 7:14 AM, Dmitry Vyukov wrote:
>
>
> 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.
>
> Cyril, Tavis, can you come up with some
On Fri, Nov 11, 2016 at 6:10 PM, Andy Lutomirski wrote:
> On Sun, Nov 6, 2016 at 2:39 PM, Dmitry Vyukov wrote:
>> Hello,
>>
>> This is notes from the discussion we had at Linux Plumbers this week
>> regarding providing a formal description of system calls
On Fri, Nov 11, 2016 at 6:10 PM, Andy Lutomirski wrote:
> On Sun, Nov 6, 2016 at 2:39 PM, Dmitry Vyukov 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
On Mon, Nov 7, 2016 at 11:38 AM, Cyril Hrubis wrote:
> Hi!
>> We identified a surprisingly large number of potential users for such
>> descriptions:
>> - fuzzers (syzkaller, trinity, iknowthis)
>> - strace/syscall tracepoints (capturing indirect arguments and
>>printing
On Mon, Nov 7, 2016 at 11:38 AM, Cyril Hrubis wrote:
> Hi!
>> We identified a surprisingly large number of potential users for such
>> descriptions:
>> - fuzzers (syzkaller, trinity, iknowthis)
>> - strace/syscall tracepoints (capturing indirect arguments and
>>printing human-readable info)
On Mon, Nov 7, 2016 at 1:28 AM, Szabolcs Nagy wrote:
> * Dmitry Vyukov [2016-11-06 14:39:28 -0800]:
>> This is notes from the discussion we had at Linux Plumbers this week
>> regarding providing a formal description of system calls (user API).
> yes a
On Mon, Nov 7, 2016 at 1:28 AM, Szabolcs Nagy wrote:
> * Dmitry Vyukov [2016-11-06 14:39:28 -0800]:
>> This is notes from the discussion we had at Linux Plumbers this week
>> regarding providing a formal description of system calls (user API).
> yes a database of the syscall abis would be useful
On Sun, Nov 6, 2016 at 2:39 PM, Dmitry Vyukov 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
On Sun, Nov 6, 2016 at 2:39 PM, Dmitry Vyukov 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
Hi!
> We identified a surprisingly large number of potential users for such
> descriptions:
> - fuzzers (syzkaller, trinity, iknowthis)
> - strace/syscall tracepoints (capturing indirect arguments and
>printing human-readable info)
> - generation of entry points for C libraries (glibc,
Hi!
> We identified a surprisingly large number of potential users for such
> descriptions:
> - fuzzers (syzkaller, trinity, iknowthis)
> - strace/syscall tracepoints (capturing indirect arguments and
>printing human-readable info)
> - generation of entry points for C libraries (glibc,
* Dmitry Vyukov [2016-11-06 14:39:28 -0800]:
> This is notes from the discussion we had at Linux Plumbers this week
> regarding providing a formal description of system calls (user API).
yes a database of the syscall abis would be useful
..depending on the level of detail it
* Dmitry Vyukov [2016-11-06 14:39:28 -0800]:
> This is notes from the discussion we had at Linux Plumbers this week
> regarding providing a formal description of system calls (user API).
yes a database of the syscall abis would be useful
..depending on the level of detail it has.
(right now
26 matches
Mail list logo