linux-kernel - Re: [PATCH] doc: convert printk-formats.txt to rst

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] [day] [month] [year] [list]

Message-ID: <6ccb79e1-bf1b-0862-ec79-2f3f7763db62@redhat.com>
Date:   Mon, 11 Dec 2017 10:40:54 -0800
From:   Laura Abbott <labbott@...hat.com>
To:     "Tobin C. Harding" <me@...in.cc>, Joe Perches <joe@...ches.com>
Cc:     Dan Carpenter <error27@...il.com>,
        Kees Cook <keescook@...omium.org>,
        Jonathan Corbet <corbet@....net>,
        Randy Dunlap <rdunlap@...radead.org>,
        Andrew Murray <amurray@...-data.co.uk>,
        linux-doc@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] doc: convert printk-formats.txt to rst

On 12/08/2017 10:33 PM, Tobin C. Harding wrote:
> [Adding Laura]
> 
> On Fri, Dec 08, 2017 at 06:18:45PM -0800, Joe Perches wrote:
>> On Sat, 2017-12-09 at 12:27 +1100, Tobin C. Harding wrote:
>>> On Fri, Dec 08, 2017 at 01:22:37PM -0800, Joe Perches wrote:
>>
>>>> Outside of the documentation, what could be useful is for
>>>> someone to add a tool to verify %p<foo> extension to
>>>> the typeof address actually passed as an argument.
>>>
>>> This sounds interesting to work no. At first glance I have no idea how
>>> one would go about this. Some form of static analysis would be a good
>>> place to start, right? I'd like to allocate some cycles to this, any
>>> pointers most appreciated.
>>
>> A gcc-plugin would likely work best.
> 
> What's the learning curve like in your opinion to do a gcc-plugin. I
> recall reading someplace 'deep understanding of how the compiler works'
> or some such thing. I suppose reading the Dragon book would be a good
> place to start?
> 

The hardest part of doing a gcc-plugin is understanding the gccisms.
There isn't much documentation and most of what there is ends up
being "here's how you hook into the compiler at point X" without
showing how you do anything with it. The Dragon book (also known
as "Compilers: Principles, Techniques, and Tools" for those who
haven't heard of it before) is a great resource for general compiler
concepts but it's not helpful for gcc-specific work.

Writing about some of my experiments on my gcc-plugins has been
on my TODO list for a while. 2018 resolution on actually finishing
it perhaps.

> We could also catch pointers being cast to longs and printed with %x
> (and %u) or so I would guess.
> 
>> There was some discussion about such a thing here:
>> http://www.openwall.com/lists/kernel-hardening/2017/02/14/38
> 
> Did you make much progress with this Laura?
> 

Not particularly. I wanted to re-use the kernel's print functionality
in the plugin to automatically check new formats but I went
down a rathole trying to make it work and got side tracked with
other things and never picked it up again.

>> I vaguely recall someone else doing a broader use tool
>> which I believe was not smatch, but my google-fu isn't
>> finding it.
>>
>> It might have been coccinelle based.
> 
> thanks,
> Tobin.
> 

Thanks,
Laura