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

D. Hugh Redelmeier hugh at mimosa.com
Tue Jan 9 12:23:24 EST 2018

| 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

- brand new Haswell chips are not a bargain compared with current

- 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.


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:

- 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

| 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.

More information about the talk mailing list