Hi
See kernel/git/firmware/linux-firmware.git - Repository of firmware blobs for use with the Linux kernel
and WHENCE file;
STIBP: “Single Thread Indirect Branch Predictors” – <https://www.theregister.co.uk/2018/11/20/linux_kernel_spectre_v2_patch_slowdown_intel/>.
BTW, on this AMD machine:
# find /sys/devices/system/cpu/vulnerabilities/* -print -exec cat {} \;
/sys/devices/system/cpu/vulnerabilities/l1tf
Not affected
/sys/devices/system/cpu/vulnerabilities/meltdown
Not affected
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1
Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full AMD retpoline, IBPB: conditional, STIBP: disabled, RSB filling
#
STIBP is Single Thread Indirect Branch Predictors, which counters Spectre Variant 2 attacks
If you disable the firmware you don’t get any protection from spectre
[QUOTE=malcolmlewis;2896786]Hi
See https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/about/
and WHENCE file;
I see nothing on these links which makes the binary blobs OSS. What do you mean?
[QUOTE=dcurtisfra;2896816]STIBP: “Single Thread Indirect Branch Predictors” – <https://www.theregister.co.uk/2018/11/20/linux_kernel_spectre_v2_patch_slowdown_intel/>.
BTW, on this AMD machine: …]
[/QUOTE]
Thanks. What is your AMD machine? I am curious to know as it says “Not affected” for a few of those. I would be happy to find a CPU which is not affected by any of those but perhaps that would be a challenge 
[QUOTE=gogalthorp;2896836]STIBP is Single Thread Indirect Branch Predictors, which counters Spectre Variant 2 attacks
If you disable the firmware you don’t get any protection from spectre[/QUOTE]
Why do you say “any”? According to what I pasted above there is still some protection with other code names (although I am not aware how worse it is compared to STIBP).
/sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: **Full generic retpoline**, STIBP: disabled, **RSB filling**
FWIW: I forgot to mention that on that newly installed Leap where I didn’t install kernel-firmware I also deliberately did not installe ucode-intel and ucode-amd. Perhaps if I would have installed those the mitigations would work.
Unfortunately not one of the currently purchasable models – except, maybe, as a used machine:
- AMD FX™-4100 Quad-Core Processor.
Thanks, dcurtisfra.
Correction to this: I saw that the second Ethernet adapter was failing due to missing firmware, so re-installing kernel-firmware was necessary. Obviously some hardware needs that.
Correction to that too: It seems there is a fully open source machine out there:
https://raptorcs.com/content/TL1BC1/intro.html
I haven’t researched anything more about it though.
I think you’re barking up the wrong tree. Firmware != Software.
Try convincing the NVIDIA’s, the AMD’s, Broadcoms of this world to load their devices with open firmware.
Re. the raptor machine: Try to use some wireless/bluetooth device and you’ll meet the same issue again.
My thinking as well. Many devices commonly employ both proprietary hardware and firmware to function - it’s a fact of real world life.
Yes, agreed: if one stops to consider the commercial world – all hardware is “commercial” – and, one is confronted with Patents – whether one wants to be or not …
- The CPU manufacturers have patented portions of their CPU Architecture and Instruction Sets – the associated Firmware and Microcode is affected by these Patents …
- Despite the fact that, the Standards for the Interface Protocols are published – often accessible only on payment of a fee – the Interface Hardware manufacturers have patented parts of the Protocols «Members of each “Protocol Club” are often exempt from licensing fees or have “special arrangements”». The Firmware and Microcode associated with each Hardware Interface is affected by these patents …
- Please note that, the Patents related to Hardware characteristics and Interface Protocols are not, IMHO, Software Patents …
- For further thoughts on Software Patents and why I personally do not classify Hardware and Interface Protocol Patents as being “Software Patents”, please note Richard Stallmann’s software development talk/essay: <https://www.gnu.org/philosophy/software-patents.en.html>.
[HR][/HR]Bottom line:
- IMHO, if you want to purchase modern, energy saving, “Green”, Hardware, you are forced to accept the commercial issues, the Patents and, the Firmware and/or Microcode …
Maybe my ideas are too simple. But I have worked with large systems in the 1970ties. When you opened a door there was a big chance you saw a whole matrix of pins with lots and lots of threads connecting those pins and to other parts of the systems. The technicians of the manufacturer that maintained the systems got sometimes bunches of paper that described changes (updates) to the hardware. They then used hours (of course down time of the system) in removing threads and adding new connections (don not make any errors in counting from left to right and from top to bottom!). This to change the logic of the machine, removing ‘bugs’ or improving it’s working.
On nowadays hardware, the firmware is deciding how the hardware will function, like the cabling was in the old times. An updated firmware is the way to remove bugs and improve the chips working. It is just the part of the hardware that can be adapted, like the cabling was earlier. Thus I see firmware as an integrated part of the hardware. And when your hardware is not Open, your firmware isn’t either.
Just my 2 cents.
Thanks everyone for the replies.
I have pretty much got the answers to my questions
Henk, from where I’m sitting, that was “Wire-Wrap” – DEC had automated Wire-Wrap facilities for their Backplanes – PDP-7 (18 bit – used by Ken Thompson to implement the first UNIX®), PDP-8 (12 bit), PDP-11 (16-bit), PDP-15 (18 bit), VAX-11 (32 bit) and DEC-System (36 bit) machines. The DEC-System 20 machines went even further: the CPU modules were multi-layer (more than 3 layers … ) PCBs with additional wired paths on the space around the ICs …
And yes, we occasionally had “Field Change Orders” (FCOs) to re-route some of the wiring at the customer’s site but, we often took the “easy way out” – we simply swapped out the backplane for one with a later revision …
I was mainly talking about Unisys 1100 systems. But yes, the Wire wrap technique was used there also. Sort of pistol, put the end of the wire in it and it was tightly turned a few times around the pin. Apparently so tight that it would not loosen again. Wires were coloured in all sorts of fantastic combinations.
I am pretty sure I have some colour slides of those “internal” of the hardware, but I have no scanner to show them here.
For PDP-11’s in the field, we used something which looked like a metal Punch – purely “finger tip” feel – no pre-set mechanical help … >:)
Scary!
I did some work with PDP-11’s, but no hardware field changes.