Wel grappig dat juist 2 pakketten waarvan de auteurs altijd de grootste bek hebben op het gebied van "wij kunnen alles
veel beter dan anderen" de grootste problemen hebben als er iets onverwachts gebeurt :-)

systemd laat het systeem hangen in de boot (het zal eens een keer niet zo zijn!)
wireguard zogenaamd het beste VPN met de minste lines of code gaat ook al de mist in

Ik zou denken dat zo iets het best ergens gefixed kan worden in een routine die de random numbers genereert, in de
kernel of in een user proces wat die instructie wil gebruiken. Werkt ie niet gebruik dan wat anders.
Je kunt wel hopen op de installatie van een microcode update maar dat kan lang duren, dan is een kernel patch
vast sneller uitgerold.

Poettering is gewoon een arrogante lul en "useful idiot" voor red hat, niet een kundig codeschrijver.

Ik ken noch de auteur noch de interne aangelegenheden van wireguard, maar zo in het algemeen betekent "minder code" statistisch gezien "minder kans op ongelukken." Het is wel nieuwe code en crypto-aangelegenheden zijn notoir tricky.

Maargoed, als de linux-kernel-crew z'n job had gedaan dan was er een solide krand() die uit een pool leest die uit meerdere bronnen gevoed wordt. Dan is één vuile bron minder tot geen probleem. Een les die ze de vorige ronde ook al niet wilden leren, door de bestaande infrastructuur in z'n geheel door de (kennelijk vuile) intel cpurand te vervangen. (Dan is die van AMD eerlijker: Die geeft gewoon niets nuttigs terug. Die van intel lijkt dat wel te doen, maar is vervolgens dat vertrouwen niet waard.) Dus dan had hij gewoon die kunnen gebruiken.

Microcode kun je niet lezen. linux kernel patches wel. Meestal iig.

Er is al vele jaren /dev/(u)random dus is er vast ook wel een routine die in de kernel zelf kan worden aangeroepen.
Als je zo iets gebruikt kan er onder water een CPU instructie (mede) gebruikt worden en als die niet werkt worden overgeslagen.

Ik geloof het niet helemaal. Dat het een bug is. Ik bedoel, wat is de geloofwaardigheid van zo'n bug?

Ik kan de bug zelf niet aantonen, maar het verhaal klinkt mij te geloofwaardig om verzonnen te zijn.

Het gemene van falende random number generators is dat ze erg lang onontdekt kunnen blijven, maar dat bijv. (deels) daarop gebaseerde asymmetrische sleutelparen en Diffie-Hellman secrets, en daarmee encryptie en digitale handtekeningen, lang daarna eenvoudig kraakbaar kunnen blijken zijn (zie bijv. https://www.debian.org/security/2008/dsa-1571). In dit geval heeft OpenSSL er mogelijk geen last van, maar zou -naar verluidt- ASLR onder Windows en Linux aanzienlijk minder effectief kunnen zijn.

Tweaker "Uiltje" zat in juli kennelijk al op het juiste spoor, zie https://tweakers.net/nieuws/154896/amd-ryzen-3000-processors-werken-door-bug-niet-met-recente-linux-distributies.html?showReaction=13184812#r_13184812.

Overigens mijn excuses, het gaat om de RDRAND CPU-instructie (niet de eerder door mij genoemde RRAND).

Sorry, ik bedoelde dat niet. Wat ik bedoelde was eigenlijk dat de bug een beetje te fantastisch is. Wat ik bedoelde is dat het misschien gefabriceerd is. En wie / wat zou zo'n bug nou moedwillig introduceren? Denk na.

Misschien moet je zelf nadenken. En niet zo mysterieus emmeren moet "wie zou dat nou willen" .

Wil je een NSA/KGB/Chinees complot suggereren van een corrupte RDRAND rand ?
En die zouden dan hun geintroduceerde bug zo stom maken dat
1) meteeen te zien is dat de output niet random is
2) Linux (distro's) bij boot blijven hangen , en sommige games (Destiny 2) niet meer werken

Applaus hoor - scherp gedacht. Als je doel een backdoor is - en zeker één van het type "nobody but us" die er gebruik kan maken doe je dat echt niet zo.

De zorgen die je kunt hebben over de betrouwbaarheid van de RDRAND van de CPU gaan echt uit van veel subtielere bugs/backdoors, en beslist niet "de output is permanent 0xffffffff" .

Het is een nare fout, en slecht dat AMD dit in validatie gemist heeft, maar met wat programmeer kennis is het prima voorstelbaar hoe een heel kleine fout dit tot gevolg kan hebben.

Dat getal is echt helemaal random gekozen volgens deze methode: https://www.xkcd.com/221/

Als je iets gewoon met testen en reproduceren kunt vaststellen, dan begrijp ik de behoefte aan een geloof of geloofwaardigheid niet helemaal goed. Tenzij het vrijheid van meningsuiting aangesterkt met vrijheid van geloof betreft. Want daar mag je openlijk niet aan twijfelen. Dan neem ik mijn onbehoorlijke opmerking gelijk terug.

Anders, prik een processor in een experimenteerbord, en priegel die opcode er zelf eens in. Verstand, vakmanschap en kunde zijn namelijk allemaal dingetjes die je nergens gratis kunt downloaden of anderzijds lurken. Koop anders geen computer maar schaf een krultang aan met bluetooth. Want ik geloof dat die brandveilig zijn.

F, F, F, F, F... ? Die programmeertaal heet toch F+ ? ;-) Oh nee, wacht, het was F# !

Ik ben het eens met anoniem van gisteren 21:53, een stroom van waardes met alle bits één wordt onmiddellijk ontdekt (mits je kijkt, en dat hebben de testers van AMD duidelijk niet gedaan - ik vraag me dan meteen af wat ze nog meer over het hoofd hebben gezien).

Als je een backdoor in RDRAND zou willen maken, zou dat, vereenvoudigd, als volgt kunnen:
1) Neem na cold start/reset eenmalig 8 bits af van de echte CSPRNG, dat getal 0..255) noemen we X;
2) Bereken van X een hash met een functie naar keuze (met lengte >= 32 bit, bijv. CRC32) en bewaar het resultaat in X;
3) Geef als resultaat van de RDRAND functie de laatste 32 bits van X;
4) Ga naar 2).

Als "aanvaller" weet je dan dat er 256 verschillende reeksen van RDRAND outputs zijn die je, van tevoren kunt uitrekenen en opslaan in een opzoektabel. Een serieuze tester kan de voorspelbaarheid van RDRAND wel ontdekken, maar hoe meer bits er in stap 1 echt random zijn, hoe lastiger dat wordt (en hoe groter de tabel van de aanvaller).

Dat F, F, F, F... ontdekt moet worden doordat Linux niet meer boot, geeft te denken over met hoeveel vertrouwen wij CPU's in moederborden drukken en ervan uitgaan dat iemand anders wel gecontroleerd zal hebben dat zo'n ding aan de specs voldoet. De zorgen om backdoors in Huawei producten zijn, vermoed ik, terecht - maar net zo terecht als zorgen over backdoors (of onopzettelijke fouten) in producten van willekeurig welke andere fabrikant van complexe digitale onderdelen en/of apparatuur.

Wat een raar statement. Poettering is gewoon in dienst van Redhat, en als ze z'n code of keuzes niet waarderen kunnen ze 'm gewoon ontslaan. Het is niet dat ze 'm in dienst _moeten_ houden als een symbool, of als voormalig oprichter die een levenslang dienstverband bedong of dat soort redenen.

Hij _is_ een kundig codeschrijver - er zijn er die beter zijn, maar die zijn behoorlijk zeldzaam. (een stuk zeldzamer dan de mensen die _vinden_ dat ze goed zijn )
Arrogant is hij inderdaad wel - maar dat is niet zo'n unieke eigenschap onder ITers.

[..]

Wel pretenties over wie het fout doet, maar geen kennis van zaken. Kun je zo vinden als je even zoekt - het aardige van open source is dat je kunt zien wie wat deed - en eventueel fout deed.
De kernel RNG gebruikt meerdere bronnen - Ted Ts'o doet z'n job bijzonder goed.

Waar bazeer je je overigens op voor het statement dat de intel RDRAND het vertrouwen niet waard is ?

Het boot issue met systemd werd geintroduceerd omdat systemd (net als openssl) besloot om rdrand te gebruiken indien aanwezig op de CPU.

Fix van systemd (met commentaar in)
https://github.com/systemd/systemd/pull/12536/commits/1c53d4a070edbec8ad2d384ba0014d0eb6bae077


De kernel kan dit issue niet echt patchen. De kernel RNG gebruikt al meerdere bronnen. De kernel zou de 'heeft rdrand' vlag kunnen weghalen als ze dit issue zien, maar ook dat helpt alleen wanneer software de kernel cpu info gebruikt om te kijken welke features de cpu heeft. Software die zelf dat register evalueert zal gewoon rdrand gebruiken.

Er zegt toch niemand dat het moedwillig of gefabriceerd is? Het is gewoon een bug. Die kennelijk gemist is bij testen.
Dat gebeurt toch voortdurend bij het maken van software?
Of wist jij niet dat een CPU ook gewoon weer een programma draait wat de instructies uitvoert die jij hem geeft?
(dat heet microcode en daar kunnen gewoon ook weer bugs in zitten)

(21:53 weer hier. )
crypto uit de losse pols blijft tricky - een goede backdoored RNG is niet van buiten te herkennen.

Ook een fysische random-bron kan een bias hebben, of een niet-uniform spectrum, of sporen bevatten van voorspelbare signalen (50 Hz, of een klokfrequentie , e.d.) . Die worden in de bron, of in het samplen geintroduceerd.
Je moet zo'n signaal dus bewerken om daar geen probleem van te ondervinden.

Een simpel begrijpelijk voorbeeld : als je een munt wilt gebruiken met stevige bias (90% kop, 10% munt, maar wel random, bijvoorbeeld).
Met de Von Neumann multiplication trick kun je die toch gebruiken als een 50/50 random bron :

(simpele uitleg https://abcnews.go.com/Technology/WhosCounting/counting-crooked-coins-fair-probabilities-strange-sequences/story?id=12067023 )

Je gooit series van twee :

Bij Kop-Munt wint partij A
Bij Munt-Kop wint partij B

Bij Kop-Kop of Munt-Munt gooi je nog een serie van twee.

Dat werkt omdat de kans op Kop-Munt (0.9 * 0.1 ) net zo groot is als de kans op Munt-Kop (0.1 * 0.9 ).
Hier ruil je bandbreedte in voor entropie (het kost je minimaal twee worpen om één bit resultaat te krijgen ).

De RDRAND functies van (intel) CPUs worden gebruikt als input voor AES , en _die_ output wordt teruggegeven.

Als de input van AES gewoon een 32 bit teller is, is de output nog steeds niet van random te onderscheiden.

Het na-bewerken van een fysische random source om bias e.d. van sampling te verwijderen is volstrekt normaal en aanbevolen.
En helaas - als je dat goed doet kun je een niet van random onderscheidbare datastroom leveren zelfs met een backdoor- source.

zie https://www.electronicdesign.com/learning-resources/understanding-intels-ivy-bridge-random-number-generator
voor een review van het design van Intel's rdrand

Ik heb niet meteen een goede link van AMD's design. Dit lijkt een beschrijving:
https://crypto.stackexchange.com/questions/29894/amds-implementation-of-rdrand-instruction

Maar ook AMD zal een output check hebben, een de-biassing en een crypto output processing stage.

Vwbt de bug - die leek een relatie te hebben met suspend-resume .
Afgezien van kernel state moet bij suspend ook veel CPU powerdown's ook cpu state bewaard worden en later teruggezet, of opnieuw geinitialiseerd.
Het lijkt erop dat bij de AMD bug dat deel gemist is, of het zetten van de vlag 'rng is geinitialiseerd' onterecht gedaan wordt.

https://lore.kernel.org/linux-pm/776cb5c2d33e7fd0d2893904724c0e52b394f24a.1565817448.git.thomas.lendacky@amd.com lijkt te zeggen dat het mn een BIOS bug is , in de resume code .

Recente kernel discussies over de kernel RNG zijn boeiend - er zijn series apparaten zonder CPU hardware rng en met minimale IO en daarmee heel weinig manieren om random data te verzamelen . Maar die wel verwachten om extreem vroeg in het boot proces crypto-kwaliteit random data te krijgen (voor ssh keys, of certificaten e.d.).
Met komst van flashdrives zijn harddisken dubieus als bron van random bits. En "mensen die wat op een toetsenbord spelen" zijn ook niet altijd aangesloten - denk STBs, routers.
(harddisk gesample random bits zouden uiteindelijk afkomstig zijn van turbulentie rondom de leeskop )

Onze oosterburen hebben vaak goede inzichten over dit soort dingen.

https://www.heise.de/newsticker/meldung/Ryzen-3000-Niedrigere-Spannungen-im-Idle-zulasten-der-Schnelligkeit-4484365.html (31.07.2019)

Ik lees er echter ook dat het al sinds 2014 in AMD processors zit. Dus of die allemaal een nieuwe AGESA zullen krijgen?

Het best is dat software rekening houdt met kwetsbaarheden in hardware RNG's en data hiervan altijd mixt met een goede software RNG.

Er staat mij ook iets bij dat de bug alleen voorkomt als je de computer net aanzet of als die uit de slaapstand komt? In die periode geen RDRAND gebruiken lost het probleem dus ook op.

(was 21:53, en nog enkele postings die pending zijn).
knip - aanvulling op mijn eerdere antwoord - ik zag nu de AMD doc met beschrijving van hun RNG.

https://www.amd.com/system/files/TechDocs/amd-random-number-generator.pdf

Mijn indruk is dat het probleem aanwezig is (en blijft) na resume.
Ik denk niet dat "even wachten" een workaround is.

Dat die game een probleem heeft is ook een indicatie : dus na een volledige OS boot en start van de game is er nog steeds een probleem - dan is er toch al 'een tijdje' gewacht.

self-followup :

Ik schreef 'recente kernel discussies' omdat ik even geen zin had om URLs te zoeken.

Maar zie een hele serie posts met dit als start :

https://lkml.org/lkml/2019/9/10/369
https://lkml.org/lkml/2019/9/28/100

https://lkml.org/lkml/2019/10/15/1093

Heel interessant om te zien hoe dit probleem besproken wordt door de absolute top engineers.

Probleem werd gezien met GDM , omdat die vond crypto-kwaliteit random nodig te hebben voor MIT-MAGIC-COOKIE op een systeem waar dat vroeg in het bootproces nog niet aanwezig was.
(wegen geen, of disabled rdrand) . De druppel op de emmer waren ext4 changes die lezen meer efficient maken waardoor minder disk-access, waarder minder entropie bits uit de 'disk' bron - en entropie was al zo zeldzaam op dat systeem.

Cryptografie-specialist Schneier beveelt de PRNG genaamd Fortuna aan, omdat andere PRNG's te vaak niet deugen.
Zelfs ook als er een "ware random bron" aan ten grondslag ligt.
https://www.schneier.com/blog/archives/2019/10/a_broken_random.html

Behalve natuurlijk specialisten die van deze materie verstand hebben, die kunnen het wel lezen.
Microcode voor de processor wordt opgehaald uit de BIOS, en wordt bij het booten in de processor geschreven.
(hoewel het eventueel ook vanuit software zou kunnen (linux: "microcode package"),
maar de herstellende microcode moet geladen zijn voordat de functionaliteit van de processor waar iets aan mankeert
wordt gebruik!)
Daarom zit dus de oplossing van foute microcode meestal in het aanpassen van de BIOS,
hoewel men op moet passen met het doen van een reboot in multiple boot systemen.

Eigenlijk is microcode een relatief goedkope truuk om niet elke keer massaal alle processors te hoeven vervangen als er een probleem aan het licht komt. Behalve als er geen oplossing met microcode is te verzinnen die het probleem oplost.
Mocht dit gebeuren dan wordt meestal een nieuwe stepping voor de processor ontwikkeld, en moet de processor worden vervangen om het probleem op te lossen. (als het om een ernstig probleem gaat dat op geen andere manier is te omzeilen).


vr. gr.

Microcode bestaat al zolang als er microprocessors bestaan. En vroeger werd het ook gewoon gepubliceerd, zoals bv ooit voor de 8080. Zelfs ooit nog les in gehad op de HTS destijds. De assembly van de assembly, zogezegd. Het echte werk. C bestond nauwelijks nog destijds. Internet wel. En menig lezer dezes was nog niet groter dan één eicel.

Maar die microprocessoren hadden helemaal geen microcode as we know it today [1]. Dus ik weet eigenlijk niet waar je het over denkt te hebben als je zegt daar les in te hebben gehad.

[1]https://retrocomputing.stackexchange.com/questions/6656/how-was-microcode-implemented-in-retro-processors

Maar gelukkig kun jij het beter... Voor een useful idiot heeft hij iets geproduceerd dat miljoenen mensen dagelijks gebruiken, hoe zit dat met jou dat jij dit soort kritiek spuit?


Wat een klinkklare onzin. Je schrijft hier dat je een liever kapotte instructie hebt dan een instructie die werkt zoals gespecificeerd maar die volgens jou niet krachtig/veilig genoeg is. Op die manier heb ik nog een super veilige CPU voor je te koop die absoluut onkraakbaar is (want hij doet jet ook niet net als die AMD instructie).

Al met al lijk je een van die betweterige IT'er waarmee in de praktijk geen land te bezeilen valt omdat zijn ego niet door de deur past.

De manier waarop hij bereikt heeft dat "miljoenen mensen het gebruiken" die riekt nogal.
Het leek eerst alsof hij een alternatief zou aanbieden voor iets wat naar zijn idee niet meer goed werkte (en naar het
idee van miljoenen mensen prima voldeed) en vervolgens is hij begonnen om allerlei ongerelateerde pakketten afhankelijk
te maken van zijn pakket, waardoor het steeds moeilijker werd en uiteindelijk niet meer te doen was om zijn systemd
te omzeilen. Je hebt nu alleen nog wat niche distributies die zonder systemd werken.

En het gaat allemaal een kant op die we als Linux community helemaal niet willen, en altijd hebben neergezet als
meer de werkwijze van Microsoft. Dit topic is daar een goed voorbeeld van: het hele systeem sodemietert in elkaar
omdat het allesregelende systemd crasht door een onverwachte gebeurtenis. In de oude situatie zou er wellicht een
probleem zijn met een enkele service ergens, maar het systeem zelf zou gewoon zo ver booten dat je kunt inloggen
om te kijken wat er aan de hand is. Nu hangt gewoon de hele boel.

En als dit nou een incident was wat nu voor het eerst eens een keer gebeurt... maar nee, dit is al de zoveelste keer.
Ik probeer zelf systemd altijd zoveel mogelijk te vermijden maar op een gewoon werkstation kom je er al nauwelijks
meer omheen.

Systemd was nodig omdat het SysV boot proces een allegaartje van aan elkaar geknoopte shellscripts was dat niet goed overweg kon met service dependencies en praktisch iedere service sequentieel opstartte, resulterend in een traag bootproces en een hoop benodigde achtergrondkennis om services in de juiste volgorde af te sluiten en weer op te starten als er iets fout ging. Systemd heeft het bootproces van Linux desktops up to date gebracht zodat het nu kan concurreren met OS X en Windows terwijl het voorheen van inferieure kwaliteit was.


Spreek voor jezelf, ik ben langer dan 20 jaar lid van de Linux community en ben het niet met je eens.


De crash gebeurde vooral bij nieuwe systemen met een gloednieuwe CPU en BIOS, nieuwe technologie waar achteraf een fout in bleek te zitten, niet is systemd. De schuld van een fout van fabrikant A op producent B schuiven omdat die niet van tevoren op de fouten van fabrikant A weet te anticiperen is op zijn zachtst gezegd onredelijk.


Misschien is daar een andere, praktische reden voor dan samenzweringstheorieën betreffende de werelddominantieplannen van RedHat en Poettering (maw. distributeurs willen vanwege hun concurrentiepositie dat hun distro binnen seconden opstart en niet binnen minuten). Hoe dan ook hebben de SysV puristen de slag verloren en hier nog na jaren over doorzeuren werkt nogal contraproductief.

Als tig onafhankelijke distributies allemaal kiezen voor systemd zou je eens kunnen gaan denken dat systemd problemen oplost die door het klassieke alternatief niet opgelost worden.

Het was niet alleen zijn werkgever maar ook de concurrentie die overstapte. En echt niet omdat die door Redhat betaald werden om dat te doen.
Maar omdat hun klanten dezelfde problemen/omgevingen hebben als de Redhat klanten.

Misschien heb jij persoonlijk het soort problemen waar systemd een oplossing voor is niet ervaren.
Of ervaar je ze wel maar heb je niet door dat het een probleem is, omdat het altijd al zo ging.

En ja, het _is_ zwaar irritant als een decennium vingervaardigheid aangepast moet worden.


Bla bla. Zeker nooit een volle / of volle /var meegemaakt . Nog leuker als de junior moet ontdekken dat inodes ook een resource zijn die op kan, ook al is er genoeg ruimte.

Ik kan je wel vertellen - ook als oudgediend deel van de linux community - dat Linux als OS op cloudfarms daar nooit gezeten zou hebben als die 'old skool' beheerd werden : 1 admin per 50..100 machines, die het normaal vindt om een paar dagen hand werk te hebben aan het live brengen van een nieuwe machine. En waarbij het gewoon is dat andere hardware (paar NICs erbij) een reboot kost plus een admin die een stel init scripts en daemons checked.


Je kunt een paar dingen doen :

1)Als hobby bob lekker de niche distro blijven gebruiken
2)Met pensioen gaan (als je daar in de buurt zit) en zuur gaan emmeren op internet dat het allemaal zoveel slechter geworden is
3)Om je heen kijken, zien dat er wat dingen in IT land echt veranderd zijn en dat het OS daarin mee moet veranderen. En dan zuchten en eens wat nieuws gaan leren.

Om je op weg te helpen met wat er _echt anders_ is :

"servers" zijn niet meer bedoeld om uptime pik-lengte oorlogen mee te winnen. Ze worden opgespind waar nodig, en downgebracht als ze niet nodig zijn.
En "de" hardware configuratie is niet meer statisch. Storage wordt er dynamisch aangeplakt, interfaces kunnen gaan en komen (hotplug) , en zo meer.
Dat kan zo met VMs, en op nog kleinere (tijd)schaal met containers.

In de tijd dat server configuraties erg statisch waren en uptimes hoog voldeed SysV init. En ontelbare admins hebben zitten tweaken aan die scripten om kleine lokale dependencies (/usr/local komt van NFS . Fun .) in hun omgeving werkend te maken.

Snelle boot en de computer bekend maken met de hele set van dependencies is wat systemd beter doet.

Ik weet het wel. Machinetaal (assembly of firmware met bijbehorende hex-codes) werd door sommige bedrijven ooit ook wel "microcode" genoemd. Wat heb ik daar vroeger veel mee geknutseld zeg (en soms nog).
Ik hou van assembly omdat het je dicht bij de mogelijkheden van processor houdt, zodat je door goed gebruik te maken van alle functies en slimmigheden die de processor aan boord heeft super-efficiënte code kunt schrijven.
Dit is soms nodig om dingen op tijd voor elkaar te krijgen (of je neemt een krachtigere processsor voor iets meer geld)
Nadeel is dat het niet portable is.

Je hoèft natuurlijk helemaal niet te weten hoe een processor werkt om een programma te maken. Maar je kunt het wel vergelijken met tulpen. Ja, tulpen ja.

Ik leg het uit.

Je hebt bollenboeren en bloemschiksters,
Bloemschiksters hoeven niks te weten over de bollenteelt. Welke grond, wanneer ze de grond in moeten enzovoort.
Desalniettemin kunnen ze best mooie bloemstukjes maken.

Alleen die hangen wel plat na een week!

De meeste developers van vandaag zijn bloemschiksters.
Die hebben vaak niet eens interesse in bollenboeren.
Want kijk toch eens wat een beeldschoon biedemeier boeketje ze gemaakt hebben.

Een beetje weten wat er in een CPU allemaal gebeurt, dat is toch maar voor boeren.
Alleen wat met die kennis is gemaakt blijft veel langer dan een week goed. Alle jaren!
Dat is het verschil eigenlijk.