Re: [PATCH 1/2] x86/pkeys: copy pkey state at fork()

[Andy Lutomirski <luto@amacapital.net>]

> On Oct 26, 2018, at 2:39 PM, Daniel Micay <danielmicay@gmail.com> wrote:
> 
> I ended up working around this with a pthread_atfork handler disabling
> my usage of the feature in the child process for the time being. I
> don't have an easy way to detect if the bug is present within a
> library so

Can you not just make sure that the fix is backported to all relevant kernels?

I suppose we could add a new flag for pkey_get() or something.

> I'm going to need a kernel version check with a table of
> kernel releases fixing the problem for each stable branch.

That won’t work right on district kernels. Please don’t go there.

> 
> It would be helpful if there was a new cpuinfo flag to check if the
> MPK state is preserved on fork in addition to the existing ospke flag.
> The problem will fade away over time but in my experience there are a
> lot of people using distributions with kernels not incorporating all
> of the stable fixes. I expect other people will run into the problem
> once hardware with MPK is more widely available and other people try
> to use it for various things like moving GC or assorted security
> features. Someone will end up running software adopting it on an older
> kernel with the problem.
> 
> The clobbering issue I found with MAP_FIXED_NOREPLACE isn't quite
> as annoying because it was easy to make a runtime test usable in a library
> to see if the feature works properly.