Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Mar 2017 18:42:29 -0800
From: Tycho Andersen <>
To: Kees Cook <>
Cc: "" <>
Subject: Re: Ahoy!

Hey Kees,

On Wed, Mar 08, 2017 at 03:17:55PM -0800, Kees Cook wrote:
> On Tue, Mar 7, 2017 at 3:37 PM, Tycho Andersen <> wrote:
> > I'm a new engineer at Docker, and I've been given some time to work on
> > kernel security, so I figured I'd introduce myself here. I'm currently
> > trying to figure out what a good first small-ish project that matches up
> > with the company's interests (containers, infrastructure that is used for
> > security primitives like eBPF).
> >
> > Thoughts about areas to poke at are much appreciated!
> Hi! Welcome to the fun!
> As I understand it (for our earlier chat), Docker is mainly x86, which
> somewhat limits choices from the existing KSPP TODO list which has a
> lot of arm and arm64 stuff on it. :)

Yes, unfortunately :(.

> So, here's one that isn't protection exactly, but rather a requested
> arrangement of Kconfig logic: it would be nice if HARDENED_USERCOPY
> depended on !DEVKMEM and STRICT_DEVMEM=y, but this isn't quite trivial
> since STRICT_DEVMEM doesn't exist for all architectures, but maybe it
> should be looking at ARCH_HAS_DEVMEM_IS_ALLOWED... (it seems Dan
> Williams cleaned this up a lot already in commit 21266be9ed542)
> Regardless, no one has snagged this to make sure that hardened
> usercopy isn't bypassed by things like DEVKMEM or DEVMEM and the lack
> of STRICT_DEVMEM. I'd like to have that off the list, and mostly I
> think it just requires staring at the Kconfigs for a bit to figure out
> the right combination so that people wanting hardened usercopy don't
> accidentally undermine themselves.

Yeah, I think it is fairly simple. Does the attached patch look like
what you had in mind? I can send out a real version to the right
people if it looks reasonable.

> So, that's the first thing that pops out at me. What do you think? :)

I was curious about PAX_MEMORY_STACKLEAK, actually. I noticed in the
initial KSPP announcement email you mentioned it, and it's not clear
to me that anything actually got merged for it.

I understand in principle what needs to happen, but I'm not sure I
understand why a gcc plugin is required. Anyway, it seems like a
small-ish change (that could be hid behind a sysctl or a compiler
flag) that is reasonable enough to start with. Thoughts?



View attachment "0001-security-Kconfig-further-restrict-HARDENED_USERCOPY.patch" of type "text/x-diff" (942 bytes)

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.