Date: Thu, 1 Dec 2016 18:29:15 -0500 From: David Windsor <dwindsor@...il.com> To: Kees Cook <keescook@...omium.org> Cc: Peter Zijlstra <peterz@...radead.org>, "Reshetova, Elena" <elena.reshetova@...el.com>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Greg KH <gregkh@...uxfoundation.org>, "will.deacon@....com" <will.deacon@....com>, Boqun Feng <boqun.feng@...il.com>, Hans Liljestrand <ishkamiel@...il.com>, "aik@...abs.ru" <aik@...abs.ru>, "david@...son.dropbear.id.au" <david@...son.dropbear.id.au> Subject: Re: Conversion from atomic_t to refcount_t: summary of issues On Thu, Dec 1, 2016 at 6:20 PM, Kees Cook <keescook@...omium.org> wrote: > On Thu, Dec 1, 2016 at 3:03 PM, Peter Zijlstra <peterz@...radead.org> wrote: >> On Thu, Dec 01, 2016 at 04:31:16PM -0500, David Windsor wrote: >>> Also, I'd like to point out that while identifying stats_t instances, I >>> have found a similar distribution of non-standard functions (as agreed upon >>> for the stats_t API). >> >>> First, usage of atomic_long_wrap_t (there currently isn't a stats_long_t >>> planned for implementation): >> >> There isn't even a stats_t planned. I'm still very much not convinced >> stats_t is needed or even makes sense. >> >> It wouldn't have any different semantics from atomic_t, and the only >> argument Kees made was that reduced atomic_t usage would make it easier >> to spot refcounts, but you're already building tools to find those. >> >> Once the tools work, who cares. > > The tool is only part of the whole thing. By distinctly splitting the > other major atomic_t usage pattern away from atomic_t, it solidifies a > stats_t as NOT a reference counter. Further, as you pointed out in a another thread, there is value in having a type with an obviously descriptive name that naturally leads the developers to the correct API. Helping reduce misuse of types definitely has value. > It's the slow feature-creep or bad > example situations that I'd like to avoid. Also, tools won't catch > everything, and doing manual inspection is much easier if we know a > stats_t cannot be misused. > > There doesn't seem to be a good reason NOT to have stats_t, beyond the > work needed to create it and audit the places it should be used. > > -Kees > > -- > Kees Cook > Nexus Security
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.