throgh wrote:Well, Hyperbola won't install any kind of mirocode. That is especially the point about rejecting firmware-blobs. To make that part clear: We will never include binary blobs into the Hyperbola-system being not open before compilation.
For GNU/Linux-libre there are therefore only that mitigations available we have done. HyperbolaBSD will get even more attention possible!
I'm not asking for binary blobs to be included in the kernel, not at all. I don't have the knowledge about what intel microcode even is. Are we sure that those are blobs? Or are they just patches?
Forgive me,, for I have been working a lot and am tired but I wanted to get this out
From the responses so far I think we need to re-look at what mitigations are available. The mainline Linux kernel has made mitigations but some options apparently have to be turned on in the compile process. So, it would just be a matter setting the defaults for the Linux-libre kernel at compile time to cover these vulnerabilities. The issue I see on my computer is that some but not all have been 'patched' or configured with the safe defaults.
With that being the case, the safe defaults are in line with Hyperbola policy
Unless I totally misunderstood, tho. But I do gather that microcode is but only one of the mitigations, the other is changes to the kernel itself. It must be stressed that Spectre affects even ARM and MIPS cpus, and I am left with the impression that this affects all kernels
Information can be found here and some astute kernel person can make the appropriate decisions:
https://docs.kernel.org/admin-guide/hw-vuln/
https://docs.kernel.org/admin-guide/hw- … ectre.html
https://wiki.archlinux.org/title/Microcode
https://wiki.archlinux.org/title/Security#CPU
Excited for HyperbolaBSD-libre btw