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]

Message-ID: <CACT4Y+ZHeD=xyQyoD8DKitxP31LLZ1zKwcUmJVDBF4Gk+PC5Ow@mail.gmail.com>
Date:   Wed, 28 Dec 2016 08:32:53 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     "Levin, Alexander" <alexander.levin@...izon.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 Tue, Dec 27, 2016 at 6:23 PM,  <alexander.levin@...izon.com> 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@...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?

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


>> > 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.