[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 26 Apr 2017 04:01:28 +0200
From: "PaX Team" <pageexec@...email.hu>
To: linux-kernel@...r.kernel.org, Kees Cook <keescook@...omium.org>
CC: Kees Cook <keescook@...omium.org>, Peter Zijlstra <peterz@...radead.org>,
Jann Horn <jannh@...gle.com>, Eric Biggers <ebiggers3@...il.com>,
Christoph Hellwig <hch@...radead.org>,
"axboe@...nel.dk" <axboe@...nel.dk>,
James Bottomley <James.Bottomley@...senpartnership.com>,
Elena Reshetova <elena.reshetova@...el.com>,
Hans Liljestrand <ishkamiel@...il.com>,
David Windsor <dwindsor@...il.com>, "x86@...nel.org" <x86@...nel.org>,
Ingo Molnar <mingo@...nel.org>, Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"David S. Miller" <davem@...emloft.net>,
Rik van Riel <riel@...hat.com>,
linux-arch <linux-arch@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH v2 0/2] x86, refcount: Implement fast refcount overflow
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.
> 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.
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.
