|
Message-ID: <1479228602.4622.64.camel@redhat.com>
Date: Tue, 15 Nov 2016 11:50:02 -0500
From: Rik van Riel <riel@...hat.com>
To: kernel-hardening@...ts.openwall.com,
Peter Zijlstra
<peterz@...radead.org>
Cc: 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 Mon, 2016-11-14 at 12:31 -0800, Kees Cook wrote:
> On Fri, Nov 11, 2016 at 12:17 PM, Peter Zijlstra <peterz@...radead.or
> g> 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.
>
> >
> > 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?
> - keeping this fast enough that it can be used even in very sensitive
> places (net, fs, etc).
>
> >
> > stats_t; should only have: add,sub
> Seems right, though why not inc/dec? And shouldn't it have a _read of
> some kind?
>
> Keeping the implementation details of refcount_t and stats_t opaque
> to
> the users should discourage misuse...
I suspect a lack of inc_not_zero and dec_and_test would
be the biggest things discouraging misuse of stats_t
for reference counting :)
--
All rights reversed
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
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.