Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Nieuwe AMD Ryzen-cpu's booten niet op nieuwe Linux-systemen
08-07-2019, 22:16 door Anoniem, 13 reacties
En iedere keer horen we dat Linux zo stabiel is. Alles werkt altijd perfect en zonder enige problemen. Opstart problemen zijn er nooit. Alle updates kan je altijd zo installeren.
Helaas zit de waarheid iets anders in elkaar, dan men hier altijd zo mooi voordoet.
Mooi voorbeeld hier: https://www.phoronix.com/scan.php?page=article&item=ryzen-3700x-3900x-linux&num=2
So what's the problem? On newer Linux distributions, there's a hard regression either within the kernel but more likely some cross-kernel/user-space interaction issue leaving newer Linux distributions unbootable.
While Ubuntu 18.04 LTS and older Linux distributions boot Zen 2, to date I have not been able to successfully boot the likes of Ubuntu 19.04, Manjaro Linux, and Fedora Workstation 31. On all newer Linux distributions I've tried on two different systems built around the Ryzen 7 3700X and Ryzen 9 3900X, each time early in the boot process as soon as trying to start systemd services, all systemd services fail to start.
I've confirmed with AMD they do have an open issue surrounding "5.0.9" (the stock kernel of Ubuntu 19.04) but as of writing hadn't shed any light into the issue. AMD has said their testing has been mostly focused on Ubuntu 18.04 given its LTS status. I've also confirmed the same behavior with some other Windows reviewers who occasionally dabble with Linux.
So unfortunately not being able to boot newer Linux distributions is a huge pain. I've spent days trying different BIOS versions/options, different kernel command line parameters, and other options to no avail.
Complicating this issue further is that when trying Linux 5.0/5.1/5.2 kernels on Ubuntu 18.04 LTS, they all booted up fine! Hence it doesn't appear to simply be a kernel regression but either some kernel+systemd interaction issue happening just on AMD Ryzen 3000 series processors or some awkward thing happening with the X570 chipset. When asking AMD again on the day prior to launch, they were still investigating the issue and apparently unsure of the root cause at this time.
Helaas zit de waarheid iets anders in elkaar, dan men hier altijd zo mooi voordoet.
Mooi voorbeeld hier: https://www.phoronix.com/scan.php?page=article&item=ryzen-3700x-3900x-linux&num=2
So what's the problem? On newer Linux distributions, there's a hard regression either within the kernel but more likely some cross-kernel/user-space interaction issue leaving newer Linux distributions unbootable.
While Ubuntu 18.04 LTS and older Linux distributions boot Zen 2, to date I have not been able to successfully boot the likes of Ubuntu 19.04, Manjaro Linux, and Fedora Workstation 31. On all newer Linux distributions I've tried on two different systems built around the Ryzen 7 3700X and Ryzen 9 3900X, each time early in the boot process as soon as trying to start systemd services, all systemd services fail to start.
I've confirmed with AMD they do have an open issue surrounding "5.0.9" (the stock kernel of Ubuntu 19.04) but as of writing hadn't shed any light into the issue. AMD has said their testing has been mostly focused on Ubuntu 18.04 given its LTS status. I've also confirmed the same behavior with some other Windows reviewers who occasionally dabble with Linux.
So unfortunately not being able to boot newer Linux distributions is a huge pain. I've spent days trying different BIOS versions/options, different kernel command line parameters, and other options to no avail.
Complicating this issue further is that when trying Linux 5.0/5.1/5.2 kernels on Ubuntu 18.04 LTS, they all booted up fine! Hence it doesn't appear to simply be a kernel regression but either some kernel+systemd interaction issue happening just on AMD Ryzen 3000 series processors or some awkward thing happening with the X570 chipset. When asking AMD again on the day prior to launch, they were still investigating the issue and apparently unsure of the root cause at this time.
Reacties (13)
13-07-2019, 21:05 door
OliverS
[Verwijderd door moderator]
13-07-2019, 21:07 door
OliverS
[Verwijderd door moderator]
Mooi onvolledig bericht weer van de TS.
Het probleem zat hem in de nieuwste bleeding edge releases, waarvan 1 (Fedora Workstation 31) nog niet eens gereleased was.
Daarnaast is het probleem vorige week al verholpen.
Wij noemen dit F.U.D.
Het probleem zat hem in de nieuwste bleeding edge releases, waarvan 1 (Fedora Workstation 31) nog niet eens gereleased was.
Daarnaast is het probleem vorige week al verholpen.
Wij noemen dit F.U.D.
Linux doet het prima op Ryzen.
Voor de duidelijkheid: Linux is de kernel. En kernel 5.0/5.1/5.2 in Ubuntu 18 LTS doet het prima. Het probleem zit dus niet in de kernel, anders zou Ubuntu 18.04 LTS met kernel 5.0 het ook niet doen.
Het probleem zit in Ubuntu 19.04, Manjaro en Fedora Workstation 31 dus NIET in Linux.
Voor de duidelijkheid: Linux is de kernel. En kernel 5.0/5.1/5.2 in Ubuntu 18 LTS doet het prima. Het probleem zit dus niet in de kernel, anders zou Ubuntu 18.04 LTS met kernel 5.0 het ook niet doen.
Het probleem zit in Ubuntu 19.04, Manjaro en Fedora Workstation 31 dus NIET in Linux.
Door Anoniem: Linux doet het prima op Ryzen.
Voor de duidelijkheid: Linux is de kernel. En kernel 5.0/5.1/5.2 in Ubuntu 18 LTS doet het prima. Het probleem zit dus niet in de kernel, anders zou Ubuntu 18.04 LTS met kernel 5.0 het ook niet doen.
Het probleem zit in Ubuntu 19.04, Manjaro en Fedora Workstation 31 dus NIET in Linux.
Wat maakt dit voor een eind gebruiker uit? Die heeft gewoon een probleem als hij dit wilt gebruiken.Voor de duidelijkheid: Linux is de kernel. En kernel 5.0/5.1/5.2 in Ubuntu 18 LTS doet het prima. Het probleem zit dus niet in de kernel, anders zou Ubuntu 18.04 LTS met kernel 5.0 het ook niet doen.
Het probleem zit in Ubuntu 19.04, Manjaro en Fedora Workstation 31 dus NIET in Linux.
Er is wel een probleem. De meeste distro's komen niet met 5.0 of hoger out of the box dus met installeren loop je tegen problemen op. Eergisteren ook Linux Mint met nomodeset moeten booten om te kunnen installeren en dan de 4.15 kernel te updaten naar 5.0.
Sjesus. Gelukkig staat dit niet op papier want het zou een melding van milieuverontreiniging waard zijn.
Natuurlijk gepost door een anoniem en doorgelaten door de redactie. En ik maar denken dat er gemodereerd wordt hier.
Natuurlijk gepost door een anoniem en doorgelaten door de redactie. En ik maar denken dat er gemodereerd wordt hier.
En wat heeft dit (tijdelijke probleem) met security te maken? Waarom wordt dit doorgelaten?
Wat blijkt: AMD heeft schoonheidsfoutjes gemaakt bij hun implementatie (en workaround voor een eerdere fix) van RdRand. Daardoor was de hardwarematige random number generation niet willekeurig genoeg, en werd output van RdRand (terecht) afgekeurd door systemd (jawel ;-) ).
AMD zou een microcode-fix hebben, welke in eerste instantie per BIOS-update naar eindgebruikers moet komen. Van dezelfde bron als het originele artikel:
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Releases-Linux-Zen2-Fix
AMD zou een microcode-fix hebben, welke in eerste instantie per BIOS-update naar eindgebruikers moet komen. Van dezelfde bron als het originele artikel:
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Releases-Linux-Zen2-Fix
Door Anoniem: Wat blijkt: AMD heeft schoonheidsfoutjes gemaakt bij hun implementatie (en workaround voor een eerdere fix) van RdRand. Daardoor was de hardwarematige random number generation niet willekeurig genoeg, en werd output van RdRand (terecht) afgekeurd door systemd (jawel ;-) ).
AMD zou een microcode-fix hebben, welke in eerste instantie per BIOS-update naar eindgebruikers moet komen. Van dezelfde bron als het originele artikel:
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Releases-Linux-Zen2-Fix
AMD zou een microcode-fix hebben, welke in eerste instantie per BIOS-update naar eindgebruikers moet komen. Van dezelfde bron als het originele artikel:
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Releases-Linux-Zen2-Fix
Mww - je samenvatting suggereert 'matige' random numbers . Feitelijk staat de RNG soms 'uit' (waarschijnlijk in relatie met suspend/resume) , terwijl de status vlag die moet zeggen 'call succesvol' toch 'succes' belooft .
De teruggelezen waarde is dan -1 .
Het probleem is iig wel heel duidelijk herkenbaar - een bug waarbij bv de randum numbers de output zouden zijn van een aes met een vaste of voorspelbare input zou extreem moeilijk detecteerbaar zijn.
Comment in de systemd fix/workaround:
/* Apparently on some AMD CPUs RDRAND will sometimes (after a suspend/resume cycle?) report success
* via the carry flag but nonetheless return the same fixed value -1 in all cases. This appears to be
* a bad bug in the CPU or firmware. Let's deal with that and work-around this by explicitly checking
* for this special value (and also 0, just to be sure) and filtering it out. This is a work-around
* only however and something AMD really should fix properly. The Linux kernel should probably work
* around this issue by turning off RDRAND altogether on those CPUs. See:
* https://github.com/systemd/systemd/issues/11810 */
Wat is eigenlijk de performance van de nieuwe AMD Ryzen processoren tegenover Intel i5/i7 onder Linux?
Ik heb twee situaties en advies nodig:
Situatie 1) Qubes OS desktop met 4 actief draaiende security domeinen. Welke hardware (cpu/mem) raden jullie aan?
Situatie 2) Arch Linux met Virtualboxen (2-3 OS systemen). Dezelfde vraag (cpu/mem)?
Het gaat in beide gevallen om normaal belastte OS instances, dus geen gaming, wel browsing, audio/video etc.
Extra vraag: welke optie zou jij kiezen voor een veilige en werkzame desktop omgeving (situatie 1 of 2) ? Ik ben niet van plan om elke week mijn core OS te updaten dus is Qubes misschien het beste? Aan de andere kant heeft een minimale Arch config met Xorg en Virtualbox een kleinere footprint. Lastig kiezen...
Ik heb twee situaties en advies nodig:
Situatie 1) Qubes OS desktop met 4 actief draaiende security domeinen. Welke hardware (cpu/mem) raden jullie aan?
Situatie 2) Arch Linux met Virtualboxen (2-3 OS systemen). Dezelfde vraag (cpu/mem)?
Het gaat in beide gevallen om normaal belastte OS instances, dus geen gaming, wel browsing, audio/video etc.
Extra vraag: welke optie zou jij kiezen voor een veilige en werkzame desktop omgeving (situatie 1 of 2) ? Ik ben niet van plan om elke week mijn core OS te updaten dus is Qubes misschien het beste? Aan de andere kant heeft een minimale Arch config met Xorg en Virtualbox een kleinere footprint. Lastig kiezen...
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
