linux-kernel - Re: [RFC 0/3] ABI spec

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 12 Dec 2016 11:12:44 +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>,
        Nicholas Mc Guire <der.herr@...r.at>
Subject: Re: [RFC 0/3] ABI spec - verification

On Wed, Nov 23, 2016 at 3:36 PM,  <alexander.levin@...izon.com> wrote:
> On Mon, Nov 21, 2016 at 03:25:05PM +0100, Dmitry Vyukov wrote:
>> On Wed, Nov 16, 2016 at 6:37 PM,  <alexander.levin@...izon.com> wrote:
>> > As discussed at plumbers, having a standard spec for the kernel's ABI has
>> > quite a few uses and enough people wanted it to get the ball rolling.
>> >
>> > We agreed that it's desirable to have something that can be used from code
>> > rather than just a spec on paper both for validation and allowing other users
>> > (like fuzzers, userspace libraries, and various userspace tools) to build
>> > on that.
>> >
>> > What we ended up deciding on at plumbers is:
>> >
>> >  - I'll do a few kernel bits do demonstrate how we can validate the spec from
>> > the kernel.
>> >  - Dmitry Vyukov will provide a way to translate syzkaller's syscall
>> > documentation into something that can be easily used in the kernel and
>> > userspace.
>> >  - Various projects will attempt to integrate it to make sure that the
>> > framework works for them.
>> >
>> > Once those bits are done we can focus on getting the spec right, and we'll
>> > have a good way to validate our work both in userspace and in the kernel.
>> >
>> > This patchset is a basic draft of said kernel bits. I mostly want to make
>> > sure that Dmitry and myself are on the same page as to how integration will
>> > look like, but also to open it to criticism and suggestions (bikeshedding).
>>
>>
>> Looks like a good starting point!
>>
>> Do you have a git repo with this somewhere? I have problems applying
>> the patches, seems that my gmail messed them with some weird escaping.
>
> I've pushed it to https://git.kernel.org/cgit/linux/kernel/git/sashal/linux.git/log/?h=abi_spec ,
> will try to keep it updated.

Was paged out by personal matters. Now looking at your code and trying
to extend it to handle more cases.



>> Is the intention that these descriptions are written by hand, or
>> generated from some DSL?
>> I benefited from easier to write descriptions, also I changed several
>> times what code generator generates without changing descriptions.
>> However, an additional level of indirection in the form of code
>> generator introduces own pain to maintain. So I am not too strong
>> here.
>
> I would really to have the descriptions written in just *one* place, either
> by hand the way I did in that example, or in DSL. I understand your point about
> another level of indirection, but I'm afraid that if we don't force a monolithic
> spec we'll end up with way more than 2 different descriptions to maintain.


Yes, it absolutely must be written in just one place.
What I meant is that we write DSL that is also checked into kernel
tree. And then whenever the descriptions change, we also regenerate
code. So that C code is 100% auto generated and never changed by hand.