On Fri, Oct 19, 2018 at 8:49 AM, Will Deacon [off-list ref] wrote:

On Fri, Oct 19, 2018 at 08:36:45AM -0700, Kees Cook wrote:

quoted

On Fri, Oct 19, 2018 at 4:24 AM, Will Deacon [off-list ref] wrote:

quoted

FWIW: I think we should be entertaining a prctl() interface to use a new
key on a per-thread basis. Obviously, this would need to be used with care
(e.g. you'd fork(); use the prctl() and then you'd better not return from
the calling function!).

Assuming we want this (Kees -- I was under the impression that everything in
Android would end up with the same key otherwise?), then the question is
do we want:

  - prctl() get/set operations for the key, or
  - prctl() set_random_key operation, or
  - both of the above?

Part of the answer to that may lie in the requirements of CRIU, where I
strongly suspect they need explicit get/set operations, although these
could be gated on CONFIG_CHECKPOINT_RESTORE=y.

Oh CRIU. Yikes. I'd like the get/set to be gated by the CONFIG, yes.
No reason to allow explicit access to the key (and selected algo) if
we don't have to.

Makes sense.

quoted

As for per-thread or not, having a "pick a new key now" prctl() sounds
good, but I'd like to have an eye toward having it just be "automatic"
on clone().

I thought about that too, but we're out of clone() flags afaict and there's
no arch hook in there. We could add yet another clone syscall, but yuck (and
I reckon viro would kill us).

Or are you saying that we could infer the behaviour from the existing set
of flags?

I mean if it's starting a new thread, it should get a new key
automatically, just like the ssp canary happens in dup_task_struct().

(Or did I miss some context for why that's not possible?)

-Kees

-- 
Kees Cook
Pixel Security