# kernel question

## ee99ee2

Just had an idea a minute ago. What would be required for dynamic kernel switching? Is it at all possable? I know you can't do it now, but I'm saying if someone were to re-write something, could it be done?

-ee99ee2

----------

## B_F_Skinner

I don't think it would be possible to "hot swap" a kenel.  I mean, if the kernel were running, what would do the switching?  (The kernel can't do it b/c it is being switched).  What would load the kernel after you killed the old one?  Wouldn't killing a running kernel in essence kill any running processes as well (basically, shut down the system)?

----------

## carmiac

I'm fairly certain that something like this could happen acutally, you would just lose all running processes, but there might even be a way around that.  

Here is why I think so:

In BeOS land there was a free version that could install inside a large loopback file in windows9x.  There was a small app that came with the install  that would shutdown windows and load BeOS without rebooting the machine.  In effect it made a "hot" kernel swap, and a whole lot more.  It did have a few problems, mostly due to windows leaving hardware in an unuseable state after shutting down, but it did work.

It you were switching between two kernels for the same OS and they were both aware of hot swapping capabilities it might be possible to hot swap without losing processes by having the unloading kernel save its state, drivers state, processes, ram, etc to hd and then perform the swap however that BeOS loader did it and the the new kernel could restore the system as long as it had >= the modules and such that the old one had.

It would be very cool to be able to due, but I dont know how much real use it would have.

----------

## KiTaSuMbA

I think there is already a dirty hack to change kernels on-the-fly. The problem is that a kernel is already loaded on your RAM so it sounds like the old kernel should commit suicide _while_ loading the new one. However I don't want to discuss this method on a "can it be done?" level but rather on a "is it a good idea to want this feature?". And my answer is NO. Many security critical systems are built as monolithic (no modules) to avoid that a security compromise in userland leads to kernel alteration (through loading compromised modules that is). Now imagine if you can swap a kernel entirely! 

It's more of a bug than a feature... It's a design choice just asking for trouble.

----------

## choward

 *KiTaSuMbA wrote:*   

> I think there is already a dirty hack to change kernels on-the-fly. 

 

It's not a dirty hack, it's called kexec and it's being worked on by Eric Biederman.  I don't think it's in 2.5, but it will be for sure in 2.7.

 *Quote:*   

> Many security critical systems are built as monolithic (no modules) to avoid that a security compromise in userland leads to kernel alteration (through loading compromised modules that is). Now imagine if you can swap a kernel entirely! 

 

This argument is widely disupted by the kernel hackers.  Loading a module is a root operation, and if you have root you can just modify /dev/[k]mem directly, so you can get around not being able to load modules anyway.

----------

## KiTaSuMbA

Using /dev/mem... hmmm

Try cat /dev/mem to get an idea of what's in there... Now compare this to swapping kernels after compiling the rooted one calmly at home...

The first case is almost-magic, the second.. well even a script-kiddie could deploy that one!

----------

## BigRedDot

 *Quote:*   

>  Try cat /dev/mem to get an idea of what's in there... Now compare this to swapping kernels after compiling the rooted one calmly at home...
> 
> The first case is almost-magic, the second.. well even a script-kiddie could deploy that one!

 

The point he is trying to make is that if you cannot control root, you have no security, completely irregardless of whether the kernel can be "hot swapped" or not.  That is why your argument is not convincing.

On the other hand, I can certainly imagine situations where it would be beneficial to upgrade a running kernel without downtime.  When I worked for motorola, some of the file servers (Auspex's) had the file and network server portions of the OS split physically onto different processor boards so that the main OS could be rebooted with no interuption to these services. I am sure if there was a way to reliably replace a running kernel without requiring a physical reboot many IT departments would jump at it.

----------

## choward

 *KiTaSuMbA wrote:*   

> Using /dev/mem... hmmm
> 
> Try cat /dev/mem to get an idea of what's in there... Now compare this to swapping kernels after compiling the rooted one calmly at home...
> 
> The first case is almost-magic, the second.. well even a script-kiddie could deploy that one!

 

That's a good point, but I'd rather not rely on security by obscurity.  Being forced to use /dev/mem certainly raises the bar on the amount of skill required to crack the box, but it's impossible to remove the threat completely.

The /dev/mem argument  was present on lkml when someone suggested disabling module support in order to prevent malicious code being added to the kernel while running.

----------

## gsfgf

along these lines, will there ever be a way to rescue a hardlocked system?

----------

## KiTaSuMbA

A good security policy is always multi-leveled starting at the firewall and ending at the chair.  Even if they take root you still have a good chance of realising what's going on in useful times. An appropriately hacked kernel is going to make detection a lot more harder...

----------

## BigRedDot

 *Quote:*   

> Even if they take root you still have a good chance of realising what's going on in useful times. An appropriately hacked kernel is going to make detection a lot more harder...

 

Maybe so, maybe no.  It still merits an actual risk/benefit analysis rather than a knee-jerk response.  If downtime costs you something like a million dollars an hour (in lost sales, idle wages, and such --  not too far off the figure quoted to me at one job) and you run 24/7/365, then you may very well calculate that the benfit outweighs the risk. Espcially if, say, you run an isolated internal network and you have a rigorous policy already in place.  

If it doesn't make sense for you, then you don't install a kernel with that capability, and voila, that capability can't be exploited.  That's no reason to say it "should not" be pursued by anyone who might disagree.

----------

## choward

 *gsfgf wrote:*   

> along these lines, will there ever be a way to rescue a hardlocked system?

 

I rather doubt it.  A system hardlocks for one of two reasons: hardware failure or kernel failure.

If you have a hardware failure (ie CPU overheats a makes a bad calculation), you're screwed as no software can recover from that.  You can't trust your software if you can't trust your hardware.

If the kernel failed for some reason, the kernel has decided that it can't continue and will stop responding to any command, including a kexec or softreboot.  The kernel should never stop responding, so you've found a bug and the bug should be fixed.  But you can't replace the dead code already on the system with the newer version with the bug fix.

So the moral of the story is, we can lower the occurences of lockups, but we can't fix a dead system.

----------

