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

[Russell]

On January 8, 2018 10:33:00 AM EST, "Steve Petrie, P.Eng. via talk" <talk at gtalug.org> wrote:
>Warm Greetings To GTALUG Members,
>
>Just as year 2018 arrived and I prepared to push the Order button, on
>the various parts for building a new desktop PC to run debian LInux,
>replacing an ancient Dell Windows XP PC, along comes revelation of the
>Intel Meltdown CPU bug, to muddy the picture.

As someone who has already pushed the order button on a future with Intel, I'll add my 2c about some of the perception(s) of the flaws.

>
>My present new desktop PC build spec (much modified according to some
>excellent earlier advice from GTALUG members) has an Intel Z97 LGA 1150
>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.

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 attach a copy of the present build spec:
>a.. <ca.pcpartpicker.com -- deb8_PC_business_24_7_duty_bare_v1 -
>summary - Steve_Petrie - 20170722.odt.pdf>; 
>b.. <ca.pcpartpicker.com -- deb8_PC_business_24_7_duty_bare_v1 -
>accessories - Steve_Petrie - 20170722.odt.pdf>;
>* * *
>* * *
>
>It seems to me that, with regard to the Intel Meltdown bug, I have two
>basic options:
>a.. 1. Just accept the Meltdown bug situation, proceed with the PC
>build using the Intel CPU, and live with the perforrmance hit that
>comes with the fix in the Linux kernel for the Meltdown bug.

This is what I'll have to do, having already assembled my base box on an Z370 w/ Intel i-7 8700. 

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. Heck I bought two Z370 motherboards, fully expecting to relegate my current i7 CPU to headless storage. I figured by the time I migrate my data from ISA/PATA disk storage, I'd be ready for the next generation, mostly due to the obsolete MB etc. in my rack. The next Intel gen is 10nm. This is much more densely configured. In fact that density is a big part of the problem.

Think Rowhammer, but on the CPU die.

https://en.m.wikipedia.org/wiki/Row_hammer

While Rowhammer can use electrical/thermal anomalies to flip bits; in terms of Meltdown et al, a similar buffering scheme, or kernel isolation if you prefer, is compromised by these current exploits. 

>    
>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. Having a predictive microcode hypervisor has been described as having a RISC backend with a CISC frontend. This issue could probably be mitigated by switching entirely to RISC. In fact the industry has moved in the other direction. This happened in part because Linux was pioneered on CISC; due to the affordablity constraints of the volunteer development of GNU/Linux.

>
>* * *
>* * *
>
>*** LATE BREAKING NEWS ***
>
>Speaking of DragonFlyBSD, here is an interesting snippet just in from
>the dfly <users at dragonflybsd.org> email discussion forum:
>
>Subject: Re: Meltdown and Spectre information update
>
>Matthew Dillon wrote:
>> (2) Intel is supplying a Microcode patch for newer CPUs, but it's
>hard
>> to say how many BIOS makers will ever adopt it.
>
>I wouldn't count on it very much, especially nowadays when hardware is
>very usable far longer than vendors are even willing to support it.
>
>But that's the reason why Linux kernel provides a way to update a
>microcode early during boot or even in runtime. Maybe it's a good idea
>to implement it for DragonFly as well.
>
>https://github.com/torvalds/linux/blob/master/Documentation/x86/microcode.txt
>
>Could be a promising fix for Meltdown, using the Linux microcode update
>facility to install the Intel microcode patch for the Meltdown bug. I
>may need to switch to a newer Intel CPU (than Haswell), if no Meltdown
>microcode fix is forthcoming from Intel for Haswell.

You should be ok, Haswell is still within it's operational lifespan. Here's what Intel says about these "side channel" exploits.

https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html

>
>* * *
>* * *
>
>Do GTALUG members have any opinions on the relative merits of the
>strategies I suggest above ??
>
>Any comments / advice from GTALUG members, regarding the above
>strategies (or any other strategy that comes to mind) would be
>gratefully received.
>
>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
>

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. 

I'm not losing any sleep over my choices but then again, I am not running a cloud service which holds the confidential passwords or financial information of millions of people.

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

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.

>Thanks in advance,

Good luck with your choices. Remember, you have to be compromised in the first place for these exploits to take hold. The weakest link is the cloud. My Nexux phone (Android 6) hasn't burped yet. My older LG updated 32 apps when I turned it on yesterday. 

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

Cheers
>
>Steve
>
>apetrie at aspetrie.net

-- 
Russell