Debian 13 - Boot Meldung "RDSEED32 is broken"

  • Hallo Forum,

    ich habe gerade Debian 13.4.0 UEFI amd64 minimal vom SCP auf einem neuen RS1000 installiert.

    Der Server bootet auch problemlos, ich bekomme beim Booten aber eine Fehlermeldung:

    VPS.PNG

    Ich kann damit nicht ganz soviel anfangen und wollte mich erkundigen, ob jemand weiß was das genau bedeutet und das igrendwelchen Einfluss auf den Server und die Performance hat?

    Ich habe schonmal kurz rechechiert, und verschiedene Auskünfte gefunden - manche Sprechen von einem Bios Update was das behebt?
    Oder kann es daran liegen dass ich UEFI statt Bios gewählt habe?

    // Update zu UEFI/Bios - habe zum Testen mal die Debian Version mit Bios aufgespielt, dort kommt auch ein RDSEED32 Error:

    VPS2.PNG

    Würde mich über Hilfe freuen.

    Danke!

    3 Mal editiert, zuletzt von mango (12. April 2026 um 12:58)

  • Diese Meldung [0.084436] RDSEED32 is broken. Disabling teh corresponding CPUID bit ist kein kritischer Systemfehler – sie wird lediglich als Warnung ausgegeben.

    Der Linux-Kernel hat erkannt, dass deine CPU bzw. der RDSEED-Befehl fehlerhaft ist und entsprechende Funktionen deaktiviert.

    Abhilfe könnte aufgrund einer fehlerhaften Firmware der Befehl apt upgrade linux-firmware bringen.

  • Diese Meldung [0.084436] RDSEED32 is broken. Disabling teh corresponding CPUID bit ist kein kritischer Systemfehler – sie wird lediglich als Warnung ausgegeben.

    Der Linux-Kernel hat erkannt, dass deine CPU bzw. der RDSEED-Befehl fehlerhaft ist und entsprechende Funktionen deaktiviert.

    Abhilfe könnte aufgrund einer fehlerhaften Firmware der Befehl apt upgrade linux-firmware bringen.

    Okay, danke für die Antwort, dann ist das also kein kritisches Problem. Anscheinend kann bei virtualisierten CPUs RDSEED durch den Hypervisor falsch durchgereicht werden, aber da kann ich ja nichts machen. Oder?

    Wie willst Du auf einem VServer denn Firmware Updates einspielen?

    Und den Befehl "apt upgrade linux-firmware" habe ich gerade probiert, aber scheint nicht zu gehen.

  • Okay, danke für die Antwort, dann ist das also kein kritisches Problem. Anscheinend kann bei virtualisierten CPUs RDSEED durch den Hypervisor falsch durchgereicht werden, aber da kann ich ja nichts machen. Oder?

    Und den Befehl "apt upgrade linux-firmware" habe ich gerade probiert, aber scheint nicht zu gehen.

    Es gibt noch eine Alternative: Wenn der o.g. Befehl bei einer VM nicht funktioniert, so könnte auch der Kernelparameter rdseed=0 in der Datei grub zur Umgebungsvariable GRUB_CMDLINE_LINUX_DEFAULT hinzugefügt werden. Denn damit wird zwar das ursprüngliche Problem nicht gelöst, welches auf dem Hypervisor zu suchen ist, aber die o.g. Ausgabe wird während des Systemstarts zukünftig unterbunden.

  • Es gibt noch eine Alternative: Wenn der o.g. Befehl bei einer VM nicht funktioniert, so könnte auch der Kernelparameter rdseed=0 in der Datei grub zur Umgebungsvariable GRUB_CMDLINE_LINUX_DEFAULT hinzugefügt werden. Denn damit wird zwar das ursprüngliche Problem nicht gelöst, welches auf dem Hypervisor zu suchen ist, aber die o.g. Ausgabe wird während des Systemstarts zukünftig unterbunden.

    Okay verstehe, das wäre dann nur um die Meldung eben nicht mehr anzuzeigen.

    Ich habs gerade mal probiert und eingefügt bei GRUB_CMDLINE_LINUX_DEFAULT="quiet rdseed=0"
    Danach habe ich gemacht.

    sudo update-grub
    sudo reboot

    Seltsamerweise wird die Meldung immernoch beim Booten angezeigt.

    Ich weiß nicht ob ich das RDSEED überhaupt brauche, bin damit noch nie in Kontakt gekommen. Wenn ich ein Server aber neu aufsetze der lange Zeit halten soll, wollte ich halt alles richtig machen.

  • Ich habs gerade mal probiert und eingefügt bei GRUB_CMDLINE_LINUX_DEFAULT="quiet rdseed=0"
    Danach habe ich gemacht.

    sudo update-grub
    sudo reboot

    Seltsamerweise wird die Meldung immernoch beim Booten angezeigt.

    Und wie verhält sich deine VM, wenn du den Kernelparameter von der Reihenfolge wie folgt setzt?

    GRUB_CMDLINE_LINUX_DEFAULT="rdseed=0 quiet"

    und dann die VM mit dem Befehl poweroff herunterfährst und danach neu startest?

    Ich weiß nicht ob ich das RDSEED überhaupt brauche, bin damit noch nie in Kontakt gekommen.

    In einer VM emuliert der Hypervisor die Hardware. RDSEED ist eine echte CPU-Funktion des physischen Prozessors und VM´s haben keinen direkten Zugriff auf echte CPU-Features wie RDSEED.

    Was ist RDSEED? RDSEED ist eine CPU-Instruction, die vom Prozessor echte Zufallszahlen aus physikalischen Quellen erzeugt, anstatt pseudo-zufällige Zahlen zu berechnen.

    Wenn RDSEED auf dem Hypervisor defekt ist, können folgende Probleme für die VM entstehen:

    • Sicherheitsrisiko: Kryptografische Schlüssel könnten vorhersagbarer sein.
    • Performanceeinbußen: Der Kernel muss auf langsame Software-RNGs ausweichen.
    • Potenzielle Blockaden: Bei hoher Last kann /dev/random blockieren, wenn nicht genug Entropie verfügbar ist.
  • Ich bin noch nicht dazugekommen das mit den Kernelparamtern zu testen und hatten auch gehofft dass der Netcup Support mir Hilfe geben kann, da ist aber seit einer Woche Funkstille (leider).

    Zum Test habe ich aber mal Ubuntu 24.04.4 aufgespielt, hier wird mir der Fehler nicht angezeigt. Ich war halt bisher immer auf Debian unterwegs da nach meine Recher das am besten für VPS ist.

    Ich habe Grundkenntnisse in Linux und Severadministration, weiß jetzt aber nicht wie "kritisch" es ist wenn RDSEED nicht auf dem Server funktioniert und überlege ob ich diesen daher widerrufen soll. Wie groß könnte hierdurch ein Sicherheitsrisiko sein oder auch potentielle Anwendungen die ich auf dem Server laufen lasse?

    Einmal editiert, zuletzt von mango (20. April 2026 um 16:06)

  • https://bbs.archlinux.org/viewtopic.php?id=310214

    https://www.phoronix.com/news/AMD-Zen-5-More-RDSEED-ucode

    deepl Übersetzung:

    Zitat

    - Es wurde festgestellt, dass das RDSEED32-Register bei AMD-CPUs nicht so zufällig ist, wie es sein sollte.

    - Als Übergangslösung haben die Kernel-Entwickler die CPU vorerst so umkonfiguriert, dass der CPUID-Befehl den Programmen im Userspace mitteilt, dass sie RDSEED32 nicht verwenden sollen.

    - In der Zwischenzeit hat AMD ein Microcode-Update veröffentlicht, um RDSEED32 zu beheben. Der Fix wurde gerade erst in den Hauptzweig von `linux-firmware` aufgenommen.

    - Allerdings gab es für `linux-firmware` seit dem 14.11.2025 noch keine Upstream-Veröffentlichung. Sobald dies geschieht, wird es in...

  • Mach Dir nicht zu viele Sorgen. Es gibt einen Bug in der Firmware von AMD Zen 5 Prozessoren, der unter bestimmten Umstaenden dazu fuehrt, dass die RDSEED CPU-Instruktion den falschen Wert 0 liefert, aber per Statusbit behauptet, der Wert sei gueltig.

    Die Meldung, die Du siehst, besagt, dass Dein Kernel so eine Situation bemerkt hat, und das Featurebit fuer RDSEED in der CPUID abgeschaltet hat. Er stellt also einen sichereren Zustand fuer Dich her. Zufallszahlen koennen diese Prozessoren mit Hilfe der RDRAND-Instruktion trozdem erzeugen.

    Der Vollstaendigkeit halber: https://www.amd.com/en/resources/p…md-sb-7055.html

  • Mach Dir nicht zu viele Sorgen. Es gibt einen Bug in der Firmware von AMD Zen 5 Prozessoren, der unter bestimmten Umstaenden dazu fuehrt, dass die RDSEED CPU-Instruktion den falschen Wert 0 liefert, aber per Statusbit behauptet, der Wert sei gueltig.

    Die Meldung, die Du siehst, besagt, dass Dein Kernel so eine Situation bemerkt hat, und das Featurebit fuer RDSEED in der CPUID abgeschaltet hat. Er stellt also einen sichereren Zustand fuer Dich her. Zufallszahlen koennen diese Prozessoren mit Hilfe der RDRAND-Instruktion trozdem erzeugen.

    Der Vollstaendigkeit halber: https://www.amd.com/en/resources/p…md-sb-7055.html

    Okay prima, das heißt ich kann den Server problemlos nutzen, und ich habe, auch wenn der Bug weiter besteht, keine wirklichen Einschränkungen, da ich Zufallszahlen auch mit einer anderen Instruktion erzeugen kann?

    Wenn das dann gefixed wird, kann ich das aber vermutlich nicht selbst updaten, oder?

    Und kurze Frage wenn ich hier schon Experten habe, welches Debian 13.4.0 Image - Bios oder gleich mit UEFI?