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

[alexander.levin@verizon.com]

On Mon, Dec 12, 2016 at 11:29:35AM +0100, Dmitry Vyukov wrote:
> On Wed, Nov 23, 2016 at 3:59 PM,  <alexander.levin@verizon.com> 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:
> https://android.googlesource.com/kernel/tegra/+/android-tegra-3.10/security/tlk_driver/ote_protocol.h
> next_ptr_user is a pointer to te_oper_param. Thus recursive definition.
> 
> Another example is snd_seq_ev_quote:
> http://lxr.free-electrons.com/source/include/uapi/sound/asequencer.h#L194
> 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?
 
> > 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.

-- 

Thanks,
Sasha