Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 21 Jan 2016 13:45:19 +0100
From: Yves-Alexis Perez <>
To:, Kees Cook <>
Cc: David Windsor <>
Subject: Re: [RFC PATCH v2 00/12] Add PAX_REFCOUNT
 overflow protection

On mer., 2016-01-20 at 20:01 -0500, Daniel Micay wrote:
> It could do some fine-grained randomization. It does have a measurable
> performance cost since it makes allocations colder and there isn't much
> room for adding entropy but it does add up over time. Depending on the
> locking design it could also hurt there too.
> Take a look at OpenBSD malloc if you're interested in it. It has a few
> forms of randomization and they do add 

I also checked in the PaX patch to see if there was something done to harden
slab, and while it's not randomisation, there's some hardening done as part of
PAX_USERCOPY (heap hardening for copy_{from,to}_user stuff).

The patch adds a GFP_USERCOPY/SLAB_USERCOPY flag for allocation, and then use
it for “tagging” allocations of pages which will end up in a
copy_{from,to}_user() call (as far as I can tell, it's a manual approach). The
tagged allocations are then using a separate slab cache from the kernel
itself, so it shouldn't be possible to exploit an UAF: the memory originating
from userland would not be dereferenced as a kernel allocation.

4.5 kernel will apparently include a SLAB_ACCOUNT flag which is use from
accounting. I wonder if it'd be possible to also use it to tag and isolate
memory allocated from different privilege levels.


Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)

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.