Fatal glibc error: CPU does not support x86-64-v2

[vikman90]

Wazuh version	Install type	Action performed	Platform
4.8.0	Manager	Install / Upgrade	Proxmox ≤ 7.x

Description

Users have reported encountering the following error while running our packages:

Fatal glibc error: CPU does not support x86-64-v2

This issue appears to be related to an incompatibility between the version of glibc used in our 4.8.0 release and certain older CPUs. This error has been specifically noted in environments using Proxmox 7.x or earlier.

Rationale

The root cause of this issue stems from the deprecation of older operating systems (e.g., CentOS 6 and Debian 7) and a change related to CURL:

• Deprecate CentOS 6 and Debian 7 on Wazuh Manager compilation #2164
• Update OpenSSL dependency to 1.1.1t and CURL to 7.88.1 wazuh#16279

Additionally, glibc has introduced requirements that certain CPU features must be present, which are only available in CPUs starting from the Intel Core 2 Duo architecture. This means that any CPU lacking these features, or virtual environments not properly emulating them, will fail to execute the binaries.

While Proxmox version 8 and later should not face this issue, older CPUs and certain virtual environments (e.g., Proxmox 7.x or earlier) may not meet the necessary requirements. The failure is likely due to virtualized environments where the CPUID presented to the guest OS does not include the necessary feature flags.

Affected Platforms

• Physical machines with CPUs older than Intel Core 2 Duo.
• Virtual environments using Proxmox 7.x or earlier.
  They do not properly emulate the required CPU features.

Next Steps

1. Reproduce the issue:
   Set up an environment with an affected CPU or a Proxmox 7.x (or earlier) virtual environment to confirm the error.
2. Assess the impact:
   Determine whether the number of affected users and the criticality of this issue justify the development effort for a fix.
3. Develop the fix:
   If deemed necessary, implement a fix by adjusting the compilation flags used when generating the official packages to ensure compatibility with x86-64-v1 CPUs.

Related forums

• Wazuh Slack channel - Jun 12th
• Fatal glibc error: CPU does not support x86-64-v2 using 4.8.0 image wazuh-kubernetes#719
  • Wazuh Slack channel - Jun 18th

Related issue with MySQL

• CPU does not support x86-64-v2 in the latest 8.4.0 docker-library/mysql#1055
• mysql8) Fatal glibc error: CPU does not support x86-64-v2

All these cases are related to Proxmox 7.x.

References

• Proxmox Roadmap

[crlsgms]

To workaround this issue without going to proxmox 8 change the cpu type on kubernetes node machines to host or Broadwell-noTSX

anyhow to use the 4.8.0 images the k8s nodes need to be rebooted to get the new cpu type.

just to register on this same array of hardware / proxmox wazuh 4.7.5 runs normally

[vikman90]

Update

I have attempted to reproduce this issue using a VirtualBox virtual machine with the following CPUID (basic functionality + SSE + SSE2):

Leaf	EAX	EBX	ECX	EDX
1	00000f12	00000000	00000000	3febfbff

.\VBoxManage.exe modifyvm debian_jammy_1718810405219_28512 --cpuidset 1 00000f12 00000000 00000000 3febfbff

Results

OS	Kernel	Result	Screenshot
CentOS 7	3.10.0-1160.95.1.el7.x86_64	❌ Kernel panic
Ubuntu 22.04	5.15.0-89-generic	❌ System hang

Neither of these kernels booted, which leads me to believe that the kernels used in these distributions for Kubernetes/Proxmox are modified.

Given that this issue has only been reported on virtualized systems with Proxmox 7.x, I propose associating the cause of the problem with this specific system. Therefore, I do not see the need to recompile Wazuh for older systems.

Workarounds

• Upgrade Proxmox to version 8 or higher.
• Change the CPU type to Broadwell-noTSX (thanks @crlsgms!).