Re: [RFC 1/3] abi_spec: basic definitions of constraints, args and syscalls

From: Dmitry Vyukov
Date: Wed Dec 28 2016 - 02:33:19 EST

On Tue, Dec 27, 2016 at 6:23 PM, <alexander.levin@xxxxxxxxxxx> wrote:
> On Mon, Dec 12, 2016 at 11:29:35AM +0100, Dmitry Vyukov wrote:
>> On Wed, Nov 23, 2016 at 3:59 PM, <alexander.levin@xxxxxxxxxxx> wrote:
>> > On Mon, Nov 21, 2016 at 03:48:17PM +0100, Dmitry Vyukov wrote:
>> > I imagine that this will be handled by specific logical type handlers we'll
>> > need to implement. Can you give me an example and I'll try to code that?
>> One example is te_oper_param here:
>> next_ptr_user is a pointer to te_oper_param. Thus recursive definition.
>> Another example is snd_seq_ev_quote:
>> it contains struct snd_seq_event *event and snd_seq_event recursively
>> contains snd_seq_ev_quote.
>> In all cases it is pointer recursion via structs.
>> Sometimes it wish that developers have to write formal descriptions in
>> a limited language upfront. That would probably eliminate lots of
>> weird one-off "see what I invented here" cases :)
> We'll need a special handler for each struct passed as a parameter anyway, no?
> In this scenario we just call that handler recursively?

Yes, but you can't describe it the way you started describing
arguments, because you can't put struct type into struct type by

>> > But that means I need a custom handler for every syscall to parse the
>> > struct fields rather than a generic code that goes through the args and calls
>> > the right handler?
>> No, you don't. We will need generic code that parses a piece of memory
>> as a struct and splits it into fields anyway.
>> We can just reuse this code to handle syscall arguments as follows.
>> Describe syscall arguments as a pseudo struct (array of fields). Then
>> syscall handling function accepts pointer to region of memory with
>> arguments and description of the struct, and invokes common struct
>> handling code.
> Oh, I understand your point now - I missed the part about a generic fields
> struct and thought you want a specialized struct for each syscall.
> Yes, that makes sense.
>> >> How would you like us to collaborate on this?
>> >> If you share your git repo, I could form it into something that would
>> >> be suitable for syzkaller and incorporate most of the above.
>> >
>> > I'd really like to have something that either generates these descriptions from
>> > your DSL (it really doesn't have to be perfect (at first)) or something that
>> > generates DSL from these C structs.
>> Do you mean generating C from my DSL of a one-off or as a permanent solution?
> I think it depends on what's easier to maintain - the spec in C or a parser
> for DSL->C.

Let's concentrate on the C part for now. Even with DSL we need to
understand how C should look like. We can decide on DSL later.