I installed Ksplice and its Uptrack Manager on my 32-bit and 64-bit F13 laptops about a month ago during the last big kernel vulnerability flap. My objective was to become more familiar with Ksplice before investing in it for several RHEL servers. Yesterday the Ksplice icon in the upper toolbar indicated new updates were available. Specifically, there was a patch for CVE-2010-3432 "Remote denial of service vulnerability in SCTP" plus one other involving garbage data on the kernel stack when handling signals (no CVE). Before running Ksplice Uptrack Manager I ran 'uname' to check the running kernel version: $ uname -a Linux localhost@localdomain 2.6.34.7-56.fc13.i686.PAE #1 SMP Wed Sep 15 03:27:15 UTC 2010 i686 i686 i386 GNU/Linux This did not change after running KUM. The contents of /etc/grub.conf were also unchanged. It appears that Ksplice had updated only the code running in RAM. To test this hypothesis, I rebooted the laptop. After reboot, the Ksplice icon was in its normal state. When clicked it reported the two installed updates, but neither /etc/grub.conf nor the output of uname had changed. So... Ksplice appears to fulfill its promise to keep a system updated, but it does so dynamically in a way that will require changes in most configuration management auditing processes. Tools that check the RPM database won't work because neither rpm nor yum are used to apply Ksplice updates. The output of uname won't change until I apply standard update patches and reboot into a new kernel. I must still run 'yum update' to apply kernel and other patches that required rebooting before Ksplice. With Ksplice I don't actually have to reboot after running 'yum update' because its dynamic patching mechanism alters the running kernel on-the-fly, but my auditing and configuration management tools can't correctly determine the system state. Before those can work again I must still schedule downtime for a reboot. The bottom line appears to be that Ksplice can dynamically patch a system and allow uninterrupted operation indefinitely. It does so in a way that invalidates auditing tools that are not Ksplice-aware. --Doc Savage Fairview Heights, IL -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
