Reply to post:

kgraft and similar schemes don't actually delete the old code. To do that, you will need to stop CPUs to make sure they aren't in the middle of executing the code you are deleting. Just like I described.

The scheme it's describing (INT3 yadda yadda) is so it can insert the jumps into code that's not been specifically prepared for it. Just like I described...

(Hmm - noticing a pattern here. Might have something to do with the fact that I have actually implemented a lot of this in other contexts...)

There's a bit of discussion regarding hotpatching in Windows here and how they solved that same issue, in that case by having the code be prepared for it beforehand: https://blogs.msdn.microsoft.com/oldnewthing/20110921-00/?p=9583/

kgraft and similar schemes are making far smaller changes than moving the entire damn kernel would be. Even if it would be nuking old code etc, it's making tiny changes to individual functions, which typically are not interrupt handlers or any of the other tricky cases. It's simply not comparable.

If you're gonna MOVE the kernel code, you need to have all CPUs stop at a safe point.

This would typically mean that you have to stop them one by one as they reach it, not just suddenly stop them all at once.

You'll either have to re-route IRQs from the CPUs one by one as they are being stopped or live with a potentially large random delay in serving IRQs from the CPUs stopped before the others.

Then once they're stopped, or sit spinning at some code you won't be removing, with interrupts disabled, you have a lot of work to do.

For once, you need to locate all function pointers in memory and change them. How would you even do that? You'd need some sort of managed memory scheme to know what's a relevant pointer and not, similar to mark/sweep GC with exact tracing. At the very least, you need full cooperation from ... everything in the kernel. Including all drivers. Good luck with that.

If you want to move the static data as well, you're in for exponentially more fun. You might as well stick a compacting mark/sweep GC in the kernel and be done with it.

How long would all of this take? The answer is most likely "too long" in a lot of cases. At the very least it's utterly unpredictable beforehand.

And for all this you will have accomplished... nothing. Maybe you have prevented some cache/paging side channel attack or something that takes longer to execute than the interval between two "total kernel re-mixes", but that's not what actual kernel exploits use in the wild.

Not to mention that none of this exercise helps you move anything else than the kernel code and possibly static data. You have just moved the kernel code, which is good for stopping things like ROP (eg to disable SMEP), but there are lots of other attack vectors you haven't affected at all.

So to sum up:

How much work would be needed to do it? A lot.

Would the resulting impact on performance, responsiveness and timing cause a problem for anyone? Yes, for a lot of users, and the exact impact would be dependent on the specific combination of kernel, drivers, workload, etc.

How much would it improve security? Very close to nothing.