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

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

1

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

1

1

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...

2

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).

1

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.

1

Replying to

and

I didn't notice that they removed the dependency of CHECKPOINT_RESTORE on EXPERT. It was kept behind that for a long time since the way they do a lot of things is just a bad idea. They're apparently also trying to remove the CHECKPOINT_RESTORE configuration option as a whole.

1

Replying to

and

i.e. making it mandatory: mail-archive.com/linux-kernel@v Hard to care at this point when Linux has so much insanely high complexity already. I think this feature is pretty insane though and people should just be using virtualization... not migrating across kernel versions/configs.

1

Replying to

and

While I largely agree about checkpont/restore being a poor design, a lot of the functionality hidden behind the config option is very useful and it's ridiculous that it's hidden behind it. For instance several prctls (used to be more of them).

1

Replying to

and

They're using the configuration option to avoid going through the proper design / review process for the features. They add whatever they want and include it behind their own configuration option. They treat it all as something that MUST be done ASAP to avoid having CRIU break.

1

Replying to

and

So, there's useful stuff behind the option because they have a tendency to use the configuration option as their escape hatch. If it hadn't been introduced with the configuration option, it would have been harder to land. It might have ended up being designed better too.

7:23 AM · May 16, 2020Twitter Web App

Replying to

and

It's easier for them to use the configuration option to land whatever they need and then split out portions of it later. I see it as a way of avoiding the appropriate review and debate. People working on stuff that's already in the kernel have privileges like this others don't.