Previous Entry Share Next Entry
Secure Boot versus Ksplice.
I have been attending many talks on Secure Boot.  The basic idea behind secure boot is to ensure that the bios/bootloader and kernel have not been hacked.  My understanding of how this is done is everything is signed and verified during the bootup.  Nothing can run in the kernel that was not signed and verified.  

Then we Oracle pushing Ksplice.

I can't help but ask the question?

Is ksplice a security disaster waiting to happen?

Hi Dan,

(Disclaimer: I'm one of the founders of Ksplice the company, though I think you'll see that that's not relevant if you read on)

Conveniently, there's an easy answer to your question: no, it's not. Here's why:
Ksplice does not require any advance modification to the kernel.

And that's really the beauty of Ksplice. You don't need to boot into a special "Ksplice-enabled" version of the system; we can update the kernel you are already running!

The consequence of that is that we're not introducing anything that increases the security risk. Fundamentally, if you can load kernel modules on the system, you can update the system the way Ksplice does. In fact, the Ksplice updates themselves are just kernel modules.

So, given that, I think the answer to your question is a resounding no :)

On the contrary, since patching with Ksplice is so easy, it means you're going to do it more often -- so you're actually going to close these security holes right when your vendor releases patches, not several weeks later when you finally get around to scheduling downtime.

As an aside, I don't think Ksplice is incompatible with Secure Boot either. I don't know a ton about it, but if you have a system that has loadable kernel modules at all, you have a system that can use Ksplice. (In fact, we've produced Ksplice updates for a system that can only load signed modules, and everything works just fine.)

I hope that clears things up; if not, please let me know!


No HTML allowed in subject


(will be screened)


Log in