Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 16 Nov 2015 15:20:22 -0800
From: Kees Cook <>
To: "" <>
Subject: Re: 

On Mon, Nov 16, 2015 at 2:03 PM, Daniel Micay <> wrote:
> On 16/11/15 01:38 AM, David Windsor wrote:
>> I'm currently in the process of preparing my earlier PAX_REFCOUNT patch
>> set for resubmission, and I tend to agree with you - I'm not very
>> hopeful of Linus, et al accepting them.  But, we will try again.
>> With respect to the issue of having a refcount_t type, PAX_REFCOUNT adds
>> overflow protection to the already existing atomic_t type, and creates a
>> new type, atomic_unchecked_t, for non-reference-counter types (i.e.
>> statistical counters).
> Yeah, I'm aware it does it that way. The problem is that it would have
> to be done the other way around for it to land upstream (realistically).

I may be proven wrong in the end, but I totally disagree with you. :)
I think it is valuable to _start_ from a position of protecting the
atomics and then marking those that don't care about overflow (they
are the minority). We should take a stance of whitelist not blacklist
for these features.

> Doing it the only way around would be involve too many changes so it
> wouldn't be feasible to land everything, but the positive side of it is
> that the changes could be landed bit by bit (i.e. one set of refcount
> fields at a time).

We'll see what it looks like, but I think we start by gaining the
protection and people that don't want it can fix it on a case-by-case
basis. I may be naive, but I think it's probably the best place to
work from initially.


Kees Cook
Chrome OS 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.