On Fri, Oct 19, 2018 at 4:24 AM, Will Deacon <will.deacon@xxxxxxx> wrote: > [+Cyrill Gorcunov for CRIU stuff] > > On Fri, Oct 19, 2018 at 12:15:43PM +0100, Catalin Marinas wrote: >> On Fri, Oct 05, 2018 at 09:47:44AM +0100, Kristina Martsenko wrote: >> > diff --git a/arch/arm64/include/asm/pointer_auth.h b/arch/arm64/include/asm/pointer_auth.h >> > new file mode 100644 >> > index 000000000000..2aefedc31d9e >> > --- /dev/null >> > +++ b/arch/arm64/include/asm/pointer_auth.h >> > @@ -0,0 +1,63 @@ >> > +// SPDX-License-Identifier: GPL-2.0 >> > +#ifndef __ASM_POINTER_AUTH_H >> > +#define __ASM_POINTER_AUTH_H >> > + >> > +#include <linux/random.h> >> > + >> > +#include <asm/cpufeature.h> >> > +#include <asm/sysreg.h> >> > + >> > +#ifdef CONFIG_ARM64_PTR_AUTH >> > +/* >> > + * Each key is a 128-bit quantity which is split across a pair of 64-bit >> > + * registers (Lo and Hi). >> > + */ >> > +struct ptrauth_key { >> > + unsigned long lo, hi; >> > +}; >> > + >> > +/* >> > + * We give each process its own instruction A key (APIAKey), which is shared by >> > + * all threads. This is inherited upon fork(), and reinitialised upon exec*(). >> > + * All other keys are currently unused, with APIBKey, APDAKey, and APBAKey >> > + * instructions behaving as NOPs. >> > + */ >> >> I don't remember the past discussions but I assume the tools guys are ok >> with a single key shared by multiple threads. Ramana, could you ack this >> part, FTR? >> >> (and it would help if someone from the Android and Chrome camps can >> confirm) > > 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. 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(). -Kees -- Kees Cook Pixel Security