Expect churn for users in regard to AVX removal due to downfall

[Christian Ehrhardt ]

As far as I can overlook the currently proposed solutions related to downfall [1] there seem to be those cases:
1. chip has AVX but is not affected for some reason/condition
2. chip has AVX, is affected but fixed by microcode
3. chip has AVX, is affected but NOT fixed by microcode

Out of those #2 and #3 can very much be identical hardware.

Kernel patches that have been flying by seem to detect for the unsafe condition #3 of above and disable AVX in that case.

This will (we will know for sure in a few weeks) lead to the same troubles like bug 1853200 did when TSX needed to be disabled in a similar situation.
Expect cpu type detection breaking or changing what it detects on that HW.
And expect trouble not able to migrate to what "seems to be" same hardware as #1 and #2 would not be able to migrate to #3.

Once we see these kernel changes really land we need to check asap (until then this is mostly blocked) test various systems how they behave and coordinate with qemu/libvirt upstreams .

[1]: https://downfall.page/

[Christian Ehrhardt  (paelzer)]

@SMB
Once there is an easy (tm) way to access a kernel with that change we can have a look at an older system that should be affected how it changes between old/new kernels.

If you have an idea what kernel parmline can force-overwrite it we'd appreciate to know.
And maybe a link to an example recent version of the patch set?

Thanks in advance!

[Stefan Bader (smb)]

Full Description:
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/lunar/tree/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst?id=0b1773963f11c7e9ea4fa0d0ed55dd3581cfe635

The latest kernels will _NOT_ forcefully disable AVX in case of a vulnerable CPU without microcode update being available. To test this future scenario one has to pass "gather_data_sampling=force" on the kernel command-line. Those kernels are currently building[1] for Lunar, Jammy, and Focal. Once finished they can be installed by enabling: "apt-add-repository ppa:canonical-kernel-team/proposed".

[1] https://kernel.ubuntu.com/sru/dashboards/web/kernel-stable-board.html?cycle=2023.08.07

[Christian Ehrhardt  (paelzer)]

Thanks Stefan,
if the default is now this way around it is not so great for security but much better for impact to systems on kernel upgrade.

Since it will now be a conscious/manual "I do not want/can to microcode upgrade, but want the features despite being unsafe" we can expect that people doing so also are ok to manually adapt e.g. guest definitions.

The more concerning problem would have been default-on which have led to the problems I outlined.

Marking this a low prio "worth to check how it looks" task (just to be sure) ...

[Launchpad Janitor (janitor)]

[Expired for qemu (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for libvirt (Ubuntu) because there has been no activity for 60 days.]