Intel CPU Design Flaw

[e1-531g]

Originally Posted by jggimi

There is microcode for it, but it doesn't appear to have been updated since November 17.

• The web page lists the CPU in its "This download is valid for the product(s) listed below" section.
• The kernel searches for /etc/firmware/intel/06-2a-07 which is included in the bundle.

Can you tell how did you managed to know which microcode file kernel is searching for?
I would like to know about microcode for my processor i5-3320M
Windows program called CPU-Z says:

Family:6
Model: A
Ext. Model: 3A
Stepping: 9
Revision: E1/L1

Intel provided microcode package 2018-03-12:
https://downloadcenter.intel.com/dow...code-Data-File

[e1-531g]

Yesterday OpenBSD-current had previous Intel firmware from November. Today it has firmware released in march. It should contain Spectre fixes for Sandy and Ivy Bridge, Haswell and so on, but probably mitigations need also OS kernel counterparts to be effective, which at the moment OpenBSD does not have.
http://firmware.openbsd.org/firmware/snapshots/

Meltdown and Spectre PoC for OpenBSD. This is not mine. Use at your own risk.
https://github.com/genua/meltdown

[jggimi]

Originally Posted by e1-531g

Can you tell how did you managed to know which microcode file kernel is searching for?

Had you asked me two months ago, I might have remembered. I will have to guess: keyword searching, probably in /sys/arch/amd64.

[e1-531g]

There is fourth variant.
Speculative Store Bypass
https://www.redhat.com/en/blog/specu...t-how-it-works
https://blogs.technet.microsoft.com/...cve-2018-3639/

[shep]

Theo weighs in on the latest: More vulnerabilities likely, media distractions and new syspatch in the works:
http://www.undeadly.org/cgi?action=a...20180815070400

[shep]

24August2018:

Two recently disclosed hardware bugs affected Intel cpus:

- TLBleed

- T1TF (the name "Foreshadow" refers to 1 of 3 aspects of this
bug, more aspects are surely on the way)

Solving these bugs requires new cpu microcode, a coding workaround,
*AND* the disabling of SMT / Hyperthreading.
SMT is fundamentally broken because it shares resources between the two
cpu instances and those shared resources lack security differentiators.
Some of these side channel attacks aren't trivial, but we can expect
most of them to eventually work and leak kernel or cross-VM memory in
common usage circumstances, even such as javascript directly in a
browser.

There will be more hardware bugs and artifacts disclosed. Due to the
way SMT interacts with speculative execution on Intel cpus, I expect SMT
to exacerbate most of the future problems.

A few months back, I urged people to disable hyperthreading on all
Intel cpus. I need to repeat that:

DISABLE HYPERTHREADING ON ALL YOUR INTEL MACHINES IN THE BIOS.

Also, update your BIOS firmware, if you can.

OpenBSD -current (and therefore 6.4) will not use hyperthreading if it
is enabled, and will update the cpu microcode if possible.

But what about 6.2 and 6.3?

The situation is very complex, continually evolving, and is taking too
much manpower away from other tasks. Furthermore, Intel isn't telling
us what is coming next, and are doing a terrible job by not publically
documenting what operating systems must do to resolve the problems. We
are having to do research by reading other operating systems. There is
no time left to backport the changes -- we will not be issuing a
complete set of errata and syspatches against 6.2 and 6.3 because it is
turning into a distraction.

Rather than working on every required patch for 6.2/6.3, we will
re-focus manpower and make sure 6.4 contains the best solutions
possible.

So please try take responsibility for your own machines: Disable SMT in
the BIOS menu, and upgrade your BIOS if you can.

I'm going to spend my money at a more trustworthy vendor in the future.

http://www.undeadly.org/cgi?action=a...20180824024934

[e1-531g]

Developers of Qubes OS also disabled HT.
https://github.com/QubesOS/qubes-sec...b-043-2018.txt