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.