[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170725075217.bfwp7slacegqcv7g@ishxps>
Date: Tue, 25 Jul 2017 10:52:17 +0300
From: Hans Liljestrand <liljestrandh@...il.com>
To: Kees Cook <keescook@...omium.org>
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
"Reshetova, Elena" <elena.reshetova@...el.com>,
Dave Hansen <dave.hansen@...el.com>,
"H. Peter Anvin" <hpa@...or.com>,
Daniel Micay <danielmicay@...il.com>
Subject: Re: [RFC PATCH 3/5] x86: add mpxk-wrappers
On Mon, Jul 24, 2017 at 07:45:21PM -0700, Kees Cook wrote:
>On Mon, Jul 24, 2017 at 6:38 AM, Hans Liljestrand
><liljestrandh@...il.com> wrote:
>> This adds actual implementation for mpxk-wrapper functions. The wrapper
>> function are used by the instrumentation to update and check pointer bounds
>> on functions that alter memory, e.g. kmalloc and memcpy. The kmalloc
>> wrapper function for instance simply executes kmalloc, associates bounds
>> with the returned pointer, and returns both. Other wrapper functions, such
>> as for memcpy, also check the bounds of incoming arguments.
>>
>> For future work these wrappers could potentially be replaced by direct
>> instrumentation without the need to incur the cost of calling the wrapper
>> function. In this scenario every kmalloc would simply be preceded by an
>> appropriate mkbnd instruction, and memcpy preceded by bndcu+bndcl
>> instructions.
>>
>> The wrappers are added by the MPXK gcc-plugin, and as such work on
>> preprocessed code. This introduces another problem with our
>> implementation since macros might actually be used to direct "base
>> functions" into specific implementations (e.g. memcpy might be a macro
>> pointing to __memcpy). One solution is covering all possibilities, but
>> this might introduce unwanted code bloat.
>
>I'd be curious to see how (if?) this interacts with CONFIG_FORTIFY. It
>seems that currently the MPXK checks would be similar to the
>inter-object checks as they exist (e.g. checking the size of the whole
>kmalloc allocation), but it wouldn't work on intra-object copies (i.e.
>bounds checking a field within an object).
Do you mean the FORTIFY_SOURCE thing (could not find anything directly on
CONFIG_FORTIFY). Based on a quick look FORTIFY_SOURCE is localized, and
essentially just provides the equivalent os our "wrappers", but I could be
wildly off?
MPXK on the other hand also checks other pointer dereferences and propagates
pointer bounds into non-wrapper functions. The wrappers themselves also do not
load any bounds, instead the calling function passes in the pointer bounds via
the bound registers (although the caller might, depending on the situation
have loaded the bounds based on the kmalloc allocation).
Regarding inter-objects thing MPXK is a bit fuzzy, which is one of the
weaknesses of our approach in general. The mpxk_load_bounds functions uses the
whole kmalloc allocation, but MPX also uses narrowing, which (in some cases)
narrows pointer bounds to intra-object pointers (excluding first fields and
pointers into arrays, which all retain the bounds of the whole structure). The
narrowing is provided by vanilla GCC MPX instrumentation, not specific to our
MPXK code. As a guarantee we therefore cannot say more than that we enforce
the whole kmalloc area (provided kmalloc was used).
>
>More directly, I'd be curious to see coverage and performance
>comparisons between FORTIFY and MPXK.
Based on the above we have seen KASAN as the more direct comparison, or would
you disagree? In the any case, we would also like to get some actual
comparisons done.
Can you recommend any "standard" way of doing measurements, either coverage or
performance, for this kind of protections?
Thanks,
-hans
>
>-Kees
>
>--
>Kees Cook
>Pixel Security
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.
