Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161111183118.GO11945@leverpostej>
Date: Fri, 11 Nov 2016 18:31:18 +0000
From: Mark Rutland <mark.rutland@....com>
To: kernel-hardening@...ts.openwall.com
Cc: Peter Zijlstra <peterz@...radead.org>,
	Will Deacon <will.deacon@....com>,
	Greg KH <gregkh@...uxfoundation.org>,
	David Windsor <dave@...gbits.org>,
	Elena Reshetova <elena.reshetova@...el.com>,
	Arnd Bergmann <arnd@...db.de>, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <h.peter.anvin@...el.com>
Subject: Re: Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC

On Fri, Nov 11, 2016 at 09:43:00AM -0800, Kees Cook wrote:
> (And now Greg went missing from the reply? Re-added...)
> 
> On Thu, Nov 10, 2016 at 11:50 PM, David Windsor <dave@...gbits.org> wrote:
> > On Thu, Nov 10, 2016 at 6:38 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
> >> On Thu, Nov 10, 2016 at 03:15:44PM -0800, Kees Cook wrote:

> As far as refcount_t is concerned, I worry using cmpxchg will be too
> costly, but it's worth benchmarking.

If that does turn out to be a problem, we could allow architectures to
provide their own implementations of the API, with a generic fallback
otherwise, as we do for other features.

> I suspect the first pass at this style will be:
> 
> 1) create refcount_t, API, and wrap detection
> 2) convert atomic_t-as-refcount users to refcount_t (coccinelle to
> find "dec_and_test" followed by "free"?)

This was problably already covered, but I take it that as part of 1 we'd
migrate kref to refcount_t? 

We should also add coccicheck / checkpatch stuff to detect suspicious
usage in new patches. That'll make fighting the tide less painful (or
teach people to obfuscate their patches, and make it harder, who
knows?).

> 3) create sequence_t API
> 4) convert atomic_t-as-stat users to sequence_t
> 5) implement atomic_t as one-or-the-other based on CONFIG

> 1,2 and 3,4 can happen at the same time.

If we manage 1 and 2, the remaining classes of atomic_t usage should be
far easier to distinguish (which would influence steps 3+).

Currently, it's not entirely clear to me what shapes the remaining
instances would have, and Peter mentioned that they don't fall into the
proposed sequence class.

Thanks,
Mark.

Powered by blists - more mailing lists

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