Messages in this thread |  | | From | alexander.levin@verizon ... | Subject | Re: [RFC 1/3] abi_spec: basic definitions of constraints, args and syscalls | Date | Tue, 27 Dec 2016 17:23:24 +0000 |
| |
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
|  |