| david95 | Hello everyone. Please recommend VPS on which to install Devuan. Thanks in advance for your recommendations. | 20:39 |
|---|---|---|
| Xenguy | david95, Someone mentioned vultr.com | 20:51 |
| Xenguy | Some time ago | 20:51 |
| Xenguy | "I'm using vultr.com, also custom ISO" | 20:52 |
| systemdlete | So I am getting an error from apt-listchanges (after an update) saying I am running with an old firmware version, namely 0x00000000. IOW, it doesn't seem to get the real version. | 21:01 |
| david95 | Thank you very much for the recommendation, $5 is not a bad price for 1 vCPU, 1GB, 1.00 TB, 25 GB. If I understood you correctly, by default it is Debian and I need to install Devuan myself after purchase? | 21:02 |
| systemdlete | This ONLY happens on chimaera systems, afaict. Daedalus works without this error. | 21:02 |
| systemdlete | I've browsed around the Interwebs but have not found a reliable AND simple way to get the firmware version. | 21:03 |
| systemdlete | Anyone know the magic fu for this? | 21:03 |
| systemdlete | and this happens inside of VMs; I haven't seen this on my one chimaera host. | 21:04 |
| systemdlete | I'm not really sure if I even need firmware inside a VM in the first place, but Uncle Duck's "wisdom" (AI bot) tells me that spectre and the other malware can happen to a VM. But I have never been clear about this. | 21:05 |
| systemdlete | Thank you for any knowledge you can impart to me about this. | 21:05 |
| plasma41 | systemdlete: What firmware is this? | 21:07 |
| systemdlete | When apt-listchanges runs, it tells you if processes are running that are linked to now-outdated libraries, if sessions need to be restarted, etc, as well as if the running system is still using now-outdated firmware. | 21:10 |
| systemdlete | But even after a reboot, any apt upgrades will call apt-listchanges and give this (false?) warning. | 21:11 |
| systemdlete | I've looked at dmidecode, but it doesn't show the firmware version | 21:12 |
| systemdlete | This whole issue is very minor, I admit, but it would be NICE if it actually worked correctly... | 21:13 |
| systemdlete | False warnings are not very helpful, IMO | 21:13 |
| fsmithred | dpkg -l | grep firmware | 21:14 |
| systemdlete | fsmithred, that only tells which version is installed, not which version is running. | 21:15 |
| fsmithred | I would expect that you're running the version that's installed | 21:15 |
| systemdlete | The system has to be rebooted for changes to take effect | 21:15 |
| fsmithred | apt policy firmware-whatever | 21:15 |
| systemdlete | same thing for apt policy | 21:15 |
| fsmithred | can't modprobe it? | 21:15 |
| systemdlete | hmmm | 21:15 |
| systemdlete | not sure | 21:16 |
| systemdlete | interesting idea, and maybe would work! | 21:16 |
| plasma41 | I get that apt-listchanges indicates the firmware version is outdated, but what is the name of the firmware it reports is outdated? | 21:17 |
| systemdlete | plasma41, maybe amd64-microcode? | 21:18 |
| systemdlete | fsmithred, any idea which module name? | 21:18 |
| * systemdlete notices lscpu in one search output... | 21:20 | |
| plasma41 | systemdlete: Just spitballing here, but maybe your initramfs didn't get rebuilt after a cpu microcode update and an old initramfs is still loading an older microcode version during boot? | 21:23 |
| systemdlete | lshw does list the firmware version. So it is possible I can use that... but still not sure | 21:24 |
| systemdlete | plasma41, possibly. But I am not doing anything special with regard to update-initramfs | 21:25 |
| systemdlete | This same behavior seems to be consistent across chimaera systems and not daedalus systems from what I know so far. But I haven't tested every last chimaera system yet. | 21:25 |
| plasma41 | I'd need output via pastebin to make a more educated guess. | 21:26 |
| systemdlete | ok, give me a moment... | 21:27 |
| systemdlete | I may have mis-spoken. Maybe it is not apt-listchanges that spits out these messages, but I'm not sure. | 21:35 |
| systemdlete | The message I see as an upgrade is finishing is: "The currently running processor microcode revision is 0x00000000 which is not the expected microcode revision 0x06000852." | 21:36 |
| systemdlete | So, whatever program is generating that... | 21:36 |
| * systemdlete apologizes for ignorance, stuff they really ought to know | 21:38 | |
| plasma41 | systemdlete: Based on a quick code search http://codesearch.debian.net/search?q=which+is+not+the+expected+microcode+revision&literal=1 that message comes from the 'needrestart' package https://tracker.debian.org/pkg/needrestart | 21:39 |
| systemdlete | oh, duh! of course. That's what I meant. Sorry, I was up late last night battling with this... | 21:40 |
| systemdlete | yes, it is needrestart, not apt-listchanges. | 21:40 |
| systemdlete | Not sure what I was thinking. Still on first cup. Maybe I should have some caffeinatied instead. | 21:40 |
| plasma41 | That would definitely make more sense, yes. | 21:40 |
| systemdlete | So sorry, plasma41. | 21:40 |
| plasma41 | systemdlete: No worries. | 21:41 |
| systemdlete | needrestart -b or -p both show the firmware version as 0x00000000 or similar | 21:43 |
| systemdlete | also, needrestart always spits out a message that the uCode field of the structure it is using is uninitialized | 21:45 |
| systemdlete | (and,yes, I know that should be a clue here) | 21:45 |
| plasma41 | systemdlete: Like this?: https://bugs.debian.org/973050 | 21:46 |
| systemdlete | That message has been showing for about a year or so now. But now I am ALSO getting this warning about out-of-date microcode | 21:46 |
| systemdlete | Yeah, that one. | 21:46 |
| systemdlete | In my case, though, where it shows that "The processor microcode seems to be up-to-date." instead I get the "The currently running processor microcode revision is 0x00000000 which is not the expected microcode revision 0x06000852." message | 21:47 |
| plasma41 | systemdlete: https://bugs.debian.org/896926 sounds like it's relevant as well. | 21:48 |
| plasma41 | systemdlete: If you can provide additional context to those issues, please do. | 21:51 |
| systemdlete | one thing I am noticing is that most of the hits I get from various searches point to examples involving intel, not amd64. | 21:51 |
| systemdlete | Sure, if I can just figure out where to start... | 21:51 |
| systemdlete | plasma41, to start with, is it best to install microcode in a VM? Am I vulnerable to spectre and its malware friends inside a VM? I mean, this is a home system, but still... | 21:53 |
| systemdlete | best practices, etc. | 21:53 |
| systemdlete | interesting. On daedalus, needrestart skips microcode checks inside a vm! | 21:57 |
| plasma41 | I would assume that if the host system installed updated microcode during boot, the guest VM wouldn't need to do anything extra. If the host system didn't install updated microcode during boot, the guest VM wouldn't be able to update the microcode as that would require crossing a privilege barrier. At least that's what intuitively makes sense to me. | 21:58 |
| systemdlete | I think I agree. I have always just assumed that. | 22:01 |
| systemdlete | So I might be vulnerable to spectre attacks in a VM, and thus maybe Uncle Duck was not a complete Quack. | 22:03 |
| systemdlete | But Duck wasn't completely clear w/r/t whether microcode is proliferated to VMs from the host... | 22:04 |
| fsmithred | doesn't your vm run its own kernel? | 22:04 |
| systemdlete | fsmithred, of course it does | 22:05 |
| plasma41 | AIUI, If you are vulnerable to spectre attacks outside a VM, you are vulnerable to them inside a VM. | 22:05 |
| systemdlete | so the firmware update is not applied to the CPU? | 22:05 |
| systemdlete | plasma41, all of my hosts have the firmware updates | 22:06 |
| systemdlete | the question is whether the VMs get protected by the host having the updates | 22:06 |
| fsmithred | probably depends on the exploit | 22:07 |
| plasma41 | systemdlete: Unless I'm fundamentally misunderstanding something, yes, VMs get protected by the host having the updates. | 22:07 |
| systemdlete | plasma41, that would, indeed, seem to follow. | 22:07 |
| systemdlete | This sounds like a kernel developer question, doesn't it? | 22:08 |
| systemdlete | Definitive clarity would be comforting. | 22:09 |
| systemdlete | time for second cup, caffeinated this time | 22:11 |
| plasma41 | Unless your virtual machine goes to the immense effort of simulating speculative execution on an emulated CPU for high hardware accuracy and a massive performance penalty, I think you're fine. | 22:12 |
| plasma41 | systemdlete: https://github.com/liske/needrestart/issues/323 also sounds similar to what you're seeing. | 22:18 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!