Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities
On 01/08/2018 05:44 PM, Bruce Dubbs wrote: DJ Lucas wrote: I might be confused, but I thought microcode updates on consumer processors is handled by BIOS update from the motherboard manufacturer, the AGESA part of the BIOS version, currently 1.0.0.7. I'm not sure if we'll see a late-load .bin for the consumer processors. If anybody can confirm or deny, please speak up. BLFS shows how to update the microcode in an initrd. That's really just having the kernel do what the BIOS update would do. Bruce, the AGESA comment is specific to AMD R5/R7 processors. They obviously intend to provide the files for at least Epyc. Nothing has surfaced yet for Ryzen or Threadripper outside of the BIOS updates. --DJ -- 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
Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities
On 01/08/2018 03:12 PM, Michael Shell wrote: On Sun, 7 Jan 2018 16:47:00 -0600 DJ Lucas wrote: I might be confused, but I thought microcode updates on consumer processors is handled by BIOS update from the motherboard manufacturer, the AGESA part of the BIOS version, currently 1.0.0.7. I'm not sure if we'll see a late-load .bin for the consumer processors. DJ, Given that a microcode update would apply to all processors of a given type and given this is a security related matter, the chances are very good that *somebody* will extract and "leak" the microcode files to the public even if Intel/AMD does not (officially) do so > IMHO, tis kind of silly of Intel/AMD to expect microcode updates to come only by way of BIOS updates given how reluctantly motherboard makers issue BIOS updates. Agreed, however, it seems to be the case. AGESA (AMD Generic Encapsulated Software Architecture) is the working name. I suppose you can do so without a BIOS update, but somebody will have to either extract it, or break NDA (probably equally frowned upon in many jurisdictions). --DJ -- 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
Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities
DJ Lucas wrote: I might be confused, but I thought microcode updates on consumer processors is handled by BIOS update from the motherboard manufacturer, the AGESA part of the BIOS version, currently 1.0.0.7. I'm not sure if we'll see a late-load .bin for the consumer processors. If anybody can confirm or deny, please speak up. BLFS shows how to update the microcode in an initrd. That's really just having the kernel do what the BIOS update would do. On my latest build (yesterday), I have: menuentry 'LFS SVN-20180106 kernel 4.14.12' { linux /vmlinuz-4.14.12-lfs-SVN-20180106 root=/dev/sda9 ro initrd /microcode-06-5e-03.img } -- 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
Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities
On Sun, 7 Jan 2018 16:47:00 -0600 DJ Lucas wrote: > I might be confused, but I thought microcode updates on consumer > processors is handled by BIOS update from the motherboard manufacturer, > the AGESA part of the BIOS version, currently 1.0.0.7. I'm not sure if > we'll see a late-load .bin for the consumer processors. DJ, Given that a microcode update would apply to all processors of a given type and given this is a security related matter, the chances are very good that *somebody* will extract and "leak" the microcode files to the public even if Intel/AMD does not (officially) do so. IMHO, tis kind of silly of Intel/AMD to expect microcode updates to come only by way of BIOS updates given how reluctantly motherboard makers issue BIOS updates. 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
Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities
On Sun, Jan 07, 2018 at 04:47:00PM -0600, DJ Lucas wrote: > > > I might be confused, but I thought microcode updates on consumer processors > is handled by BIOS update from the motherboard manufacturer, the AGESA part > of the BIOS version, currently 1.0.0.7. I'm not sure if we'll see a > late-load .bin for the consumer processors. If anybody can confirm or deny, > please speak up. > In theory you can get a new BIOS/UEFI from the motherboard manufacturer. But linux has supported updating the microcode for a long time (but you need to do it on every boot). All my Intel motherboards now load newer firmware than what is in the BIOS, but of my AMDs only the oldest (Athlon64x2) has newer firmware available from linux-firmware. BLFS, Part II, Chapter 3, 'About Firmware'. ĸen -- Truth, in front of her huge walk-in wardrobe, selected black leather boots with stiletto heels for such a barefaced truth. - Unseen Academicals -- 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
Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities
On 01/07/2018 04:11 PM, Ken Moffat wrote: On Fri, Jan 05, 2018 at 08:43:11PM -0500, Michael Shell wrote: On Fri, 5 Jan 2018 17:26:13 + Ken Moffat 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. If anybody has an EPYC[1], SuSe has a srpm - but it doesn't apply to Ryzens, and the kerneli might need a patch because it had known nothing about Ryzen microcode and tests against an old default size (not sure which versions have that patch) - details at https://bugs.archlinux.org/task/56951 Yes, I had seen this as well, but this is specific to Epyc. Clearly this is aimed at Spectre. I saw the kernel patch a while ago, which is why I was hopeful about microcode. But I don't even have a Ryzen so for me that part is academic. 1. The server version of Zen, aimed at Data Centres, so I can understand why that would get priority. I might be confused, but I thought microcode updates on consumer processors is handled by BIOS update from the motherboard manufacturer, the AGESA part of the BIOS version, currently 1.0.0.7. I'm not sure if we'll see a late-load .bin for the consumer processors. If anybody can confirm or deny, please speak up. --DJ -- 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
Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities
On Fri, Jan 05, 2018 at 08:43:11PM -0500, Michael Shell wrote: > On Fri, 5 Jan 2018 17:26:13 + > Ken Moffat 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. > If anybody has an EPYC[1], SuSe has a srpm - but it doesn't apply to Ryzens, and the kerneli might need a patch because it had known nothing about Ryzen microcode and tests against an old default size (not sure which versions have that patch) - details at https://bugs.archlinux.org/task/56951 Clearly this is aimed at Spectre. I saw the kernel patch a while ago, which is why I was hopeful about microcode. But I don't even have a Ryzen so for me that part is academic. 1. The server version of Zen, aimed at Data Centres, so I can understand why that would get priority. ĸen -- Truth, in front of her huge walk-in wardrobe, selected black leather boots with stiletto heels for such a barefaced truth. - Unseen Academicals -- 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
Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities
On Fri, 5 Jan 2018 17:26:13 + Ken Moffat 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). 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. 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. 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
Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities
On Fri, Jan 05, 2018 at 02:58:57AM -0500, Michael Shell wrote: > > Most interesting, but also scary. Here's my own summary take on the info > which I found at: > [ snipping - people can, and should, follow the links in your original post, but I've got a question on one item ] > > There is, however, conflicting information when it comes to the AMD > (Zen/Ryzen) CPUs and variant 2: > https://www.realworldtech.com/forum/?threadid=173741&curpostid=173810 > > Suse and Red Hat have released a firmware/microcode update for the AMD 17h > family (Zen). This new firmware claims to > > " This new firmware disables branch prediction on AMD family 17h processor. > 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. >Also the CPU microcode for Intel Haswell-X, Skylake-X and Broadwell-X >chipsets was updated to report both branch prediction control via CPUID >flag and ability to control branch prediction via an MSR register. > " Ah, the high-end -X CPUs. I'm still hopeful of seeing new intel firmware, but the last comment I read on lkml last night was that it had not been released yet. I looked at RedHat updates, they are still using microcode_ctl and the date of that was not recent. ĸen -- Truth, in front of her huge walk-in wardrobe, selected black leather boots with stiletto heels for such a barefaced truth. - Unseen Academicals -- 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
Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities
On Thu, 4 Jan 2018 20:16:18 + Ken Moffat wrote: > There are two vulnerabilities, with the shiny names of Meltdown and > Spectre. Both refer to ways of userspace finding where the kernel > has been mapped, to try to do harm. Page Table Isolation addresses > the first of these. Google claim it affects some AMD processors, > AMD deny this. Most interesting, but also scary. Here's my own summary take on the info which I found at: http://www.tomshardware.com/news/meltdown-spectre-exploits-intel-amd-arm-nvidia,36219.html https://wccftech.com/intel-affected-by-critical-kernel-bug-amd-hit/ https://overclock3d.net/news/cpu_mainboard/amd_releases_response_to_meltdown_and_spectre_exploits/ https://www.phoronix.com/scan.php?page=news_item&px=Linux-Tip-Git-Disable-x86-PTI https://www.theregister.co.uk/2018/01/04/intel_amd_arm_cpu_vulnerability/ There are three variants of this new class of vulnerability which all involve gaining illegal read access to memory: Variant 1: Bounds check bypass, aka "Spectre (Version 1)", CVE-2017-5753, Supposedly, is to be fixed within the kernel. It is promised to be an easy and painless fix. Almost all modern processors are affected. Variant 2: Branch target injection, aka "Spectre (Version 2)", CVE-2017-5715 May require a CPU microcode update or recompiling all the applications to fix. More mystery and conflicting info over this one than the other variants. AMD claims vulnerability is "almost zero". The Zen family may be an exception (see below). Variant 3: Rogue data cache load aka "Meltdown", CVE-2017-5754 The new Linux kernel Page Table Isolation (PTI) feature protects against this exploit. All post-1995, except Itanium and pre-2013 Atom, Intel CPUs and Arm Cortex-A15, Cortex-A57, Cortex-A72 and Cortex-A75 cores are vulnerable. No AMD CPUs are vulnerable to variant 3. From https://wccftech.com/intel-affected-by-critical-kernel-bug-amd-hit/ "Variant 1 is software [OS] patchable and affects almost all modern processors. The patch itself will have negligible performance hit. Variant 2 and 3 are rooted further in hardware and are not patchable by any known means of code. Attempting to patch these using software will result in performance hits and so far these only seem to affect Intel and ARM processors with near zero risk to AMD CPUs." However, the above quote is a little misleading because the Linux kernel Page Table Isolation (PTI) feature should be able to prevent Variant 3, albeit with a load dependent performance penalty. Tis real bad news for folks using Intel because Intel's processors are impacted much more severely than those of AMD. In particular, "it is said that Meltdown (Variant 3) has been tested on all Intel processor generations since 2011, with 'effectively every processor since 1995' being affected (with a few exceptions)". AMD claims its processors are not vulnerable to Variant 3 (and the upcoming Linux kernel releases will disable the PTI protection config option by default for AMD processors), and that they have "near zero" risk from variant 2 (but see below for evidence that Ryzen CPUs might have an issue with variant 2). Variant 1 affects almost all modern processors, including those of AMD, and may require future hardware architecture changes to totally mitigate without the need for OS patches/protection. However, AMD now claims it has developed a patch (kernel or microcode level?) that "can mitigate variant 1 with minimal performance impact." From https://wccftech.com/intel-affected-by-critical-kernel-bug-amd-hit/ there were four proof of concept exploits that have been demonstrated: "During the course of our research, we developed the following proofs of concept (PoCs): 1. A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries. 2. A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. 3. A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed t