[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161115080133.GC3142@twins.programming.kicks-ass.net>
Date: Tue, 15 Nov 2016 09:01:33 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Kees Cook <keescook@...omium.org>
Cc: Will Deacon <will.deacon@....com>, Greg KH <gregkh@...uxfoundation.org>,
David Windsor <dave@...gbits.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
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 Mon, Nov 14, 2016 at 12:31:32PM -0800, Kees Cook wrote:
> On Fri, Nov 11, 2016 at 12:17 PM, Peter Zijlstra <peterz@...radead.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.
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.
