Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 25 Apr 2017 20:59:10 -0700
From: Kees Cook <>
To: PaX Team <>
Cc: LKML <>, Peter Zijlstra <>, 
	Jann Horn <>, Eric Biggers <>, 
	Christoph Hellwig <>, "" <>, 
	James Bottomley <>, 
	Elena Reshetova <>, Hans Liljestrand <>, 
	David Windsor <>, "" <>, Ingo Molnar <>, 
	Arnd Bergmann <>, Greg Kroah-Hartman <>, 
	"David S. Miller" <>, Rik van Riel <>, 
	linux-arch <>, 
	"" <>
Subject: Re: [PATCH v2 0/2] x86, refcount: Implement fast refcount overflow

On Tue, Apr 25, 2017 at 7:01 PM, PaX Team <> wrote:
> On 25 Apr 2017 at 15:56, Kees Cook wrote:
>> This protection is a modified version of the x86 PAX_REFCOUNT
>> implementation from PaX/grsecurity. This speeds up the refcount_t API by
>> duplicating the existing atomic_t implementation with a single instruction
>> added to detect if the refcount has wrapped past INT_MAX (or below 0)
>> resulting in a signed value.
> 'signed value' sounds somewhat ambiguous given that in C a signed type (such
> as the one beneath refcount_t) can have both negative and positive values yet
> you didn't mean the latter here i guess.

Yeah, the language for the CPU "sign flag" confuses this. I will
attempt to clarify for future versions.

>> Various differences from PaX:
>> - uses "js" instead of "jo" to trap all signed results instead of just
>>   under/overflow transitions
> there're differences in my 4.11 port but this isn't one of them.

Any changes you'd suggest for upstreaming?


Kees Cook
Pixel 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.