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.

So what you're saying is all these systems that've been running for perhaps years with quite a few kernel patches - they all still have the old code from v1.0 sitting there somewhere, never deleted from memory? That seems at odds with the text.

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

I'll try to take your word for it - but what you describe and what the authors describe seems to be at odds :)

kgraft and similar schemes are making far smaller changes than moving the entire damn kernel would be.

But you're the only person talking about moving the entire kernel. And the texts do reference moving "thousands of lines" of code as well. It may not always be a huge amount, but the principles are still the same.

If you have the kernel in an area of ram, and you patch a module so that it becomes say 1 byte longer than the original module (or a kilobyte, or terabyte, use whatever number gets you to see the point) then you either need to move everything after that point, or move the module to a larger block of ram.

If you can move a module to another area of ram to accomodate an increase in the size of a module in a running kernel without noticeable performance impact, then you can move a module for any other reason without noticeable performance impact. If not, can you explain how moving the module for patching is safe and done in "microseconds" without stopping processing, but moving it the same module for other reasons requires the stuff you describe? What is the difference other than the reason for the move?

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.

Again, the texts from others say otherwise. These are people I know for a fact have implemented it.

With updating files in Linux, the system works by leaving the old data in place until it is no longer being used - new instances of the program(etc) use the new code, old instances use the old code. Why would this need to be any different?

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.

"Microseconds", according the texts I've read (we're talking moving portions of the kernel, not the whole lot)

So to sum up:

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.

"Microseconds", and done during peak times with no noticeable impact - according to the people who implement the live patching.

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

That, at least, we agree on - while I can see that the processes are in place to allow random relocations of parts of the kernel (and the article is about randomising the entire kernel layout at boot after all, so the kernel isn't being treated as one big block of code that can't be broken up but is being treated as a number of smaller blocks that don't have to reside in any specific place in memory), I can also see that a) there are more exploits than just the few buffer overruns this may stop and b) there has to be pointers to the code and data, and these most be known thus must be discoverable (of course, isolating data and code would be helpful but there must be reasons why it's not as common as we would like).

So while it would be an interesting idea and mitigate against a few attacks, it probably does add load with little gain.