Conversation

FFS Linux *please* stop hiding features behind CONFIG_CHECKPOINT_RESTORE just because checkpoint/restore migration is *one* possible usage case for them!!!

Quote Tweet

Rich Felker

@RichFelker

May 16, 2020

Uhg it's not CONFIG_HAVE_ARCH_SOFT_DIRTY but CONFIG_MEM_SOFT_DIRTY, and the latter is hidden behind CONFIG_CHECKPOINT_RESTORE like lots of other useful stuff for no legitimate reason.

Show this thread

Replying to

I hate checkpoint restore... they exposed so many things that were never designed or intended to be part of the public API. It's now used as a justification to avoid fixing tons of security issues and API design flaws. It was the blocker for mitigating en.wikipedia.org/wiki/Sigreturn. :(

en.wikipedia.org

Sigreturn-oriented programming - Wikipedia

Replying to

and

IIRC,

made an SROP patch for the Linux kernel and CRIU is what blocked it from landing. They made a ton of stuff part of the public ABI without really asking anyone or going through a design process for it. It doesn't even work properly...

6:56 AM · May 16, 2020Twitter Web App

Replying to

and

FWIW, I'm not sure exactly what "SROP mitigation" would look like but I suspect it would break other valid things like sigreturn-based ucontext API implementation (IIRC this is used by glibc on one or more archs, and is a good choice of implementation).

Replying to

and

Shadow stacks mitigate it so I'm not particularly concerned since software-based shadow stacks work decently on arm (but not x86 via a simple implementation) and superior hardware-based support should be available in a couple years via CET on x86 and memory tagging on ARM.

Show replies

Replying to

and

I could come up with better examples since I've seen this block fixing tons of things now. Having a guaranteed backwards compatible ABI is problematic enough without having CRIU turning everything they need into a public ABI with guaranteed backwards compatibility without review.