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

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Nov 14, 2016 at 12:31:32PM -0800, Kees Cook wrote:
> On Fri, Nov 11, 2016 at 12:17 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Fri, Nov 11, 2016 at 10:04:42AM -0800, Kees Cook wrote:
> >
> >> I'm totally open about how to get there, but things can't just be opt-in.
> >
> > There really is no alternative.
> 
> I realize you feel that way, but if we can find a way to squeeze
> mistakes down to impossible or very small, that has a strong effect on
> the future of avoiding exploitation of these kinds of things.

So new drivers and code in general need review anyway, right? There's
tons of other ways people can do root holes by accident. And this whole
refcount thing is something fairly trivial that even tools could spot.

So I really don't see this we must break the world over this argument.

> > refcount_t; should only have: inc, inc_not_zero, dec_and_test
> 
> Sounds good. Two questions remain:
> 
> - how to deal with existing refcounting atomic_t users that want _add and _sub?

The consensus seems to be to hit them over the head and not do this :-)

> - keeping this fast enough that it can be used even in very sensitive
> places (net, fs, etc).

There's really nothing you can do about it except better hardware. If
you want solid semantics you'll have to have this cmpxchg loop. As said,
the LL/SC archs can do slightly better and could provide an asm version
if they feel like it.

> > stats_t; should only have: add,sub
> 
> Seems right, though why not inc/dec? 

Sure, inc/dec are trivial versions of add/sub :-)

> And shouldn't it have a _read of some kind?

I would imagine _set and _read available for all, although currently
there is the discussion of taking even _read() away from refcount_t and
only providing a printk() format specifier.