[kernel-hardening] RE: Still working on PAX_USERCOPY

[kernel-hardening] RE: Still working on PAX_USERCOPY

[Schaufler, Casey]

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

On 1/19/2016 3:59 PM, Kees Cook wrote:

> On Thu, Jan 14, 2016 at 5:43 PM, Schaufler, Casey

> <casey.schaufler@intel.com<mailto:casey.schaufler@intel.com>> wrote:

>> Just a brief status update on my work on PAX_USERCOPY. I've ditched my first

>> two attempts at doing somewhat simple minded cut'n'patch and am going to

>> have to take a more engineering (e.g. understanding what's really going on)

>> approach. The good news is that I've made enough mistakes to think there

>> aren't that many left for a project this size.

> Thanks for the report! Were you able to use or improve on the

> lib/test_user_copy.c tests during your experiments? (Or maybe we just

> need a separate lkdtm test?)



No, but hopefully before too long ...



> What kinds of dead-ends did you run into?



There are a few things that are "obvious", the GFP_USERCOPY

and CONFIG_PAX_USERCOPY (duh?) bits being the most so. And

yet, they turn out not to be so obvious. Much of what's under

ifdef isn't actually part of the feature, it's special cases

in other PAX features. PAX_USERCOPY appears to have come along

fairly late in the PAX feature set, and counts on a bunch of

previously implemented facilities. There are chunks of stack

management, for example, that (I think) have to be included.



It's not enough to understand PAX_USERCOPY. You really have

to understand all of the PAX and grsecurity memory management

changes to come up with something that works. That's what I'm

working on now, and while there's progress, it's a slog.



I'm embarking on what Intel calls a "mini-sabbatical", which

will take me away from my keyboard for 4 weeks. When I return

I plan to pick up where I left off. Hopefully with fresher and

better rested eyes.



> -Kees

>



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

[kernel-hardening] Re: Still working on PAX_USERCOPY

[Kees Cook]

On Thu, Jan 14, 2016 at 5:43 PM, Schaufler, Casey
<casey.schaufler@intel.com> wrote:
> Just a brief status update on my work on PAX_USERCOPY. I’ve ditched my first
> two attempts at doing somewhat simple minded cut’n’patch and am going to
> have to take a more engineering (e.g. understanding what’s really going on)
> approach. The good news is that I’ve made enough mistakes to think there
> aren’t that many left for a project this size.

Thanks for the report! Were you able to use or improve on the
lib/test_user_copy.c tests during your experiments? (Or maybe we just
need a separate lkdtm test?)

What kinds of dead-ends did you run into?

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security