I take the unusual approach, of hosting my Web-site, and this blog, on my personal computer at home. This implies that the visibility of this blog on the Web, is only as good the reliability of my PC, which I name ‘Phoenix’. Along with the computer I name ‘Plato’, Phoenix received a kernel-update today, which required a reboot.
The kernel-update took place uneventfully.
But, my site and blog would not have remained visible, from 20h20 until about 20h30 this evening.
I apologize for any inconvenience to my readers.
(Update 05/02/2018 … )
Contrarily to first appearances, this kernel-update did seem to have a side-effect: On one of my computers, it prevented the VirtualBox kernel-modules from being built…
On the computer I name ‘Plato’, like on all my computers, I have a version of ‘VirtualBox’ installed, which is a type of virtual machine, that happens to be easy-to-use, through its GUI. In order to possess all its capabilities, it needs to have a set of kernel-modules loaded, the presence of which can be tested, by typing in the following (as user, if the reader wishes):
lsmod | grep vbox
Several lines of output should indicate, that VirtualBox is ready-to-go.
‘Plato’ is a Debian / Stretch, Debian 9 system for which the kernel-update was an in-place update, to kernel version ‘4.9.0-6-amd64′ . This is actually contrary to how kernel-updates are usually carried out, which would have been, to cause a meta-package to depend on a new kernel-version, such as maybe ‘
In any case, any sort of kernel-update usually also causes certain out-of-tree kernel-modules to be rebuilt, with the only problem on ‘Plato’ being, that this DKMS kernel-module, for ‘virtualbox-5.0′, could no longer be built.
This did not have any strong effect on me, because in my user-space, I had not created any virtual machine-instances. But I’m guessing that such a situation could prove difficult for any other users, who rely on virtual machines. In my case, the problem was solved by first removing and purging ‘virtualbox-5.0′ (from the root partition), and then, just installing ‘virtualbox-5.2′. After that, the kernel modules were also loaded again.
This blog, as I wrote, is hosted on the computer I name ‘Phoenix’, not ‘Plato’, and on ‘Phoenix’, which is a Debian / Jessie, Debian 8 system, the out-of-tree kernel-modules rebuilt fine, without requiring any action from me. Therefore, none of this is affecting my actual server-box.
But, because ‘Phoenix’ is running older hardware, at boot-time I now get the message:
‘Spectre v2: LFENCE Not Serializing. Switching to retpoline’
Or some such message. This message actually reveals, what the goal of this kernel-update was on both machines:
It’s to harden resistance to Spectre. LFENCE seems to be a machine-language instruction for AMD chip-sets, that forces the CPU-core to wait, until all commands to load data from RAM have finished doing so, before the CPU will move on to the next machine-language instruction. Effectively, it blocks speculative execution, in specific parts of the program. Well, before using this instruction, the kernel checks whether the instruction actually does anything. On older Athlon CPUs, the instruction has no effect, and the kernel switches to using ‘some other form of protection’.
Because ‘Phoenix’ booted fine, I’d say that ‘retpoline’ works fine on this box. But there seem to be other users, for whom this kernel feature prevents booting!
I guess I was lucky myself.