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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 27 Dec 2016 17:23:24 +0000
From:   alexander.levin@...izon.com
To:     Dmitry Vyukov <dvyukov@...gle.com>
CC:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "scientist@...com" <scientist@...com>,
        "glider@...gle.com" <glider@...gle.com>,
        "andreyknvl@...gle.com" <andreyknvl@...gle.com>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "mathieu.desnoyers@...icios.com" <mathieu.desnoyers@...icios.com>,
        "daniel.vetter@...ll.ch" <daniel.vetter@...ll.ch>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 1/3] abi_spec: basic definitions of constraints, args and
 syscalls

On Mon, Dec 12, 2016 at 11:29:35AM +0100, Dmitry Vyukov wrote:
> On Wed, Nov 23, 2016 at 3:59 PM,  <alexander.levin@...izon.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