On Fri, Apr 21, 2017 at 3:55 AM, Reshetova, Elena <elena.reshetova@xxxxxxxxx> wrote: > On Thu, Apr 20, 2017 at 11:33 AM, Eric Biggers <ebiggers3@xxxxxxxxx> wrote: >> Of course, having extra checks behind a debug option is fine. But they should >> not be part of the base feature; the base feature should just be mitigation of >> reference count *overflows*. It would be nice to do more, of course; but when >> the extra stuff prevents people from using refcount_t for performance reasons, >> it defeats the point of the feature in the first place. > > Sure, but as I said above, I think the smaller tricks and fixes won't be convincing enough, > so their value is questionable. > >> I strongly encourage anyone who has been involved in refcount_t to experiment >> with removing a reference count decrement somewhere in their kernel, then trying >> to exploit it to gain code execution. If you don't know what you're trying to >> protect against, you will not know which defences work and which don't. > > Well, we had successful CVEs and even exploits on this in the past. > @Kees, do you store a list of them in the project? Here are two from last year: http://perception-point.io/2016/01/14/analysis-and-exploitation-of-a-linux-kernel-vulnerability-cve-2016-0728/ http://cyseclabs.com/page?n=02012016 I don't disagree with Eric on the threat model: the primary concern for reference count protection is the overflow condition. Detecting a prior use-after-free is certainly nice to have, but the more important case is the initial overflow. How about we introduce something like CONFIG_HAVE_ARCH_FAST_REFCOUNT_T for per-arch implementations and CONFIG_FAST_REFCOUNT_T that trades coverage for speed, and checks only the overflow condition. This gets us the critical coverage without the changes in performance. This is basically what PaX/grsecurity already did: there is a tiny change to the atomic inc functions to detect the wrap. -Kees -- Kees Cook Pixel Security
