[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 21 Jan 2016 13:45:19 +0100
From: Yves-Alexis Perez <corsac@...ian.org>
To: kernel-hardening@...ts.openwall.com, Kees Cook <keescook@...omium.org>
Cc: David Windsor <dave@...gbits.org>
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.
Regards,
--
Yves-Alexis
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.
