[GTALUG] Intel Meltdown Bug -- Conundrum For New Desktop PC Build Spec (to run debian Linux) -- Switch From Intel CPU To AMD CPU ??

Tue Jan 9 13:49:17 EST 2018

On January 9, 2018 12:23:24 PM EST, "D. Hugh Redelmeier via talk" <talk at gtalug.org> wrote:
>| From: Russell via talk <talk at gtalug.org>
>
>| On January 8, 2018 10:33:00 AM EST, "Steve Petrie, P.Eng. via talk"
><talk at 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.

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
>talk at gtalug.org
>https://gtalug.org/mailman/listinfo/talk

-- 
Russell