kernel-hardening - Re: Re: [RFC v4 PATCH 00/13] HARDENED

Follow @Openwall on Twitter for new release announcements and other news

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

Message-ID: <20161117093600.GE3142@twins.programming.kicks-ass.net>
Date: Thu, 17 Nov 2016 10:36:00 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: "Reshetova, Elena" <elena.reshetova@...el.com>
Cc: Rik van Riel <riel@...hat.com>,
	"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
	Will Deacon <will.deacon@....com>,
	Greg KH <gregkh@...uxfoundation.org>,
	David Windsor <dave@...gbits.org>, Arnd Bergmann <arnd@...db.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"Anvin, H Peter" <h.peter.anvin@...el.com>,
	"Julia.Lawall@...6.fr" <Julia.Lawall@...6.fr>
Subject: Re: Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC

On Thu, Nov 17, 2016 at 09:04:44AM +0000, Reshetova, Elena wrote:
> > I have a coccinelle rule now that found about 15 usages of it. 
> 
> >Right, so can coccinelle detect the call_rcu/free call that is
> >conditional on the dec_and_test when its hidden inside a few function
> >calls?
> 
> Yes, it can. However, I haven't expanded the rule yet to cover cases
> when "hidden inside a few function calls" goes outside of one .c or .h
> file. Coccinelle supports that, but I have to experiment fist if it
> doesn't bring more false positives that current setup. 

Sure, I can see cross translation unit being slightly more challenging
:-)

> >Also, we should really have a "make spatch" target so that we can run
> >the thing concurrently with -j80 or somesuch, because as is
> >coccinelle is unbearably slow.
> 
> The currents rules are very simple, the full run on the whole tree
> even without any pre-indexing, multithreading and etc. takes around 1
> min only.  

I tried to run something like (thanks to Thomas):


@r1@
struct kref K;
@@
-atomic_read(&K.refcount)
+kref_read(&K)

@r2@
struct kref *x;
@@
-atomic_read(&x->refcount)
+kref_read(x)

@r3@
struct kref K;
@@
-K.refcount.counter
+kref_read(&K)

@r4@
struct kref *x;
@@
-x->refcount.counter
+kref_read(x)

@@
expression K;
@@
-atomic_read(&K.refcount)
+CHECKKREF(kref_read(&K))

//@@
//expression K;
//@@
//- atomic_read(&K->refcount)
//+ CHECKBAD(kref_read(K))



using:

 spatch --in-place --sp-file kref.cocci --recursive-includes
 --include-headers -I include -I include/drm -I include/uapi
 --use-gitgrep --dir .


And that took for bloody ever, far longer than building a full bzImage.

That basically renders the thing useless in my view.

Another advantage of integrating it with make is that we get all the
right -I parameters for free.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.