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

[Mark Rutland <mark.rutland@arm.com>]

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@progbits.org> wrote:
> > On Thu, Nov 10, 2016 at 6:38 PM, Greg KH <gregkh@linuxfoundation.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.