Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 31 May 2017 06:20:25 -0700
From: Kees Cook <>
To: Davidlohr Bueso <>
Cc: LKML <>, Christoph Hellwig <>, 
	Peter Zijlstra <>, "Eric W. Biederman" <>, 
	Andrew Morton <>, Josh Poimboeuf <>, 
	PaX Team <>, Jann Horn <>, 
	Eric Biggers <>, Elena Reshetova <>, 
	Hans Liljestrand <>, David Windsor <>, 
	Greg KH <>, Ingo Molnar <>, 
	Alexey Dobriyan <>, "Serge E. Hallyn" <>,, 
	Manfred Spraul <>, "" <>, 
	James Bottomley <>, "" <>, 
	Ingo Molnar <>, Arnd Bergmann <>, 
	"David S. Miller" <>, Rik van Riel <>, 
	linux-arch <>, 
	"" <>
Subject: Re: [PATCH v5 0/3] Implement fast refcount overflow protection

On Wed, May 31, 2017 at 5:27 AM, Davidlohr Bueso <> wrote:
> On Tue, 30 May 2017, Kees Cook wrote:
>> A new patch has been added at the start of this series to make the default
>> refcount_t implementation just use an unchecked atomic_t implementation,
>> since many kernel subsystems want to be able to opt out of the full
>> validation, since it includes a small performance overhead. When enabling
>> CONFIG_REFCOUNT_FULL, the full validation is used.
>> The other two patches provide overflow protection on x86 without incurring
>> a performance penalty. The changelog for patch 3 is reproduced here for
>> details:
> To be sure I'm getting this right, after this all archs with the exception
> of x86 will use the regular atomic_t ("unsecure") flavor, right?

If a build does not select CONFIG_REFCOUNT_FULL and lacks
CONFIG_ARCH_HAS_REFCOUNT, refcount_t will be the same at atomic_t
(i.e. no change from the historical behavior where all the ref
counters in the kernel used atomic_t).


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.