# Intel & Arm & AMD and vulnerabilities in 2022

**URL:** <https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884>\
**Category:** Kernel, boot, graphics & hardware\
**Created:** [March 9, 2022, 8:32pm UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884 "2022-03-09T20:32:30Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Stephane](https://forum.endeavouros.com/user_avatar/forum.endeavouros.com/stephane/32/9196_2.png) [@Stephane](https://forum.endeavouros.com/u/Stephane)\
**Post date:** [March 9, 2022, 8:32pm UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/1 "2022-03-09T20:32:30Z")

</div>

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

> **[BHI: The Newest Spectre Vulnerability Affecting Intel & Arm CPUs](https://www.phoronix.com/news/BHI-Spectre-Vulnerability)**
>
> The VUSec security researchers are today -- in cooperation with Intel -- disclosing another new speculative execution vulnerability..

status in linux 5.17 mitigation

> **[Linux Lands Mitigations For Spectre-BHB / BHI On Intel & Arm, Plus An AMD...](https://www.phoronix.com/news/Spectre-BHI-Linux-Mitigations)**
>
> Within minutes of the BHI speculative execution vulnerability going public, patches were merged into the mainline Linux kernel Git tree for mitigating this offshoot from Spectre V2

> **[Intel Releases 20220207 Microcode For Linux Users To Provide Important...](https://www.phoronix.com/news/Intel-Microcode-20220207)**
>
> As part of Intel making a number of security disclosures public today, Intel has published updated CPU microcode images for Linux users via their GitHub repository.

results added for intel

> **[In Light Of Spectre BHI, The Performance Impact For Retpolines On Modern...](https://www.phoronix.com/review/spectre-bhi-retpoline/2)**
>
> First up was an Intel Core i9 12900K 'Alder Lake' desktop processor in seeing the performance impact if enabling the eIBRS + Retpoline option to better protect against Spectre BHI.
> 
> Indeed in workloads exposed to return trampolines overhead, there...

results added for AMD

> **[The Performance Impact Of AMD Changing Their Retpoline Method For Spectre V2](https://www.phoronix.com/review/amd-retpoline-2022)**
>
> Made public this week was the Spectre-BHB / BHI vulnerability and while only Intel and Arm processors are currently believed to be impacted, in the course of that research the folks at VUSec discovered AMD's current Retpoline strategy for Spectre V2...

---

<div class="post-metadata">

**Author:** ![keybreak](https://forum.endeavouros.com/user_avatar/forum.endeavouros.com/keybreak/32/9257_2.png) [@keybreak](https://forum.endeavouros.com/u/keybreak)\
**Post date:** [March 9, 2022, 8:35pm UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/2 "2022-03-09T20:35:10Z")

</div>

Feels like anniversary 😂

---

<div class="post-metadata">

**Author:** ![otherbarry](https://forum.endeavouros.com/user_avatar/forum.endeavouros.com/otherbarry/32/10801_2.png) [@otherbarry](https://forum.endeavouros.com/u/otherbarry)\
**Post date:** [March 9, 2022, 8:49pm UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/3 "2022-03-09T20:49:06Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![I0F](https://forum.endeavouros.com/user_avatar/forum.endeavouros.com/i0f/32/47182_2.png) [@I0F](https://forum.endeavouros.com/u/I0F)\
**Post date:** [March 9, 2022, 8:53pm UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/4 "2022-03-09T20:53:16Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![otherbarry](https://forum.endeavouros.com/user_avatar/forum.endeavouros.com/otherbarry/32/10801_2.png) [@otherbarry](https://forum.endeavouros.com/u/otherbarry)\
**Post date:** [March 9, 2022, 8:55pm UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/5 "2022-03-09T20:55:28Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![anon49550872](https://forum.endeavouros.com/letter_avatar_proxy/v4/letter/a/b2d939/32.png) [@anon49550872](https://forum.endeavouros.com/u/anon49550872)\
**Post date:** [March 9, 2022, 9:14pm UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/6 "2022-03-09T21:14:23Z")

</div>

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

```auto
$ 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

```

---

<div class="post-metadata">

**Author:** ![jonathon](https://forum.endeavouros.com/user_avatar/forum.endeavouros.com/jonathon/32/18722_2.png) [@jonathon](https://forum.endeavouros.com/u/jonathon)\
**Post date:** [March 10, 2022, 1:46am UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/7 "2022-03-10T01:46:18Z")

</div>

> [@anon49550872](#):
>
> trampolines, retpolines

What about reticulatingsplines?

---

<div class="post-metadata">

**Author:** ![anon49550872](https://forum.endeavouros.com/letter_avatar_proxy/v4/letter/a/b2d939/32.png) [@anon49550872](https://forum.endeavouros.com/u/anon49550872)\
**Post date:** [March 10, 2022, 12:32pm UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/8 "2022-03-10T12:32:28Z")

</div>

> [@jonathon](#):
>
> What about reticulatingsplines?

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

---

<div class="post-metadata">

**Author:** ![I0F](https://forum.endeavouros.com/user_avatar/forum.endeavouros.com/i0f/32/47182_2.png) [@I0F](https://forum.endeavouros.com/u/I0F)\
**Post date:** [March 10, 2022, 12:36pm UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/9 "2022-03-10T12:36:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![otherbarry](https://forum.endeavouros.com/user_avatar/forum.endeavouros.com/otherbarry/32/10801_2.png) [@otherbarry](https://forum.endeavouros.com/u/otherbarry)\
**Post date:** [March 10, 2022, 8:16pm UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/10 "2022-03-10T20:16:57Z")

</div>

> [@I0F](#):
>
> Is it even possible to create processors that are 100% safe and reliable?

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.

> [@I0F](#):
>
> I have yet to see one system that doesn’t have any exploitable flaw.

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.

---

<div class="post-metadata">

**Author:** ![I0F](https://forum.endeavouros.com/user_avatar/forum.endeavouros.com/i0f/32/47182_2.png) [@I0F](https://forum.endeavouros.com/u/I0F)\
**Post date:** [March 10, 2022, 9:56pm UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/11 "2022-03-10T21:56:13Z")

</div>

> [@otherbarry](#):
>
> I would argue a modern day commercial airliner, with all is interactive components and software, is more complex than a cpu design.

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.

---

<div class="post-metadata">

**Author:** ![Stephane](https://forum.endeavouros.com/user_avatar/forum.endeavouros.com/stephane/32/9196_2.png) [@Stephane](https://forum.endeavouros.com/u/Stephane)\
**Post date:** [March 10, 2022, 10:10pm UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/12 "2022-03-10T22:10:39Z")

</div>

now you get the result ( on first topic )

---

<div class="post-metadata">

**Author:** ![jonathon](https://forum.endeavouros.com/user_avatar/forum.endeavouros.com/jonathon/32/18722_2.png) [@jonathon](https://forum.endeavouros.com/u/jonathon)\
**Post date:** [March 10, 2022, 10:31pm UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/13 "2022-03-10T22:31:33Z")

</div>

> [@I0F](#):
>
> I want to remind you of the Boeing 737 MAX scandal.

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

---

<div class="post-metadata">

**Author:** ![I0F](https://forum.endeavouros.com/user_avatar/forum.endeavouros.com/i0f/32/47182_2.png) [@I0F](https://forum.endeavouros.com/u/I0F)\
**Post date:** [March 11, 2022, 7:21am UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/14 "2022-03-11T07:21:38Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jonathon](https://forum.endeavouros.com/user_avatar/forum.endeavouros.com/jonathon/32/18722_2.png) [@jonathon](https://forum.endeavouros.com/u/jonathon)\
**Post date:** [March 11, 2022, 10:01am UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/15 "2022-03-11T10:01:03Z")

</div>

> [@I0F](#):
>
> liability creates an environment where people simply not disclose informations

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

---

<div class="post-metadata">

**Author:** ![otherbarry](https://forum.endeavouros.com/user_avatar/forum.endeavouros.com/otherbarry/32/10801_2.png) [@otherbarry](https://forum.endeavouros.com/u/otherbarry)\
**Post date:** [March 11, 2022, 2:55pm UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/16 "2022-03-11T14:55:09Z")

</div>

> [@I0F](#):
>
> I would raise the counter argument that liability creates an environment where people simply not disclose informations.

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.

> [@I0F](#):
>
> VW exhaust gas scandal, the Boeing scandal or many other things

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.

> [@I0F](#):
>
> I doubt that making processor manufacturers liable is a good way for a better open discussion about problems.

It is the only way.

---

<div class="post-metadata">

**Author:** ![zoli62](https://forum.endeavouros.com/letter_avatar_proxy/v4/letter/z/4bbf92/32.png) [@zoli62](https://forum.endeavouros.com/u/zoli62)\
**Post date:** [March 11, 2022, 3:04pm UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/17 "2022-03-11T15:04:07Z")

</div>

Is it starting again?

---

<div class="post-metadata">

**Author:** ![Stephane](https://forum.endeavouros.com/user_avatar/forum.endeavouros.com/stephane/32/9196_2.png) [@Stephane](https://forum.endeavouros.com/u/Stephane)\
**Post date:** [March 11, 2022, 8:55pm UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/18 "2022-03-11T20:55:46Z")

</div>

added results on AMD ryzen

---

<div class="post-metadata">

**Author:** ![anon49550872](https://forum.endeavouros.com/letter_avatar_proxy/v4/letter/a/b2d939/32.png) [@anon49550872](https://forum.endeavouros.com/u/anon49550872)\
**Post date:** [March 12, 2022, 2:01pm UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/19 "2022-03-12T14:01:00Z")

</div>

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

It was:

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

```

Now it is:

```auto
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Retpolines, IBPB: conditional, IBRS_FW, STIBP: always-on, RSB filling

```

```auto
[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)

```

---

<div class="post-metadata">

**Author:** ![petsam](https://forum.endeavouros.com/user_avatar/forum.endeavouros.com/petsam/32/41308_2.png) [@petsam](https://forum.endeavouros.com/u/petsam)\
**Post date:** [March 12, 2022, 7:52pm UTC](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884/20 "2022-03-12T19:52:11Z")

</div>

> [@otherbarry](#):
>
> unsafe, faulty and unreliable products

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

🕶

[Next page](https://forum.endeavouros.com/t/intel-arm-amd-and-vulnerabilities-in-2022/24884.md?page=2)
