temporal and spatial locality in the kernel

temporal and spatial locality in the kernel

[Carter Cheng]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

Hi,

I recently attended a computer security conference for the first time and
have developed some interest in kernel hardening issues after one of the
presenters demonstrated a kernel exploit based partly around a use after
free bug.

After scanning the literature a little bit and looking at some papers I
have encountered before on CCured and Cyclone. I was curious to what extent
full memory saftety checks are now possible.

There are many papers going back quite a bit on spatial safety
implementations and some on temporal safety but they mainly target user
space. I am curious why such things don't exist in the linux kernel at
least as some sort of compile option. Is the slow down the main concern?

It seems recent work has got the performance bound down to 1.29 is this
considered too slow for many things?

Regards,

Carter

[-- Attachment #2: Type: text/html, Size: 1013 bytes --]

Re: temporal and spatial locality in the kernel

[Kees Cook]

On Fri, Sep 21, 2018 at 10:25 AM, Carter Cheng <cartercheng@gmail.com> wrote:
> Hi,

Welcome!

> I recently attended a computer security conference for the first time and
> have developed some interest in kernel hardening issues after one of the
> presenters demonstrated a kernel exploit based partly around a use after
> free bug.
>
> After scanning the literature a little bit and looking at some papers I have
> encountered before on CCured and Cyclone. I was curious to what extent full
> memory saftety checks are now possible.

CONFIG_KASAN covers a lot of this, but wasn't itself designed for
"production use". The primary concern, yes, is performance.

> There are many papers going back quite a bit on spatial safety
> implementations and some on temporal safety but they mainly target user
> space. I am curious why such things don't exist in the linux kernel at least
> as some sort of compile option. Is the slow down the main concern?
>
> It seems recent work has got the performance bound down to 1.29 is this
> considered too slow for many things?

This sounds lovely! :) I'd be curious to see patches implementing the
checks you're talking about.

-Kees

-- 
Kees Cook
Pixel Security

Re: temporal and spatial locality in the kernel

[Carter Cheng]

[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]

I suspect any modification would have to be made on the compiler side as
some sort of compiler plugin since skimming over the papers in the area
most optimize by doing some sort of dataflow analysis(removing runtime
checks when not needed). To produce something like this would require
reading through some of the literature and open source and constructing the
compiler transform pass in gcc or clang. Is gcc currently preferred for
something like this?

On Sat, Sep 22, 2018 at 2:41 AM Kees Cook <keescook@chromium.org> wrote:

> On Fri, Sep 21, 2018 at 10:25 AM, Carter Cheng <cartercheng@gmail.com>
> wrote:
> > Hi,
>
> Welcome!
>
> > I recently attended a computer security conference for the first time and
> > have developed some interest in kernel hardening issues after one of the
> > presenters demonstrated a kernel exploit based partly around a use after
> > free bug.
> >
> > After scanning the literature a little bit and looking at some papers I
> have
> > encountered before on CCured and Cyclone. I was curious to what extent
> full
> > memory saftety checks are now possible.
>
> CONFIG_KASAN covers a lot of this, but wasn't itself designed for
> "production use". The primary concern, yes, is performance.
>
> > There are many papers going back quite a bit on spatial safety
> > implementations and some on temporal safety but they mainly target user
> > space. I am curious why such things don't exist in the linux kernel at
> least
> > as some sort of compile option. Is the slow down the main concern?
> >
> > It seems recent work has got the performance bound down to 1.29 is this
> > considered too slow for many things?
>
> This sounds lovely! :) I'd be curious to see patches implementing the
> checks you're talking about.
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
>

[-- Attachment #2: Type: text/html, Size: 2278 bytes --]

Re: temporal and spatial locality in the kernel

[Laura Abbott]

On 09/23/2018 01:39 AM, Carter Cheng wrote:
> I suspect any modification would have to be made on the compilerside as some sort of compiler plugin since skimming over the papers
in the area most optimize by doing some sort of dataflow analysis
(removing runtime checks when not needed). To produce something like
this would require reading through some of the literature and open
source and constructing the compiler transform pass in gcc or clang.
Is gcc currently preferred for something like this?

gcc is still the "official" compiler but LLVM support has come a
long way. I'd recommend starting with a gcc plugin since that's
what we have the most support for. If you want to do work to
add LLVM plugins, that would be great too.

Thanks,
Laura

RE: temporal and spatial locality in the kernel

[Reshetova, Elena]

>I suspect any modification would have to be made on the compiler side as some sort of compiler plugin since skimming over the papers in the area most optimize by doing some sort of dataflow analysis(removing runtime checks when not needed). To >produce something like this would require reading through some of the literature and open source and constructing the compiler transform pass in gcc or clang. Is gcc currently preferred for something like this?

Hi,

We have tried to do some of this via gcc plugin and using existing (still last year) Intel MPX technology to prevent spatial memory errors in kernel. 
Unfortunately MPX support has been now dropped out of both gcc and kernel, so our exercise is more like a past example now.
However our code is still here: https://github.com/ssg-kernel-memory-safety/linux-mpxk

And the paper is here: https://onlinelibrary.wiley.com/doi/full/10.1002/spe.2638

If you are interested to continue on this direction, let me know, Hans and me can at least share the experience and knowledge we got while doing this with you. 

Best Regards,
Elena.

On Sat, Sep 22, 2018 at 2:41 AM Kees Cook <keescook@chromium.org> wrote:
On Fri, Sep 21, 2018 at 10:25 AM, Carter Cheng <cartercheng@gmail.com> wrote:
> Hi,

Welcome!

> I recently attended a computer security conference for the first time and
> have developed some interest in kernel hardening issues after one of the
> presenters demonstrated a kernel exploit based partly around a use after
> free bug.
>
> After scanning the literature a little bit and looking at some papers I have
> encountered before on CCured and Cyclone. I was curious to what extent full
> memory saftety checks are now possible.

CONFIG_KASAN covers a lot of this, but wasn't itself designed for
"production use". The primary concern, yes, is performance.

> There are many papers going back quite a bit on spatial safety
> implementations and some on temporal safety but they mainly target user
> space. I am curious why such things don't exist in the linux kernel at least
> as some sort of compile option. Is the slow down the main concern?
>
> It seems recent work has got the performance bound down to 1.29 is this
> considered too slow for many things?

This sounds lovely! :) I'd be curious to see patches implementing the
checks you're talking about.

-Kees

-- 
Kees Cook
Pixel Security

Re: temporal and spatial locality in the kernel

[Carter Cheng]

[-- Attachment #1: Type: text/plain, Size: 3206 bytes --]

Thanks Elena for the offer. I am actually a bit afraid of commiting to
working on this and then underdelivering though I think I might be able to
give it a serious attempt if nothing comparable ends up in the kernel in a
couple months. I would love to hear what you have learned about the spatial
safety issue from working on it. I am actually curious how a gcc plugin
could ever get accepted into the kernel and be actively maintained even
though I think this is the best way to get memory safety into the kernel
since there are potentially gains in terms of maintenance when automation
is used via static analysis.

Regards,

Carter.

On Wed, Sep 26, 2018 at 4:32 PM Reshetova, Elena <elena.reshetova@intel.com>
wrote:

>
> >I suspect any modification would have to be made on the compiler side as
> some sort of compiler plugin since skimming over the papers in the area
> most optimize by doing some sort of dataflow analysis(removing runtime
> checks when not needed). To >produce something like this would require
> reading through some of the literature and open source and constructing the
> compiler transform pass in gcc or clang. Is gcc currently preferred for
> something like this?
>
> Hi,
>
> We have tried to do some of this via gcc plugin and using existing (still
> last year) Intel MPX technology to prevent spatial memory errors in kernel.
> Unfortunately MPX support has been now dropped out of both gcc and kernel,
> so our exercise is more like a past example now.
> However our code is still here:
> https://github.com/ssg-kernel-memory-safety/linux-mpxk
>
> And the paper is here:
> https://onlinelibrary.wiley.com/doi/full/10.1002/spe.2638
>
> If you are interested to continue on this direction, let me know, Hans and
> me can at least share the experience and knowledge we got while doing this
> with you.
>
> Best Regards,
> Elena.
>
> On Sat, Sep 22, 2018 at 2:41 AM Kees Cook <keescook@chromium.org> wrote:
> On Fri, Sep 21, 2018 at 10:25 AM, Carter Cheng <cartercheng@gmail.com>
> wrote:
> > Hi,
>
> Welcome!
>
> > I recently attended a computer security conference for the first time and
> > have developed some interest in kernel hardening issues after one of the
> > presenters demonstrated a kernel exploit based partly around a use after
> > free bug.
> >
> > After scanning the literature a little bit and looking at some papers I
> have
> > encountered before on CCured and Cyclone. I was curious to what extent
> full
> > memory saftety checks are now possible.
>
> CONFIG_KASAN covers a lot of this, but wasn't itself designed for
> "production use". The primary concern, yes, is performance.
>
> > There are many papers going back quite a bit on spatial safety
> > implementations and some on temporal safety but they mainly target user
> > space. I am curious why such things don't exist in the linux kernel at
> least
> > as some sort of compile option. Is the slow down the main concern?
> >
> > It seems recent work has got the performance bound down to 1.29 is this
> > considered too slow for many things?
>
> This sounds lovely! :) I'd be curious to see patches implementing the
> checks you're talking about.
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
>

[-- Attachment #2: Type: text/html, Size: 4092 bytes --]