Daniel Micay on Twitter: "@chrisrohlf @lazytyped If you assume pkey state is lost on older kernels and set things up again that's going to be broken on kernels with it backported. I asked them to add a no-op flag to pkey_alloc so implementations could tell if pkey state is preserved on fork and handle both but they didn't..." / Twitter

By the way, I checked again and the patch did land for Linux 5.0: github.com/torvalds/linux If your use case depends on the key state being present after fork, you'll need to disable that part of the feature (such as dlopen library support) on kernels earlier than Linux 5.0.

This Tweet was deleted by the Tweet author. Learn more

Daniel Micay

@DanielMicay

Mar 20, 2019

Replying to

@chrisrohlf

and

@lazytyped

I don't think there's a safe in-process way to safely detect the patch, so unfortunately disabling features depending on it after fork on older kernels or simply not activating them at all seems like the only viable option. Can't work around it since the patch may be backported.

1

Replying to

and

If you assume pkey state is lost on older kernels and set things up again that's going to be broken on kernels with it backported. I asked them to add a no-op flag to pkey_alloc so implementations could tell if pkey state is preserved on fork and handle both but they didn't...

1:50 PM · Mar 20, 2019Twitter Web Client

Replying to

and

My plan is to check for Linux 5.0+ and disable code turning off the feature after fork. It'd be possible to make a table with stable/longterm branches and enable it on those once they're past the point that it was backported upstream. I wish the fix could just be easily detected.

1

Replying to

and

MAP_FIXED_NOREPLACE has a similar portability issue due to this bug I hit: patchwork.kernel.org/patch/10634763/ . On older kernels, it's completely broken and clobbers mappings. Not all distributions backport these fixes. Unlike the pkey issue it's easy to safely detect the bug in-process.

1

Show replies

Conversation