On Fri, 5 Jan 2018 17:26:13 +0000 Ken Moffat <zarniwh...@ntlworld.com> wrote:
> Does anybody have a link for (any) updated AMD firmware? Ryzen is > model 17h, AFAICS linux firmware has nothing for that, and the > firmware for earlier models has not been updated in a long time. I also sure would like a link to that if anyone here knows it. That said, the Debian page for the AMD microcode is here: https://packages.debian.org/sid/amd64-microcode There is also a place on github where Linux related firmware is distributed from. The AMD CPU microcode area of that is here: https://github.com/wkennington/linux-firmware/tree/master/amd-ucode But no updates since 2016 so far. Sigh. The Intel area (in the github link) does not seem to carry anything for CPUs. Intel's own distribution page for CPU microcode is here (tis the same link Ken gave earlier): https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File "This microcode data file contains the latest microcode definitions for all Intel processors." But, as Ken mentioned, it seems that the Debian page has versions more recent than Intel has officially released. Sigh. > Like you, I'm very wary of bios updates (I've bricked enough > hardware over the years). <going OT for a minute> As long as it is for the correct motherboard, it should work. I've upgraded motherboard BIOSes many times and doing so has allowed me to overcome lots of annoyances. Just be sure and record any critical settings before the update. Be prepared to have to reset your CMOS settings (or even have them automatically reset by the update process itself) and then reenter all your settings. One other thing, I never use the "network BIOS update" feature found on many modern motherboards. I always download the BIOS file manually and update from that. Always be sure and get the correct one. The bigger problem in my eyes is motherboard OEMs not creating/releasing BIOS updates, especially for older hardware. Now, when they are motivated enough to do so, it usually means something serious was fixed. I've also become a fan of the linux flash utility flashrom: https://www.flashrom.org/Flashrom Although I have not yet used it to update a motherboard BIOS, it worked great to update the BIOS on a SATA card. And it allows us to *save* a copy of the flash rom contents before we overwrite it with an update. Also, it's good to know that there are sellers on Ebay who are selling BIOS chips in the $15 range. Do a search for BIOS chip yourmotherboard model to see what's available. Some of these chips are plugin DIPs, but others are SMT devices that will require the use of soldering skills to replace. However, it's a venue that will allow you (or your local electronics technician) an emergency means to unbrick. <rant> IMHO, every firmware update-able device should carry two copies of its firmware - one that is always read only and is forever fixed at the factory and the other copy which can be updated by the user. This way, if an update fails, a switch/jumper can be set to fallback to the OEM firmware to allow booting so the second (writable) copy can be reflashed. Also, there should be a second jumper that would force the second (writable) copy to be read only as well. In this way, malware could be kept out of firmware - all firmware updates locked out in hardware. </rant> </going OT a minute> In anycase, from what I understand at present, the Meltdown/Spectre class of bugs don't allow for things like arbitary code execution - they just leak information. The spillage of the entire kernel memory area is most troubling. But, even so, it should be tough for an attacker without shell access to use that to gain root access. I think the biggest concern here is for (shared) hosting companies and companies with public servers that are handling sensitive information, not the normal desktop. Lastly, IMHO, no application facing the outside world should ever allow users to be able to craft and execute code at level low enough to permit such exploits. I think such an ability is a security-related bug in and of itself. Cheers, Mike -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
