Intel & Arm & AMD and vulnerabilities in 2022

there is new vulnerabilities in 2022,
alder lake and Arm are concerned , it’s never ending in case of intel

status in linux 5.17 mitigation

results added for intel

results added for AMD

3 Likes

Feels like anniversary :joy:

Why are chip manufacturers not liable for shipping defective products in cases that lead to hacking and financial damages?

If this were the case Microborg would be out of business, randsomeware at scale is only made possible because Winblows is just so damned hackable.

2 Likes

Would it be good if they were liable? What would happen with high end processor technology if Intel and AMD would face company threatening problems?

Engineering would be more conservative and their products would become more robust and reliable.

1 Like

hm, my AMD CPU is already using return trampolines, retpolines

$ grep . -r /sys/devices/system/cpu/vulnerabilities/
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, IBPB: conditional, IBRS_FW, STIBP: always-on, RSB filling
/sys/devices/system/cpu/vulnerabilities/itlb_multihit:Not affected
/sys/devices/system/cpu/vulnerabilities/mds:Not affected
/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/srbds:Not affected
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected

What about reticulatingsplines?

2 Likes

If I don’t know what trampolines retpolines means, how should I know what reticulatingsplines means as well? kkkkk

3 Likes

Is it even possible to create processors that are 100% safe and reliable? I have yet to see one system that doesn’t have any exploitable flaw.

1 Like

Of course it is.

Just look at the airline industry.

I would argue a modern day commercial airliner, with all is interactive components and software, is more complex than a cpu design.

When there are no consequences for manufacturing unsafe / unreliable products that is what you’ll get. Quicker time to market, less engineering discipline, less testing, quicker product turnaround.

1 Like

I want to remind you of the Boeing 737 MAX scandal. A lot fo people died, Boeing was/is held accountable, covered stuff up and made shitty components and software. I sincerely doubt modern air travel has good programming and components. Or at least it doesn’t have better components than the topic of this thread.

3 Likes

now you get the result ( on first topic )

This supports Barry’s point. In this instance, there were consequences for the failures.

A buggy CPU, on the other hand, is just an opportunity for more sales. Any CPU newer than about 8-10 years old is perfectly adequate for most desktop use, but rather than making CPUs more secure with the same level of performance they make them less secure to try and achieve performance gains (features which they then have to disable or “mitigate” when people find vulnerabilities in them).

3 Likes

I would raise the counter argument that liability creates an environment where people simply not disclose informations. Be it the VW exhaust gas scandal, the Boeing scandal or many other things, failures will get swept under the carpet until it emerges with a big boom.

I doubt that making processor manufacturers liable is a good way for a better open discussion about problems.

1 Like

Sure, but just because people and companies can lie in any situation doesn’t mean you don’t bother having laws.

That is a ridiculous argument.

If your only conclusion is that accountability for faulty & flawed manufacturing designs will lead to dishonesty, cover up and fraud, so we just shouldn’t bother … then why bother with a legal system in the first place?

CPU manufacturers should be treated the same as other companies when they produce unsafe, faulty and unreliable products; they should not be exempt.

Until that happens nothing will change, it will simply embolden them to take more risks and the number and seriousness of cpu vulnerabilities will increase.

These companies were held accountable, the cover up only escalated the punitive damages and fines handed out.

In the modern world companies that size cannot permanently sweep defects this big under the carpet, it will come out eventually, and when it does the :poop: will hit the fan.

It is the only way.

Is it starting again?

added results on AMD ryzen

It seems that these last kernel/linux firmware updates brought changes to AMD side…

It was:

/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, IBPB: conditional, IBRS_FW, STIBP: always-on, RSB filling

Now it is:

/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Retpolines, IBPB: conditional, IBRS_FW, STIBP: always-on, RSB filling
[2022-03-12T09:24:56-0300] [ALPM] upgraded amd-ucode (20220209.6342082-1 -> 20220309.cd01f85-1)
[2022-03-12T09:24:57-0300] [ALPM] upgraded linux (5.16.13.arch1-1 -> 5.16.14.arch1-1)
[2022-03-12T09:24:57-0300] [ALPM] upgraded linux-firmware-whence (20220209.6342082-1 -> 20220309.cd01f85-1)
[2022-03-12T09:24:57-0300] [ALPM] upgraded linux-firmware (20220209.6342082-1 -> 20220309.cd01f85-1)
[2022-03-12T09:24:58-0300] [ALPM] upgraded linux-headers (5.16.13.arch1-1 -> 5.16.14.arch1-1)
[2022-03-12T09:24:59-0300] [ALPM] upgraded linux-zen (5.16.13.zen1-1 -> 5.16.14.zen1-1)
[2022-03-12T09:25:00-0300] [ALPM] upgraded linux-zen-headers (5.16.13.zen1-1 -> 5.16.14.zen1-1)

Consequences are in analogy to who/what was hurt and how bad. Not all failures (mistakes in code?) can be treated the same. I hope you understand what I want to say, since I am not native English…

The ONLY solution (IMO) to this topic is already known, especially to us.

It’s

Open Source Software and Hardware

:sunglasses:

3 Likes