Hello. I just wanto to confirm: everything seems to be okay after updating Linux kernel to v4.4.0-123-generic. However, I would like to ask a question about 'intel-microcode' and 'amd64-microcode' packages. During system updating process via apt(8), there was an information that "The following NEW packages will be installed" etc. and it was about two mentioned 'microcode' packages.
I did not have these packages installed, until then. It's an Intel processor, but it seems, that Intel Corporation will not publish any microcode updates for some processor. Intel reveals (on Apr. 3., 2018) list of processors that won't receive Meltdown and Spectre patches. It seems, that some of older processors won't receive microcode updates designed to mitigate the vulnerabilities: Bloomfield, Bloomfield Xeon, Clarksfield, Gulftown etc. So, I would like to ask if it was normal, that apt(8) installed such a packages? And why both since it's an Intel processor? Can I remove both packages (since there is no changes related to the microcode and "Spectre & Meltdown" mitigation; just 'revision' change in '/proc/cpuinfo' virtual file or/and dmesg(1) etc.)? In sum two questions: ✗ why apt(8) installed two 'microcode' packages during Linux kernel v4.4.0-123-generic updates? ✗ can 'intel/amd64-microcode' packages be removed (since there is no difference with "Spectre & Meltdown" mitigations)? I apologize for asking such a questions here, but this bug is about 'ibrs/ibpb' (a method to "Spectre & Meltdown" mitigation etc.) and Linux kernel update (v4.4.0-123-generic) during which, two 'microcode' packages were installed. Thanks, best regards. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1755627 Title: ibrs/ibpb fixes result in excessive kernel logging Status in linux package in Ubuntu: Fix Committed Status in linux source package in Trusty: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Artful: Fix Committed Bug description: Since at least kernel 4.4.0-116, every invocation of `sysctl -a` results in kernel logs similar to the following: % sysctl -a &>/dev/null; dmesg -T | tail -8 [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0 [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4 [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0 [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0 [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0 [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4 [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0 [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0 The output varies with the number of CPUs. After digging a bit, it turns out this is triggered upon every read of `kernel.ibrs_dump`: % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; sleep 1; done kernel.ibrs_dump = 0 [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0 [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4 [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0 [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0 [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0 [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4 [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0 [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0 kernel.ibrs_dump = 0 [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0 [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4 [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0 [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0 [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0 [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4 [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0 [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0 kernel.ibrs_dump = 0 [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0 [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4 [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0 [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0 [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0 [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4 [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0 [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0 Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 4.4.98 per /proc/version_signature Normally this would not be the biggest concern but we have tooling that gathers instance info on a schedule, including sysctl output, thus resulting in the kernel ring buffer being full of nothing but said output in most cases and hindering live troubleshooting as a result. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
