Date: Tue, 18 Aug 2020 12:08:47 +0300 From: Alexander Popov <alex.popov@...ux.com> To: Kees Cook <keescook@...omium.org> 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, Andrey Konovalov <andreyknvl@...gle.com> Subject: Re: [PATCH RFC 0/2] Break heap spraying needed for exploiting use-after-free On 15.08.2020 19:39, Kees Cook wrote: > 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. This can be configured. Quote from linux/mm/kasan/quarantine.c: /* * The fraction of physical memory the quarantine is allowed to occupy. * Quarantine doesn't support memory shrinker with SLAB allocator, so we keep * the ratio low to avoid OOM. */ #define QUARANTINE_FRACTION 32 >> 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). I have new results. CPU: Intel Core i7-6500U CPU @ 2.50GHz Test: time make O=../build_out/defconfig/ -j2 CONFIG_SLAB_QUARANTINE disabled: Times: 10m52.978s 10m50.161s 10m45.601s Mean: 649.58s Standard deviation: 3.04 CONFIG_SLAB_QUARANTINE enabled: Times: 10m56.256s 10m51.919s 10m47.903s Mean: 652.026s (+0,38%) Standard deviation: 3.41 This test shows much lower performance penalty. More ideas of tests? Best regards, Alexander
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.