Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 25 Jul 2017 11:22:02 -0700
From: Kees Cook <>
To: Hans Liljestrand <>
Cc: "" <>, 
	"Reshetova, Elena" <>, Dave Hansen <>, 
	"H. Peter Anvin" <>, Daniel Micay <>
Subject: Re: [RFC PATCH 3/5] x86: add mpxk-wrappers

On Tue, Jul 25, 2017 at 12:52 AM, Hans Liljestrand
<> wrote:
> 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?

Yup, I mean this:

> 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).

What are the code patterns that MPXK protects? It sounds like I'm not
quite seeing what MPXK provides beyond the CONFIG_FORTIFY_SOURCE
checks (both need to know the bounds already...)

> Can you recommend any "standard" way of doing measurements, either coverage
> or performance, for this kind of protections?

I say, for build coverage (possibly via some compile-time warning),
how many, e.g., memcpy()s are protected (i.e. bounds are known). And
then similarly, during runtime (possibly via kprobe) how many
memcpy()s are protected?

For performance, it's trickier, and needs a meaningful workload. I've
used hackbench and kernel build times...


Kees Cook
Pixel Security

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.