31

How does kernel updates itself while it's running without breaking anything in the process?

Jeff Schaller
  • 66,199
  • 35
  • 114
  • 250
Atul
  • 1,851
  • 4
  • 27
  • 38
  • 41
    Short answer is it doesn't. – slebetman Jan 22 '20 at 07:22
  • 10
    The real question (but OT for this site) is why aren't windows able to do the same. I remember with horror the time when I still had an MS partition, and every time it booted it would spend ages updating/restarting/updating again and so on, before you could use the computer at all. Once I even drove to the airport with the laptop running on the passenger seat, because it was updating windows. – user000001 Jan 22 '20 at 08:08
  • 4
    @user000001 Windows kernel already had had hot-patching capability longggggg before Linux gained that ability. It just restarts because user-space apps are too stupid to use the replaced file, and Windows doesn't allow replacing file while it's being opened like Unix. The 64-bit Windows kernel has [100% hot patchability](https://docs.microsoft.com/en-us/archive/blogs/freik/what-does-hot-patchability-mean-and-what-is-it-for) right from the start and it also has [kernel patch protection](https://en.wikipedia.org/wiki/Kernel_Patch_Protection) – phuclv Jan 22 '20 at 12:40
  • 12
    Linux can do live patching [since 2015](https://en.wikipedia.org/wiki/Kpatch) with Ubuntu users can utilize that [since the end of 2016](https://ubuntu.com/blog/live-kernel-patching-from-canonical-now-available-for-ubuntu) – phuclv Jan 22 '20 at 12:40
  • 2
    @phuclv: That may be true, but still it needs to do a lot of work while the user is blocked from doing anything useful. On linux all updates are done which the computer is operation, and if a restart is needed it will take the normal time, not several dozens of minutes. – user000001 Jan 22 '20 at 13:50
  • 5
    Linux was able to do live patching long before that - I was running ksplice+uptrack back in 2010. – Skyler Jan 22 '20 at 15:01
  • @phuclv You are probably confusing hot-patching applications and files, with hot-patching the kernel itself. – Thorbjørn Ravn Andersen Jan 23 '20 at 11:39
  • 1
    @ThorbjørnRavnAndersen no, application have to do hot patching themselves if they want to. Windows and MS have nothing to do with that and can't hot patch user applications[ – phuclv Jan 23 '20 at 14:49
  • @phuclv The actions taken by Windows update... – Thorbjørn Ravn Andersen Jan 23 '20 at 14:50
  • 1
    @Skyler and 64-bit Windows have been available since 2003-2005. That blog about hot-patching was written in 2006 – phuclv Jan 23 '20 at 14:50
  • 1
    @ThorbjørnRavnAndersen Windows update deals with both user space and kernel space, and I'm talking specifically about the kernel space part (as this question is about kernel space) – phuclv Jan 23 '20 at 14:51

1 Answers1

74

When you update the kernel, you actually update the kernel package. On most Linux distributions, what this really does is just register the package in your package manager, add the new modules under /lib/modules, add the initramfs and kernel under /boot, and maybe update the bootloader entries and some other miscellaneous activity. It doesn't generally actually replace the loaded kernel in memory.

At boot, the kernel itself is loaded into memory. That is, even if the file it was loaded from (eg. /boot/vmlinuz) goes away, it's not needed after initial loading of the kernel.

Even if it was needed for something (say, debugging information) and has been replaced, anyone already with an open file handle to it will still be able to use the file, since the backing data won't be deleted until the inode in question has a reference count of 0 (the kernel itself doesn't need such a reference though, since it's already loaded into memory, unlike running processes from userspace executables). Those blocks normally can be fully freed from disk unless you're in the middle of running some user-space program on that file. The Linux kernel doesn't page its own memory, and even decompresses itself on the fly at startup. There's no /proc/.../exe or /proc/.../fd way to access the booted /boot/vmlinuz — the kernel might not even mount the device it was booted from in a netboot or USB-boot situation.

So generally, the kernel doesn't update itself. That's typically done at reboot or kexec time. The kind of thing you're describing does exist for limited use cases as kpatch, kgraft, and ksplice, but generally these can only be used for small and targeted patches, not new upstream kernel releases.

Chris Down
  • 122,090
  • 24
  • 265
  • 262
  • 4
    Also worth noting that this isn't really any different from Windows or macOS. No modern OS does online upgrades to core kernel code for full release updates, because it's actually almost impossible to reliably hot-patch a running executable unless it's a super-targeted patch and you have existing instrumentation in the executable code to allow for it. – Austin Hemmelgarn Jan 22 '20 at 19:51
  • 2
    And [Andrew Tanenbaum will tell you this is one of the reasons microkernels are better than monolithic kernels](https://en.wikipedia.org/wiki/Tanenbaum–Torvalds_debate). – jcaron Jan 23 '20 at 14:22
  • "even if the file it was loaded from goes away"... except it *won't*. On POSIX file systems, unlinked files aren't actually deleted until nothing has an open handle to them any more. This is why you *can* unlink a file in use (unlike on Windows). If you know what you're doing (i.e. can identify the correct file handle), it's possible to relink an unlinked file back into the file system. – Matthew Jan 23 '20 at 16:11
  • 1
    @Matthew I'm afraid you're conflating inode (ie. in the purest `struct inode` sense), file, and data :-) If you read further in the answer you'll see that there's already discussion about inode reference counting. – Chris Down Jan 23 '20 at 16:40
  • 1
    @jcaron Tanembaum wasn't very good on his predictions about microkernels or how soon x86 would be deprecated, however. That discussion didn't age well for his side. I mean, I'm not exactly a fan of Linux, but you can't call it obsolete by any measurement. – T. Sar Jan 23 '20 at 17:55
  • @ChrisDown, ah, I see, you were using "file" in the sense of the FS entry, not the *contents* of the file (i.e. yes, the inode). My bad. – Matthew Jan 23 '20 at 18:02