[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202008150935.4C2F32559F@keescook>
Date: Sat, 15 Aug 2020 09:39:02 -0700
From: Kees Cook <keescook@...omium.org>
To: Alexander Popov <alex.popov@...ux.com>
Cc: Jann Horn <jannh@...gle.com>, Will Deacon <will@...nel.org>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Masahiro Yamada <masahiroy@...nel.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Peter Zijlstra <peterz@...radead.org>,
Krzysztof Kozlowski <krzk@...nel.org>,
Patrick Bellasi <patrick.bellasi@....com>,
David Howells <dhowells@...hat.com>,
Eric Biederman <ebiederm@...ssion.com>,
Johannes Weiner <hannes@...xchg.org>,
Laura Abbott <labbott@...hat.com>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
kasan-dev@...glegroups.com, linux-mm@...ck.org,
kernel-hardening@...ts.openwall.com, linux-kernel@...r.kernel.org,
notify@...nel.org
Subject: Re: [PATCH RFC 0/2] Break heap spraying needed for exploiting
use-after-free
On Thu, Aug 13, 2020 at 06:19:20PM +0300, Alexander Popov wrote:
> I've found an easy way to break heap spraying for use-after-free
> exploitation. I simply extracted slab freelist quarantine from KASAN
> functionality and called it CONFIG_SLAB_QUARANTINE. Please see patch 1.
Ah yeah, good idea. :)
> [...]
> I did a brief performance evaluation of this feature.
>
> 1. Memory consumption. KASAN quarantine uses 1/32 of the memory.
> CONFIG_SLAB_QUARANTINE disabled:
> # free -m
> total used free shared buff/cache available
> Mem: 1987 39 1862 10 86 1907
> Swap: 0 0 0
> CONFIG_SLAB_QUARANTINE enabled:
> # free -m
> total used free shared buff/cache available
> Mem: 1987 140 1760 10 87 1805
> Swap: 0 0 0
1/32 of memory doesn't seem too bad for someone interested in this defense.
> 2. Performance penalty. I used `hackbench -s 256 -l 200 -g 15 -f 25 -P`.
> CONFIG_SLAB_QUARANTINE disabled (x86_64, CONFIG_SLUB):
> Times: 3.088, 3.103, 3.068, 3.103, 3.107
> Mean: 3.0938
> Standard deviation: 0.0144
> CONFIG_SLAB_QUARANTINE enabled (x86_64, CONFIG_SLUB):
> Times: 3.303, 3.329, 3.356, 3.314, 3.292
> Mean: 3.3188 (+7.3%)
> Standard deviation: 0.0223
That's rather painful, but hackbench can produce some big deltas given
it can be an unrealistic workload for most systems. I'd be curious to
see the "building a kernel" timings, which tends to be much more
realistic for "busy system" without hammering one particular subsystem
(though it's a bit VFS heavy, obviously).
More notes in the patches...
--
Kees Cook
Powered by blists - more mailing lists