Security AMD Zenbleed Zero Day Speculative Security Vulnerability On AMD Zen 2 Processors CVE-2023-20593

eva2000 · Jul 25, 2023

A new zero day security vulnerability has been announced for AMD Zen 2 family processors called Zendbleed https://lock.cmpxchg8b.com/zenbleed.html

It turns out that with precise scheduling, you can cause some processors to recover from a mispredicted vzeroupper incorrectly!

This technique is CVE-2023-20593 and it works on all Zen 2 class processors, which includes at least the following products:

AMD Ryzen 3000 Series Processors

AMD Ryzen PRO 3000 Series Processors

AMD Ryzen Threadripper 3000 Series Processors

AMD Ryzen 4000 Series Processors with Radeon Graphics

AMD Ryzen PRO 4000 Series Processors

AMD Ryzen 5000 Series Processors with Radeon Graphics

AMD Ryzen 7020 Series Processors with Radeon Graphics

AMD EPYC “Rome” Processors like EPYC 7xx2 ending in '2'

The bug works like this, first of all you need to trigger something called the XMM Register Merge Optimization2, followed by a register rename and a mispredicted vzeroupper. This all has to happen within a precise window to work.

We now know that basic operations like strlen, memcpy and strcmp will use the vector registers - so we can effectively spy on those operations happening anywhere on the system! It doesn’t matter if they’re happening in other virtual machines, sandboxes, containers, processes, whatever!

This works because the register file is shared by everything on the same physical core. In fact, two hyperthreads even share the same physical register file.
Click to expand...
Solution
We reported this vulnerability to AMD on the 15th May 2023.

AMD have released an microcode update for affected processors. Your BIOS or Operating System vendor may already have an update available that includes it.

Workaround
It is highly recommended to use the microcode update.

If you can’t apply the update for some reason, there is a software workaround: you can set the chicken bit DE_CFG[9].

This may have some performance cost.

Linux
You can use msr-tools to set the chicken bit on all cores, like this:
Code (Text):
# wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))
FreeBSD
On FreeBSD you would use cpucontrol(8).

Others
If you’re using some other operating system and don’t know how to set MSRs, ask your vendor for assistance.

Note that it is not sufficient to disable SMT.

Detection
I am not aware of any reliable techniques to detect exploitation. This is because no special system calls or privileges are required.

It is definitely not possible to detect improper usage of vzeroupper statically, please don’t try!
Click to expand...
From AMD 'Zenbleed' bug lets hackers steal data from Ryzen CPUs | PCWorld

A new vulnerability has been discovered in AMD’s Zen 2 processors—one that allows data like passwords and encryption keys to be stolen from the CPU. Disclosed publicly this week by Google security researcher Tavis Ormandy, this bug affects consumer chips as well as server, including Ryzen 3000 series parts.

As detailed by Ormandy in a post, this “Zenbleed” vulnerability was first shared with AMD back in mid-May. It can be used to execute code through Javascript on a webpage—no physical access is needed for an affected PC. And if exploited successfully, Zenbleed allows attackers to see any CPU operation, including those happening in sandboxes or virtual machines. (You can catch the full technical rundown in Ormandy’s post, or a more summarized version in this Tom’s Hardware report.) All Zen 2 processors in the following processor families are affected:

AMD Ryzen 3000 Series Processors

AMD Ryzen PRO 3000 Series Processors

AMD Ryzen Threadripper 3000 Series Processors

AMD Ryzen 4000 Series Processors with Radeon Graphics

AMD Ryzen PRO 4000 Series Processors

AMD Ryzen 5000 Series Processors with Radeon Graphics

AMD Ryzen 7020 Series Processors with Radeon Graphics

AMD EPYC “Rome” Processors

At this time, AMD has only released a microcode update for 2nd-generation EPYC server CPUs, along with a security advisory explaining the vulnerability (which was filed as CVE-2023-20593) and its release schedule for mitigations.

For consumers, a fix will be funneled through original equipment manufacturers (e.g., Dell or HP for pre-built PCs and laptops, and motherboard manufacturers for DIY PC builds), with arrival dates set for later this year. Threadripper 3000 parts are first up for the new AGESA firmware in October, followed by Ryzen 4000 mobile processors in November. For Ryzen 3000 and 4000 desktop CPUs, as well as Ryzen 5000 and 7020 mobile processors, the target is December 2023.

If you don’t want to wait for AMD, Ormandy explains how to make a software tweak as a workaround—although its impact on performance is unknown. The effect of AMD’s official fixes on performance is also not known currently, though in a statement to Tom’s Hardware, AMD described it as dependent on workload and PC configuration.

In any case, if you own a Zen 2 CPU, you’ll want to put a reminder on your calendar to check for this mitigation. Applying it promptly will be important for your online security.
Click to expand...

eva2000 · Jul 25, 2023

Lucky for me my Linode KVM VPS are AMD EPYC Milan 3rd generation 7xx3 = AMD EPYC 7713

Code (Text):

lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             AuthenticAMD
CPU family:            25
Model:                 1
Model name:            AMD EPYC 7713 64-Core Processor
Stepping:              1
CPU MHz:               1999.989
BogoMIPS:              4001.64
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             64K
L1i cache:             64K
L2 cache:              512K
L3 cache:              16384K
NUMA node0 CPU(s):     0-3

Upcloud VPS users will need to contact support I'd imagine as they use AMD EPYC Rome 2nd gen = AMD EPYC 7542 Rome

Code (Text):

lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                1
On-line CPU(s) list:   0
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
NUMA node(s):          1
Vendor ID:             AuthenticAMD
CPU family:            23
Model:                 49
Model name:            AMD EPYC 7542 32-Core Processor
Stepping:              0
CPU MHz:               2894.560
BogoMIPS:              5789.12
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             64K
L1i cache:             64K
L2 cache:              512K
L3 cache:              16384K
NUMA node0 CPU(s):     0
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm art rep_good nopl extd_apicid eagerfpu pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw perfctr_core ssbd rsb_ctxsw ibrs ibpb stibp vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 retpoline_amd arat umip spec_ctrl intel_stibp

eva2000 · Jul 25, 2023

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html

Under specific microarchitectural circumstances, a register in “Zen 2” CPUs may not be written to 0 correctly. This may cause data from another process and/or thread to be stored in the YMM register, which may allow an attacker to potentially access sensitive information.
Click to expand...

AMD recommends applying the µcode patch listed below for AMD EPYC™ 7002 Processors, and applying BIOS updates that include the following AGESA™ firmware versions for other affected products. AMD plans to release to the Original Equipment Manufacturers (OEM) the AGESA™ versions on the target dates listed below. Please refer to your OEM for the BIOS update specific to your product.
Click to expand...

For data center CPUs

Mitigation detail

Update to versions listed or higher

2nd Gen AMD EPYC™ Processors “Rome”

µcode = 0x0830107A
AGESA™ firmware = RomePI 1.0.0.H
Click to expand...

eva2000 · Jul 25, 2023

AlmaLinux has test patches for Zenbleed AlmaLinux OS - Forever-Free Enterprise-Grade Operating System
Earlier today our community pointed out a new, trivially exploitable flaw in AMD systems called Zenbleed. Due to an accident on the AMD side, the patch was released ahead of responsible disclosure, and unpatched systems are at great risk. We were able to pull in the patch, get through our normal testing, and we are now ready for wider testing for both AlmaLinux 8 and 9.

How did AlmaLinux get the patch?
The fix was released by AMD, so we were able to pull that directly in, similar to what all other distributions are currently having to do. We pulled in three patches from linux-firmware upstream:

https://git.kernel.org/pub/scm/linu...e?id=69143e8eca62a80b9791b8d358d1cc4c90e373c9

https://git.kernel.org/pub/scm/linu...e?id=b250b32ab1d044953af2dc5e790819a7703b7ee6

https://git.kernel.org/pub/scm/linu...e?id=0bc3126c9cfa0b8c761483215c25382f831a7c6f

You can see the diff of the changes on git.almalinux.org.

How do I install the updated packages?
Due to the risks involved in these patches, these packages are not yet in production and need testing! If you are willing to help provide us feedback, and have access to a bare metal AMD system, you can manually install them by pulling them from the AlmaLinux Build System.

To install the new RPM on AlmaLinux 8:
Code (Text):
dnf update https://build.almalinux.org/pulp/content/builds/AlmaLinux-8-x86_64-7032-br/Packages/l/linux-firmware-20230404-114.git2e92a49f.el8_8.alma.noarch.rpm
For AlmaLinux 9:
Code (Text):
dnf update https://build.almalinux.org/pulp/content/builds/AlmaLinux-9-x86_64-7033-br/Packages/l/linux-firmware-20230310-134.el9_2.alma.noarch.rpm
To check that the installation completed successfully, you can run
Code (Text):
rpm -qa linux-firmware
To update CPU microcode run the following:
Code (Text):
echo 1 > /sys/devices/system/cpu/microcode/reload
Once you have completed your testing, please help us by letting us know it works for you! Please share the following information (sanitized in whatever way you feel comfortable) in a comment on the issue we’ve opened to track this update on bugs.almalinux.org. We have created one specific to AlmaLinux 8 and one for AlmaLinux 9. Please include the output of the two commands from the test server.

Did it work for you? Yes or no.
Code (Text):
lscpu

journalctl -k --grep=microcode
Why call for testing now?
The depth of this exploit is motivation for moving fast, in our opinion. Our users are looking for a patch to come quickly, and this is one more opportunity that we have as a result of our decision to aim for ABI compatibility. We will be looking for more opportunities for testing and early/beta adopters as we expand. In fact, we have a kernel update in testing right now, that was shared in chat.almalinux.org earlier today. If you have interest in helping us with testing, please do join us there!

Come help!
Joining the AlmaLinux community is easy! For anyone that has time to offer: the Release Engineering SIG (~Engineering/RelEng on chat.almalinux.org) could use help for testing and building our pipelines, but the Infra, Cloud, and Marketing SIGs are always looking as well. You can also convince your company to become a sponsor or just back us as an individual on GitHub or OpenCollective.

Thank you to everyone who helps make AlmaLinux happen. Our individual sponsors and backers in addition to our corporate sponsors are the biggest reason we can continue to provide AlmaLinux OS free forever.
Click to expand...

eva2000 · Jul 25, 2023

Cloudflare Blog regarding AMD Zenbleed https://blog.cloudflare.com/zenbleed-vulnerability/

A new flaw in AMD's Zen 2 processors is detailed in this blog post (archive.org snapshot) today, July 24, 2023. The 'Zenbleed' flaw affects the entire Zen 2 product stack, from AMD's EPYC data center processors to the Ryzen 3000 CPUs, and can be exploited to steal sensitive data stored in the CPU, including encryption keys and login credentials. The attack can even be carried out remotely through JavaScript on a website, meaning that the attacker need not have physical access to the computer or server.

Cloudflare’s network includes servers using AMD’s Zen line of CPUs. We have patched our entire fleet of potentially impacted servers with AMD’s microcode to mitigate this potential vulnerability. While our network is now protected from this vulnerability, we will continue to monitor for any signs of attempted exploitation of the vulnerability and will report on any attempts we discover in the wild. To better understand the Zenbleed vulnerability, read on.
Click to expand...

The attack
Speculative execution attacks have previously been used to compromise CPU registers. These are an attack variant that takes advantage of the speculative execution capabilities of modern CPUs. Computer processors use a method called speculative execution to speed up processing times. A CPU will execute an instruction speculatively if it has no way of knowing whether it will be executed. If it turns out that the CPU was unable to carry out the instruction, it will simply discard the data.

Because of their potential use for storing private information, AVX registers are especially susceptible to these kinds of attacks. Cryptographic keys and passwords, for instance, could be accessed by an attacker via a speculative execution attack on the AVX registers.

As mentioned above, the vulnerability in AMD's Zen 2-architecture-based CPUs, wherein data from another process and/or thread could be stored in the YMM registers, a 256-bit series of extended registers, potentially allowing an attacker access to sensitive information. This vulnerability is caused by a register not being written to 0 correctly under specific microarchitectural circumstances. Although this error is associated with speculative execution, it is not a side channel vulnerability.

This attack works by manipulating register files to force a mispredicted command. First, there is a trigger to XMM Register Merge Optimization2, which ironically is a hardware mitigation that can be used to protect against speculative execution attacks, followed by a register remapping (a technique used in computer processor design to resolve name conflicts between physical registers and logical registers) and then a mispredicted instruction call to vzeroupper, an instruction that is used to zero the upper half of the YMM and ZMM registers.

Since the register file is shared by all the processes running on the same physical core, this exploit can be used to eavesdrop on even the most fundamental system operations by monitoring the data being transferred between the CPU and the rest of the computer.
Click to expand...

Fixing the bleed
Because of the exact timing for this to successfully execute, this vulnerability, CVE-2023-20593, is classified with a CVSS score of 6.5 (Medium). AMD's mitigation is implemented via the MSR register, which turns off a floating point optimization that otherwise would have allowed a move operation.

The following microcode update is getting applied to our entire server fleet that contain potentially affected AMD Zen processors. We have seen no evidence of the bug being exploited and will continue to monitor traffic across our network for any attempts to exploit the bug and report on our findings.
Click to expand...

buik · Jul 26, 2023

eva2000 said: ↑

The depth of this exploit is mWe have seen no evidence of the bug being exploitedotivation for moving fast, in our opinion. Our users are looking for a patch to come quickly, and this is one more opportunity that we have as a result of our decision to aim for ABI compatibility. We will be looking for more opportunities for testing and early/beta adopters as we expand.
Click to expand...

Don't like this at all.
There is a very obvious reason that Red Hat, tests updates thoroughly. Linux firmware is the package required for partial or full functionality of certain hardware devices. You definitely don't want 0 day code in there. Unless there really is no other way, but there is no reason for that at the moment.

CVE-2023-20593 is classed as medium. and since it is not (mis)used, totally no redeb to panic.

We have seen no evidence of the bug being exploited
Click to expand...

I was already worried that AlmaLinux would go this route, after the announcement towards non 1:1.

eva2000 · Jul 26, 2023

buik said: ↑

You definitely don't want 0 day code in there. Unless there really is no other way, but there is no reason for that at the moment.
Click to expand...

Usually I'd agree. Though Cloudflare themselves already took the very same patches and applied it to their entire AMD EPYC Zen2 fleet of servers. They wouldn't do that if their folks with knowledge deemed it OK to do so - same as AlmaLinux folks. Though in AlmaLinux's case they're only releasing it for testing. Of course side effects depending on hardware used aren't truly known yet

buik · Jul 26, 2023

eva2000 said: ↑

Usually I'd agree. Though Cloudflare themselves already took the very same patches and applied it to their entire AMD EPYC Zen2 fleet of servers. They wouldn't do that if their folks with knowledge deemed it OK to do so - same as AlmaLinux folks. Though in AlmaLinux's case they're only releasing it for testing. Of course side effects depending on hardware used aren't truly known yet
Click to expand...

But here is a big difference. Cloudflare obviously knows its own "custom" server fleet like the best.
Complete data cages or even datacenters with the same servers using the exact same components.
Of course, they have a few different server models. It could hardly be otherwise. But that seems to me to be limited to the minimum. Then it's quite easy to make a patch, stress it on test servers first, beforce implementing it production wise.
And Cloudflare as a company providing Internet security services, you have to.

A generic distro like AlmaLinux is a big different, in my opinion.
Which should run on any computer built with all the components and thus combinations from the Hardware - Red Hat Ecosystem Catalog.

Should it be a critical CVE, as a temporary, patch, ok as long as it is later replaced by RHEL upstream code.
And that doesn't happen. The example I cited the other day is Grafana.

AlmaLinux used Stream code to fix Grafana's critical CVE.
The code is not replaced with RHEL upstream code and it is still using Stream code.
Despite the fact that RHEL has long since released an update.

As can also be seen in AlmaLinux's Grafana software with Stream code and the version of Rocky Linux, which is a 1:1 on RHEL.

eva2000 · Jul 26, 2023

buik said: ↑

AlmaLinux used Stream code to fix Grafana's critical CVE.
The code is not replaced with RHEL upstream code and it is still using Stream code.
Despite the fact that RHEL has long since released an update.
Click to expand...

Isn't that expected given AlmaLinux is no longer 1:1 clone of RHEL? AlmaLinux used Grafana's direct upstream source patch https://git.almalinux.org/rpms/grafana/commit/0ee7429587298d987cde5406df203320de227083

Fix CVE-2023-3128(Patch was taken from grafana github sources and backported for 9.0.9)
Click to expand...

That seems normal to me. My PHP-FPM EOL 5.6, 7.0-7.4 backported security patches are also from official php.net backported patches too

Seems the actual backport patch is from Grafana upstream source while the unit test patched (0011-fix-alert-test.patch) is from CentOS Stream?
Code (Text):
# https://gitlab.com/redhat/centos-stream/rpms/grafana/-/blob/3731c12a8956d50514a58d9aa2f2d330d4ee32b6/0007-fix-alert-test.patch
Patch11: 0011-fix-alert-test.patch
# Patch was taken from grafana github sources and backported for 9.0.9
# git diff v9.2.19 v9.2.20 -- pkg/
Patch12: 0012-CVE-2023-3128.patch

buik · Jul 27, 2023

eva2000 said: ↑

Isn't that expected given AlmaLinux is no longer 1:1 clone of RHEL.
That seems normal to me. My PHP-FPM EOL 5.6, 7.0-7.4 backported security patches are also from official php.net backported patches too.
Click to expand...

Not logically or by definition.
None 1:1 copy is in my opinion whatever Oracle does. Adding own software, because customers are likely to ask for it.

Supporting multiple PHP versions (also with backport patches if needed in case of EOL), just like what you are doing.
Offering MySQL software, supporting multiple additional Linux Kernels etc.

So now AlmaLinux is fixing CVEs with code other than upstream. Totally unnecessary.

Thus, the distro unnecessarily drifts away from upstream. Time and energy better used elsewhere because you can easily use upstream patches. For example, use the time for an Alma-homemade kernel. CloudLinux like multiple PHP versions etc.

eva2000 · Jul 27, 2023

buik said: ↑

AlmaLinux is fixing CVEs with code other than upstream.
Click to expand...

?? Both patches resulting diff's look the same to me grafana-almalinux-vs-rockylinux-patch-compare - Diff Checker ?

buik · Jul 27, 2023

eva2000 said: ↑

?? Both patches resulting diff's look the same to me grafana-almalinux-vs-rockylinux-patch-compare - Diff Checker ?
Click to expand...

Exactly and so that's the problem. Apparently, they feel they have to sit in Red Hat's chair.
Same patch, different source, given the minor changes.
With a release way too fast, so proper testing is almost impossible.

This in combination with mixed Stream code, as you point out yourself. Gives a strange codebase mix.
Same as this AMD bug, lots of effort to do, then Red Hat arrives with a similar patch a few days later.

Why? I see absolutely no use case for a Stream mixed distro with fixes very similar to upstream.

eva2000 · Jul 27, 2023

buik said: ↑

Why? I see absolutely no use case for a Stream mixed distro with fixes very similar to upstream.
Click to expand...

Personally, I don't see the problem. You do what needs to be done to solve a problem

AlmaLinux are releasing the AMD Zenbleed patch on July 27th it seems https://almalinux.discourse.group/t/zenbleed-patch-release-7am-eastern-us-time-7-27-23/2802

Hi all! As I’m sure y’all have seen there was a flaw announced and patches released that is trivially executable in a large number of AMD environments. We announced Monday that we had a patch for Zenbleed ready 22 (please read the blog post for full details), but wanted testing.

So far we have seen a significant number of users and companies apply the patches with our updated linux-firmware package with no reported problems, and therefore we plan to push the updated package live at 07:00 US eastern time July 27th.

If you are at all concerned, we encourage you to test in your own environment and let us know if you find any problems.

As a side note: we have already been, but are continuing to discuss the right way to handle this in a sustainable way going forward. If you have interest in being part of that solution, join our chat 2 and keep an eye out for when we start to build those structures, and make sure to join us at the AlmaLinux OS Foundation 5.
Click to expand...

They're also inviting for user feedback on how they should be handling these in future

eva2000 · Jul 27, 2023

In contrast Rocky Linux is contining 1:1 clone RHEL compatibility so they decide to wait on RHEL's response https://forums.rockylinux.org/t/zen...s-rocky-linux-working-on-it/10812/2?u=eva2000. But RHEL are confusingly saying 'not affected' ? Which is true for Kernel package 2217845 – (CVE-2023-20593, zenbleed) CVE-2023-20593 hw: amd: Cross-Process Information Leak

Edit: looks like they updated cve-details to list as Affected.

So will be while to wait on RHEL and Rocky Linux to address AMD Zenbleed. Yeah takes time to test patches so sort of expected.

Greetings and welcome to the forums.
Rocky is sticking to the promise to stay 1:1 with RH. Alma has made the choice to go a different path.

Thus, it is important to see what RH is doing to know if Rocky will get the patch. It seems they’ve classified it as “not affected” but I don’t understand their logic. This has nothing to do with the kernel but rather the linux-firmware and microcode packages.
https://access.redhat.com/security/cve/cve-2023-20593 3

However, there are active discussions on the bug report for it:
https://bugzilla.redhat.com/show_bug.cgi?id=2217845 4

If RH patches upstream, then Rocky will publish the patch as well.

Hope that helps.
Click to expand...

Indeed, I have also stumbled on that report and it’s actually quite strange.

The discussion in the bugzilla report also indicates that this is actually
blocking another bug (Bug Access Denied),
which is unfortunately not accessible without a Bugzilla login but that
makes me hope that eventually RH will release a fix (sooner than later,
hopefully).
Click to expand...

From
2217845 – (CVE-2023-20593, zenbleed) CVE-2023-20593 hw: amd: Cross-Process Information Leak

cve-details lists kernel packages as "not affected", which is both true and completely irrelevant: CVE-2023-20593 is not a kernel issue (even though some kernel-side mitigations exist), it's a CPU problem and the fix is a microcode update.

Could we please get a linux-firmware update that contains the updated µcode in https://git.kernel.org/pub/scm/linu.../?id=0bc3126c9cfa0b8c761483215c25382f831a7c6f?

Debian already released an updated amd64-microsode package 2 days ago, so with Red Hat still not having even correctly assessed the issue, let alone provided any fix or mitigation, it's hard for customers to understand the value of paying an Enterprise support license in the hope of getting timely security updates. Or support.
Click to expand...

buik · Jul 27, 2023

eva2000 said: ↑

Personally, I don't see the problem. You do what needs to be done to solve a problem
Click to expand...

Because "ABI compatible with RHEL" is far too vaguely defined in terms of compatibility.
That they are no longer go 1 on 1, oke fine no problem. But then at the very least take 100% compatibility just like Oracle.
Or specify exactly what... as ABI is an incredibly broad term. And without extensive specification, it is nothing at all.
And since only a few lines of code differ now, you don't notice much of it. We'll see in a while. After they really start changing a lot of code.

As I suspected earlier, AlmaLinux want's in that Red Hat's chair,
and via GitLab and others is actively fixing, or trying to fix Red Hat's software and sending in patches.

AlmaLinux argues that: “We can fix this now. We don’t have to wait.”
That's exactly the same as: I know I'm going to die someday, I better die now. I don't have to wait.

You cannot solve a problem that does not exist (software was rated as not affected on that time). So without a specific use case, there is absolutely no reason to go correcting or (trying) directing Red Hat's software.

There is a reason Red Hat is waiting to update software and/or release a potential update.
It is complex matter and needs to work perfectly with its large compatibility hardware index before they come out with an update. And since the impact is changed from not affected to only moderate, I don't understand the panic of some administrators.

But that, of course, is my personal opinion. Just like everything I write here.

In fact, the microcode (linux-firmware) currently only fixes a small subset of AMD CPUs while the kernel patch fixes all of them.
Click to expand...

eva2000 · Jul 28, 2023

buik said: ↑

And since only a few lines of code differ now, you don't notice much of it. We'll see in a while. After they really start changing a lot of code.
Click to expand...

Yeah that would be expected if AlmaLinux is not pursuing 1:1 RHEL clone state. When I refer to doing what you need to do to solve a problem, I was thinking back when I inspected some of RHEL's .spec file source RPM files and patches, they sometimes take upstream open source updates/backports and alter the code so it works with RHEL's package/version dependencies = RHEL does whatever it needs to do to make it work with what they have.

buik said: ↑

You cannot solve a problem that does not exist (software was rated as not affected on that time).
Click to expand...

In AlmaLinux's defence, Redhat later changed AMD Zendbled to affected for all but RHEL 6 - so RHEL 7, 8, 9 are all affected cve-details. Just Redhat was either slow off the mark or incorrectly diagnosed AMD Zenbleed from the initial bug report discussion at least 2217845 – (CVE-2023-20593, zenbleed) CVE-2023-20593 hw: amd: Cross-Process Information Leak

But yes the microcode/linux firmware fix is for small set of AMD Zen2 CPUs, rest would need vendor BIOS updates from motherboard manufacturers which for mobile/desktop AMD Zen2 aren't scheduled until Oct-Dec 2023! For some folks impacted, would be quicker to switch/upgrade the CPU to AMD Zen3 or AMD Zen4 based

buik · Jul 29, 2023

Let me be clear
I am not defending anyone.
I disagree with the new path of both AlamaLinux, and Red Hat.
It's just my opinion.

eva2000 said: ↑

In AlmaLinux's defence, Redhat later changed AMD Zendbled to affected for all but RHEL 6 - so RHEL 7, 8, 9 are all affected cve-details. Just Redhat was either slow off the mark or incorrectly diagnosed AMD Zenbleed from the initial bug report discussion at least 2217845 – (CVE-2023-20593, zenbleed) CVE-2023-20593 hw: amd: Cross-Process Information Leak
Click to expand...

I don't think Red Hat was slow or incorrect.
At that time, the CVE was not final yet (still-unrated CVE at that time).
You have to be ansolutely sure. You can't start intergrating all kinds of security related code without an established CVE.

And since Red Hat uses the principle of backport.
They have to do more work because custom code, can be of great influence.
This obviously has to be done carefully and that takes time.

eva2000 · Jul 29, 2023

buik said: ↑

It's just my opinion.
Click to expand...

Definitely understand that

buik said: ↑

This obviously has to be done carefully and that takes time.
Click to expand...

Yeah a fine balance between adequate testing and urgency for zero day security vulnerabilities

buik · Jul 31, 2023

eva2000 said: ↑

Definitely understand that
Yeah a fine balance between adequate testing and urgency for zero day security vulnerabilities
Click to expand...

With a moderate CVE, there is no urgency and no reason to speed-up, the process at all.
If critical in case of vulnerabilities however, known software houses almost always get the code at least a week before publishing the CVE formally.

Then company's like Red Hat releases a patch update on day 1.
But of course well tested because it has received the code times before.
I keep repeating it. I don't understand this fuss about a moderate CVE at all.
Perhaps because I am clearly trained in stressful situations.

Where step 1 is, to keep your head cool.
The latter is not to be tough, i am not mr big star. I'm off the street and Straight edge. I just mean that more colleagues should take this training. Just be cool. Nothing to worry.

eva2000 · Sep 4, 2023

Just did a yum update on my AlmaLinux 8 and AlmaLinux 9 Centmin Mod servers and see the linux-firmware and microcode_ctl updates for Intel Downfall and AMD Zenbleed security vulnerabilities now now out of test repo into main repo AlmaLinux OS - Forever-Free Enterprise-Grade Operating System

On AlmaLinux 8 got these updates
Code (Text):
                               
  linux-firmware-20230404-114.git2e92a49f.el8_8.alma.1.noarch                               
  microcode_ctl-4:20220809-2.20230808.1.el8_8.alma.x86_64
On AlmaLinux 9 got these updates
Code (Text):
  linux-firmware-whence-20230310-134.el9_2.alma.1.noarch                                   
  microcode_ctl-4:20220809-2.20230808.1.el9_2.alma.noarch
From AlmaLinux instructions after update, to update the CPU microcode run the following or reboot the computer:
Code (Text):
echo 1 > /sys/devices/system/cpu/microcode/reload
using microcode reload echo command on AlmaLinux 8
Code (Text):
dmesg | egrep -iv 'firewall' | grep -C2 microcode
[12204821.506073] i2c i2c-2: sendbytes: NAK bailout.
[12214335.393522] i2c i2c-2: sendbytes: NAK bailout.
[12217429.885519] microcode: updated to revision 0xf4, date = 2023-02-23
[12217429.885566] x86/CPU: CPU features have changed after loading microcode, but might not take effect.
[12217429.885567] x86/CPU: Please consider either early loading through initrd/built-in or a potential BIOS update.
[12217429.885568] microcode: Reload completed, microcode revision: 0xf4
AlmaLinux 9 system didn't show anything in dmesg but does see auto applied microcode updates via command
Code (Text):
grep -i microcode /var/log/messages

Log in / Register

Forums

Welcome to Centmin Mod Community

Security AMD Zenbleed Zero Day Speculative Security Vulnerability On AMD Zen 2 Processors CVE-2023-20593

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

.

Log in / Register

Useful Searches

Welcome to Centmin Mod Community

Security AMD Zenbleed Zero Day Speculative Security Vulnerability On AMD Zen 2 Processors CVE-2023-20593

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

.