Re: [PATCH 1/2] x86/pkeys: copy pkey state at fork()
From: Andy Lutomirski
Date: Fri Oct 26 2018 - 18:12:24 EST
> On Oct 26, 2018, at 2:39 PM, Daniel Micay <danielmicay@xxxxxxxxx> 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.