Jason Donenfeld van De bekendheid van WireGuard, die de laatste tijd veel werk heeft gestoken in het verbeteren van de”willekeurige”kernelcode van Linux, heeft een voorstel gedaan om getrandom()-ondersteuning aan de vDSO toe te voegen voor betere prestaties bij het streven om beter in te spelen op de behoeften van ontwikkelaars van gebruikersruimte.
Tijdens het lezen van Phoronix ontdekte Jason Donenfeld dat de GNU C-bibliotheek de arc4random-functies heeft toegevoegd. Op zijn beurt begon Donenfeld een discussie op de Glibc-mailinglijst, omdat hij er verschillende meningen over had en vragen over het doel ervan.
Ik vraag me echt af of dit een goed idee is, of dit iets is dat glibc wil, en of het een ontwerp is dat de moeite waard is om op lange termijn aan vast te houden.
Ten eerste, voor welke gebruikssituaties helpt dit eigenlijk? Sinds recente wijzigingen aan de Linux-kernels–nu helemaal terug naar 4.9!–gerandom() en/dev/urandom zijn extreem snel en werken zonder slot per CPU. Natuurlijk vermijd je een syscall door dat in de gebruikersruimte te doen, maar maakt het echt uit? Wie heeft hier precies baat bij?
Zo bezien, lijkt het veel complexiteit voor niets, en complexiteit die uiteindelijk zal leiden tot bugs en verschillende onoplettendheid.
Bijvoorbeeld, de kernel herziet zichzelf wanneer virtuele machines forken met behulp van een identifier die via ACPI aan de kernel is doorgegeven. Het hervat zichzelf ook bij het hervatten van het systeem, zowel vanuit de gewone S3-slaap als, belangrijker nog, vanuit de slaapstand. En als arbiter van entropie is de kernel over het algemeen veel beter in staat om te bepalen wanneer het zinvol is om opnieuw te zaaien.
Glibc, aan de andere kant, kan wat heuristieken gebruiken en sommige beslissingen nemen–over fork, na 16 MiB, en dergelijke–maar in het algemeen ontbreken deze, vergeleken met het veel bredere scala aan informatie die de kernel
heeft.Je loopt dit mis met arc4random, en als die informatie in de toekomst op de een of andere manier naar de gebruikersruimte moet worden geëxporteerd, zou het erg leuk zijn om de gebruikersruimte-interface naast de kernel te ontwerpen.
Om die reden is de eerdere discussie over het genereren van willekeurige getallen in gebruikersruimte libcs erop gericht dit op de een of andere manier in de vDSO te doen, waar de kernel een essentieel onderdeel van die inspanning kan zijn.
Vanuit dit perspectief gezien, zou het meegaan met het oudere paradigma van OpenBSD nogal beperkend kunnen zijn. Waarom werken we niet samen, tussen de kernel en libc, om te zien of we iets beters kunnen bedenken, voordat we genoegen nemen met een interface met semantiek die later moeilijk terug te vinden is?
Zoals het is, is het moeilijk aan te bevelen dat iemand deze functies echt gebruikt. Blijf gewoon gerandom(2) gebruiken, dat meestal een gunstige semantiek heeft.
Ja, ik snap het: het is leuk om een generator voor willekeurige getallen te maken, en dus bedenken veel projecten een manier om ergens nog een te maken. Maar de neiging om dit te doen voelt als een rare computer-knutselziekte, eerder iets dat ooit het algehele ecosysteem heeft geholpen.
Dus ik vraag me af: wie heeft dit eigenlijk nodig en waarom? Hoe zien de prestatie-eis eruit en waarom is gerandom(2) onvoldoende? En is dit echt de beste aanpak? Als dit nodig is, wat zou je er dan van vinden om in plaats daarvan samen te werken aan een vDSO-aanpak? Of heeft misschien niemand dit überhaupt nodig?
En ten tweede, is er hoe dan ook dat glibc dit *niet* kan doen, of is dat schip volledig uitgevaren en heb ik echt gemist door geen deel uit te maken van die discussie wanneer het gebeurde?
Dat resulteerde in veel heen-en-weer discussies tussen Donenfeld en GNU toolchain-ontwikkelaars over hun prestatiebehoeften en wat leidde tot het werken aan de arc4random-functies voor Glibc die al lang beschikbaar waren op de BSD’s.
Om beter in te spelen op hun willekeurige prestatiebehoeften, heeft Donenfeld vandaag voorgesteld implementeren van gerandom() in de vDSO. De vDSO is natuurlijk de virtuele dynamische bibliotheek met gedeelde objecten die de kernel automatisch toewijst aan de adresruimte voor alle gebruikersruimtesoftware. Door gerandom() aan de vDSO toe te voegen, zou het mogelijk moeten zijn om de prestaties aanzienlijk te verhogen ten opzichte van de overhead van de systeemaanroep. Jason schreef in dat verzoek om commentaar:
Tot nu toe zijn in mijn testresultaten de prestaties behoorlijk fantastisch, en het lijkt te werken. Maar dit is heel, heel jonge, onvolwassen code, geschikt voor een RFC en niet meer, dus verwacht draken.
Zie de mailinglijst voor meer technische details indien geïnteresseerd.
Bovendien heeft Jason Donenfeld het arc4random-ontwerp vereenvoudigd tot de Glibc code en dat is al samengevoegd met Git. Deze ontwerpvereenvoudiging is voor een betere veiligheid met de nieuwe arc4random-functie door elke keer getrandom() aan te roepen in plaats van 16 MiB aan entropie in de gebruikersruimte te bufferen, dus er is voorlopig enige prestatieoverhead met deze vereenvoudiging.
