On January 9, 2018 12:23:24 PM EST, "D. Hugh Redelmeier via talk" <[email protected]> wrote: >| From: Russell via talk <[email protected]> > >| On January 8, 2018 10:33:00 AM EST, "Steve Petrie, P.Eng. via talk" ><[email protected]> 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.
Well your and Lennarts suggestions helped to move me to a more correct value point choice for my situation. Especially your CPU recommendation; dodged a bit of shrapnel with that one, at least according to some of the benchmarks I'm seeing. I checked for vulnerabilities. wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh Ran it and then updated I the MB firmware to the most recent v606. The checker now says. CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Checking count of LFENCE opcodes in kernel: NO (only 34 opcodes found, should be >= 70) > STATUS: VULNERABLE (heuristic to be improved when official patches become > available) CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigation 1 * Hardware (CPU microcode) support for mitigation: YES * Kernel support for IBRS: NO * IBRS enabled for Kernel space: NO * IBRS enabled for User space: NO * Mitigation 2 * Kernel compiled with retpoline option: NO Internet trampoline/java fix needed? Two choices to follow. * Kernel compiled with a retpoline-aware compiler: NO > STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline > are needed to mitigate the vulnerability) One down in any case. CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: YES > STATUS: NOT VULNERABLE (PTI mitigates the vulnerability) > >| >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. I'm asking myself the same question. > >| 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. I'm in 100 per cent agreement with you there. Try and tell a merchant class that security by obscurity, plainly and simply, does not work; see how far that gets you. Having said that, as I become more familiar with policy management tools, I become more trusting of them. Notwithstanding that the it was NSA which produced SElinux. > >| 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> Sorry should have trimmed that url. It's an interesting read considering the situation my current setup choices. > >| 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). Sorry forgot about the f*wit internet trampoline when I said that. > >| 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. >--- >Talk Mailing List >[email protected] >https://gtalug.org/mailman/listinfo/talk -- Russell --- Talk Mailing List [email protected] https://gtalug.org/mailman/listinfo/talk
