Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 11 Nov 2016 10:00:27 -0800
From: Kees Cook <>
To: Peter Zijlstra <>
Cc: Elena Reshetova <>, 
	"" <>, Arnd Bergmann <>, 
	Thomas Gleixner <>, Ingo Molnar <>, 
	"H. Peter Anvin" <>, Will Deacon <>, 
	Hans Liljestrand <>, David Windsor <>
Subject: Re: [RFC v4 PATCH 12/13] x86: implementation for HARDENED_ATOMIC

On Thu, Nov 10, 2016 at 3:30 PM, Peter Zijlstra <> wrote:
> On Thu, Nov 10, 2016 at 03:07:37PM -0800, Kees Cook wrote:
>> , but basically this
>> is a race in the overflow protection, so it's not operationally a
>> problem. The process that caused the overflow still gets killed, and
>> if the system isn't already set up to panic on oops, this becomes a
>> resource leak instead of an exploitable condition.
> Now is this harmless? If you have two increments racing like:

Adding some annotation for values and the BUG:

>           inc
>           jno 1 // overflow
>                           inc
>                           jno 1 // !overflow
>           dec
>         1:              1:
> The second thread will still affect your wrap and not BUG.

Agreed: the first thread will BUG and the second thread is still halfway to 0.

On systems that panic on BUG, things are protected. For the rest of
the systems, an alternative to "dec" on overflow is to sub (more than)
NR_CPUS, to keep the saturation below the overflow level. This means
that it is still detected (BUG) by at least 1 thread, and cannot reach
0 (to trigger the flaw) on all other threads, even if they all lose
the race.

Some further details on examining the race is here:

To me, this seems better than taking the cmpxchg performance hit.


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.