Originally posted by Adarion
View Post
Announcement
Collapse
No announcement yet.
Ubuntu 15.04 Will Attempt To Better Update CPU Microcodes
Collapse
X
-
-
Originally posted by Azrael5 View PostThanks for the answer. A last question: code updating affects bios or operating system? Is there a way to update bios bios code by hardware peripherals code so to avoid pci unknown device issue during POST, though ACPI and APIC demands to operating system device management in modern systems?
cpu microcode does not affect anything but the cpu
not that you will notice anything different after it is "updated"
how it works is that the kernel module "microcode.ko" checks /lib/firmware/ for microcode, then uploads it to the cpu
for updating bios i think i used flashrom once
the recommended way from the motherboard vendor might be a smarter plan
(like mine has a way to flash by putting a file on a stick then choosing to update in bios)
Comment
-
Originally posted by Espionage724 View PostAre microcode updates temporary or permanent? Or I guess a better question; do they just affect the running session, or does it persist after reboots?
I heard a while back that Intel was distributing microcode updates to prevent overclocking on certain processors that some motherboard vendors unlocked; not sure how true that is, but as to how concerning it might be might depend on the above.
Comment
-
-
Originally posted by gens View Postcrisb explained it better
cpu microcode does not affect anything but the cpu
not that you will notice anything different after it is "updated"
how it works is that the kernel module "microcode.ko" checks /lib/firmware/ for microcode, then uploads it to the cpu
for updating bios i think i used flashrom once
the recommended way from the motherboard vendor might be a smarter plan
(like mine has a way to flash by putting a file on a stick then choosing to update in bios)
Comment
-
Package cryptokey more reliable than CPU/firmware key for security
Originally posted by Adarion View PostI thought that was a matter of the kernel. But then I am gentoo and compile my own kernels and put everything right in. I have few modules and never had an initrd (what is that good for anyway ). And I mean, what means "better microcode updates"? You can probably ship the latest blob and maybe somehow improve loading at kernel boot time but the microcode itself is a blob provided by the CPU vendor so you can't really change much about it. And a lot of CPUs/APUs today even want this one crpytographically signed, for mixed reasons. :/
The CPU firmware signing key is not to be trusted against the NSA. It's possible that Intel will refuse to provide it in the post-Snowden era for business reasons, just as Google claims to be encrypting data against the NSA while selling it to everyone else. It's also possible that the wealthy corporate bosses at Intel (like at Shell, etc) see the NSA as part of the military and the military as their own security force. Even if they have clammed up for a while, that will only last until the next terrorist strike anywhere in the world where encryption can be plausably blamed for assisting the attackers.
By comparison, if Canonical got caught givng GCHQ signing keys for Ubuntu packages, that would be the end of Ubuntu and everyone knows it. Even Red Hat could not afford this kind of fallout, while Microsoft's rather different end user base tolerated the Windows 2000 NSA key revelation with barely a whisper. When it REALLY counts (Snowden, etc) and performance is acceptable with the firmware that came on the CPU's ROM, it makes sense to use the firmware that came on the CPU assuming that was sourced randomly with cash. Below the Snowden level, everyone should refuse to install unsigned firmware packages if their distro normally signs packages.
As for that CPU firmware: we know damned well that Intel is not to be trusted with something like Boot Guard, even though for a lot of us the true "turtles all the way down" level of security would be a chip fabbed ourselves from an open source design on a some kind of descendant of 3-d printers, only accepting firmware signed with our own keys and locked to our own bootloaders or kernels. The problem then becomes the printer that fabs the CPU...
Comment
-
Originally posted by Luke View PostAs for that CPU firmware: we know damned well that Intel is not to be trusted with something like Boot Guard, even though for a lot of us the true "turtles all the way down" level of security would be a chip fabbed ourselves from an open source design on a some kind of descendant of 3-d printers, only accepting firmware signed with our own keys and locked to our own bootloaders or kernels. The problem then becomes the printer that fabs the CPU...
Comment
-
Originally posted by Adarion View PostThe con side is: No freedom firmware, no own firmware, you have to live with what the CPU manufacturer provides you. You also do not have control over this. That means: Firmware/Microcode runs at lowest level, can achieve SMM (!) and this way phone home totally transparent to you, your OS and your anti-malware solution. It is like somebody stops time and exchanges the chair you sit on (under your ass! ) and puts a new chair there. And you will not notice it. Also this firmware can limit the functions of your CPU. Nvidia and intel are actually doing this or at least planning to do so. Intel wanted to sell CPUs and you had to pay extra to "release" certain functions or better speed. Nvidia might pretend the GPU to be a newer model but it is just an ooold chip rebranded. Or limit GPU functions. (The 3.5 GB desaster was hardware, though )
Probabling hoping in further development and for personal use availability of the Loongson CPUs is just utopia
Comment
Comment