| From: Russell via talk <talk@gtalug.org> | On January 8, 2018 10:33:00 AM EST, "Steve Petrie, P.Eng. via talk" <talk@gtalug.org> wrote: | >Intel 4-Core i5-4460 3.2GHz Haswell Processor. (I know, I know, the | >Intel Haswell CPU series is obsolete, but let's just ignore this fact | >for the present discussion.) | | I personally wouldn't say its obsolete until there is a significant lack | of replacement parts or, essential bios functionality requirements for | running the software are unavailable in updates. Haswell machines are fine as anything now but - they use older memory which is already starting to fade from the scene - brand new Haswell chips are not a bargain compared with current chips - firmware updates have already disappeared for many Haswell motherboards (like the one I'm typing on) | Although Spectre and Meltdown may make it look like this is the case, I | am reminded of the immortal words of Thomas Edison who said, paraphrased | - nothing good ever just works, it needs working on. I'm not quite up to speed on the various horrible problems that have come out recently. So take what I say with a grain of salt. - Meltdown is Intel-only. I don't see how it can be fixed on an existing chip -- I don't see microcode updates doing that. OS-level mitigations should work, at the cost of performance. There is a feature of recent Intel CPUs called PCID (Process Context IDentifiers) that might help reduce the performance cost but it isn't yet exploited. PCID is probably in Haswell, but I don't know. - Spectre is a general problem in modern high-performance processors. Luckily, there are probably only a few places that need to be changed to avoid the attack. In general terms, interpreters that are the bulwark against untrusted code need to be hardened. Think: java, javascript, eBPF. - separately, there are horrible security holes in Intel's and AMD's chipsets. These cannot be mitigated by anyone but the manufacturer because the holes are in secret and proprietary features. Any fix must come in the form of either mitigating rituals specified by the manufacturer or in firmware updates. Processor firmware updates installed by Linux cannot do the job completely because these flaws are in code that is active before the OS is loaded. Thus these processor firmware fixes must be embedded in motherboard firmware updates (mistakenly called BIOS updates). So: you want to have a system with a motherboard which will still get firmware updates. This is a really annoying requirement since motherboard firmware updates often cease rather quickly. The main exception is in systems intended for business or server use. For example, in my experience, ThinkPads get firmware updates for many years but other Lenovo laptops get perhaps a year of firmware updates. | My choices were based on the fact that the Z370 was designed with only | forward compatibility in mind and i-7x was a mature 14nm manufacturing | technology. If you are going to the trouble and expense of assembling a system yourself, this seems like the right attitude. | >b.. 2. Invest a week or two to investigate AMD CPU options that will | >avoid altogether the Intel Meltdown bug. This strategy could lead to a | >lengthy necessary respecification of other components in the PC build | >spec, depending on how an AMD architecture fits with peripherals. | >An ARM CPU is not an option, as one of the other operating system I | >plan to run on the new PC is DragonFlyBSD, which only runs on Intel and | >AMD processors (not ARM). | | Waiting won't necessarily hurt, but it won't necessarily change | anything. As consumers, we believe what we are told by experts about | zero day exploits, this is one of those days. | | Certainly this is industry wide and not just within Intel. There are | perhaps a couple of singular exceptions to-date. Yes. The IC processes are so effective that complexity is cheap. It is really hard to make a complex system secure. This affects all processor manufacturers. | Having a predictive | microcode hypervisor has been described as having a RISC backend with a | CISC frontend. I don't think that you are using the word "hypervisor" correctly. I also don't see how "predictive" belongs in this sentence. | This issue could probably be mitigated by switching | entirely to RISC. I don't know what you mean by "this issue". I do think that RISC is simpler and should have fewer cases to get right. But real-world RISC architectures seem to get more complicated at quite a pace. | >And then there is the Spectre bug also lurking ... | | Microsoft has stopped, temporarily, updating AMD due to poor documentation. | | https://www.theverge.com/2018/1/9/16867068/microsoft-meltdown-spectre-security-updates-amd-pcs-issues> Thanks for this reference. I hadn't seen that. Microsoft isn't too clear about their finger-pointing (that doesn't mean that they are wrong). This notice isn't very clear: <https://support.microsoft.com/en-us/help/4073707/windows-os-security-update-block-for-some-amd-based-devices> - it would be really handy if they explained what "some" means. Which AMD-based devices are currently blocked - this run-on sentence might not mean what it is supposed to After investigating, Microsoft has determined that some AMD chipsets do not conform to the documentation previously provided to Microsoft to develop the Windows operating system mitigations to protect against the chipset vulnerabilities known as Spectre and Meltdown. - Spectre and Meltdown are different. The fixes are different. Preventing installation of the fixes for both is probably a mistake. To be honest, I don't understand why these mitigations involve a chipset at all. | As end users we are all beholding to the good faith disclosure of | manufacturing industries. Some early reports say that only a revamp of | CPU design will fully address Spectre. Actually, we probably want speculative execution in a way that makes this leak possible. We just want a simple code sequence that can stop this speculation for some particular references. Then we have to trust the software people to use that sequence where it is needed. | Here's an interesting link to the KASLR report on address space layout | randomization and problematic Intsructional Level Parallelism. | | https://www.google.ca/url?sa=t&source=web&rct=j&url=https://gruss.cc/files/kaiser.pdf&ved=2ahUKEwjOtpWZ-srYAhUE9YMKHT-yDqUQFjAEegQIARAB&usg=AOvVaw0vUvGParJ9_uWXs2iph7KZ That's a very indirect URL. How about <https://gruss.cc/files/kaiser.pdf> | I'd be much more worried if this had been discovered running in the wild | rather than by lab testing and research, but I've been wrong before. Everyone is. But a lot of the bad players try to use these things in ways that won't be detected. | | >Thanks in advance, | | Good luck with your choices. Remember, you have to be compromised in the | first place for these exploits to take hold. Not true. Spectre can be exploited via javascript on a web site (including an ad from who knows where). | In the weeks before this broke and while I was configuring Fedora 27 on | this new HW, I updated based on notices of important changes. | | No new updates since this news broke, so I did a refresh update. That | produced no noticable changes. Mind you that's just ad hoc observations | from the system monitor and not benchmarked results. YMMV There have been several relevant Fedora 27 updates. Some were released just as the first inklings were appearing. In fact, the first news broke because an AMD patch to the kernel spilled the beans. The AMD patch turned off the already present mitigation for Meltdown in the case of AMD processors.