OpenBSD schakelt HyperThreading standaard uit bij Intel-processors

OpenBSD schakelt HyperThreading bij Intel-processors standaard uit vanwege de beveiligingsrisico's die hiermee gemoeid zouden zijn. Op termijn schrapt het besturingssysteem simultaneous multithreading bij alle processors.

Het ontwikkelteam denkt dat multithreading misbruik van meerdere Spectre-achtige bugs mogelijk maakt. "Implementaties voor simultaneous multithreading delen de translation look-aside-buffer en de L1-cache tussen threads. Dit kan cache-timingaanvallen vereenvoudigen", schrijft Mark Kettenis van OpenBSD.

Kettenis verwijst naar de verschillende varianten van Spectre-kwetsbaarheden die sinds eind vorig jaar aan het licht zijn gekomen. De mogelijkheid bestaat dat meer kwetsbaarheden aan het licht komen waarbij multithreading een rol speelt, als onderzoekers nieuwe sidechannelaanvallen vinden om de eigenschap uit te buiten dat meerdere stukken code op meerdere logische cores maar op een enkele fysieke core draaien en interactie met elkaar hebben.

Het beste zou volgens Kettenis zijn om geen verschillende beveiligingsdomeinen op verschillende threads op dezelfde core te draaien, maar om de scheduler van OpenBSD hiervoor aan te passen zou veel werk betekenen. Daarom is ervoor gekozen de HyperThreading standaard helemaal uit te schakelen. Gebruikers hebben de keuze deze instelling aan te passen via de hw.smt-sysctl-instelling.

Voorlopig is het uitschakelen dus alleen bij gebruik van Intel-processors in combinatie met de 64bit-versie van OpenBSD het geval. In de toekomst moet ook de multithreading bij processors van andere fabrikanten uitgezet worden. Kettenis wijst erop dat multithreading niet altijd snellere prestaties biedt, maar dat dit afhangt van de werklast. Die moet ervoor geoptimaliseerd zijn.

Reacties (99)

[EraYaN]

Voelt als een beetje een botte niet-echt oplossing, maar goed daar is het dan OpenBSD voor I guess?

[walteij]

Het is inderdaad een botte oplossing en daardoor juist wel een echte oplossing.
Daarvoor is het dus ook OpenBSD, niet voor niets het meest veilige OS dat er op de markt te vinden is. OpenBSD heeft als basis een zeer klein aanvalsoppervlak (er wordt alleen geinstalleerd wat écht nodig is). Als er de keuze is tussen gebruikersvriendelijkheid, performance of beveiliging, wordt er door de ontwikkellaars van OpenBSB altijd voor beveiliging gekozen.
Daarom nu dus ook het uitschakelen van Hyperthreading. Het kost mogelijk wat performance, maar je bent niet meer vatbaar voor Spectre-achtige lekken.

Hoewel ik me ook best nog kan voorstellen dat er een of meerdere OpenBSD ontwikkellaars zijn die de scheduler van openBSD toch nog onder handen willen nemen.

[Darkstriker]

Geen enkele van te tot nu toe gepresenteerde Spectre/Meltdown-achtige lekken had HT/SMT nodig. Uiteraard is het niet onmogelijk dat dit soort aanvallen worden gevonden, als je ALTIJD kies voor beveiliging, dat kan je je PC gewoon niet gebruikt. Ook de BSD devs maken een afweging. En hoewel ik wel kan zien hoe deze stap mogelijke problemen voorkomt, kun je je toch afvragen of ze hier wel de juiste afweging hebben gemaakt. Er zijn denk ik wel meer CPU features te bedenken die potentieel aanvallen in de hand kunnen werken (of er ook echt aanvallen mogelijk zijn is nog te bezien), maar die worden ook niet massaal uitgeschakeld door BSD. En het uitschakelen van HT/SMT heeft in veel scenario's wel aanzienlijke prestatiekosten (Vaak 25%, soms meer dan 50%). Weinig andere CPU features hebben dermate grote invloed op de prestaties van de CPU.

Anderzijds ben ik op vlak van software ontwikkeling ook geen expert en zou me dus persoonlijk gewoon bij hun besluit neerleggen als ik vanwege de beveiliging voor het (volgens jou) veiligste OS dat er is had gekozen.

[jurroen]

Het disablen van HT heeft niet te maken met spectre/meltdown maar tlbleed:

https://www.blackhat.com/...aches-is-not-enough-10149

[Darkstriker]

Dat is wel een ernstig lek zo uit de omschrijving. Ik ging in mijn posts af op degelijke journalistiek van tweakers (blijkbaar niet het geval) en begon daarom over Spectre/Meltdown.
Als je dat zo leest wil je haast HT op al je PCs uitzetten... Gelukkig is mijn desktop al een i5 zonder xD

[jurroen]

Op het moment dat dit nieuws bericht verscheen was dit nog niet duidelijk; net voor mijn voorgaande reactie is dit pas aangekondigd.

[Reactie gewijzigd door jurroen op 24 juli 2024 10:18]

[Cerberus_tm]

Bij wat voor taken zou je dan veel achteruitgang merken bij het uitschakelen van hyperthreading/SMT? Ook bij b.v. browsen met veel zwaren tabbladen open? Spellen? Of alleen bij heftige videobewerking?

[Darkstriker]

Van de dingen die jij noemt wordt alleen een deel van de games NIET getroffen door prestatieverschil. Moderne browsers gebruiken een groot aantal threads en profiteren stevig van HT (het verschil is echter vaak niet voelbaar omdat websites gevoeld meteen laden, maar dat neemt niet weg er stevig meetbaar snelheidsverschil is en bij zwaardere websites valt het ook gewoon op). Videobewerking sowieso, zoals je zelf al aangeeft. En ook steeds meer games profiteren van HT. Zeker bij laptops die het vaak nog met dual-cores met HT moeten doen.

OpenBSD is echter niet gericht op videobewerking nog gaming, dus dat is ook niet super relevant, maar veel server-taken hebben ook stevig baat bij HT omdat er honderden of duizenden verschillende threads lopen. Dat kan behoorlijk prestastieverlies in een core taak van OpenBSD opleveren.

Interessanter is de vraag, wie hier uiteindelijk aan het langere einde gaat trekken: de CPU-makers, die met "lakse" security-praktijken bij de implementaties van HT kosten besparen of prestatie ten kosten van beveiliging halen of de OS ontwikkelaars die proberen kosten te besparen door hun scheduler niet herschrijven om de door hun gevreesde aanvallen onmogelijk te maken.

[Cerberus_tm]

OK begrijpelijk allemaal. Het is ook wel een beetje een dilemma, veiligheid of snelheid. Maar deels kun je inderdaad ook veel veiligheid winnen met een beetje snelheidsverlies.

Overigens vroeg ik het als een beetje een terzijde, omdat ik me afvraag hoeveel baat je nu echt hebt bij 6 kernen / 12 draden (i7 of Ryzen) versus 6 kernen / 6 draden (i5). Ik ga namelijk binnenkort een nieuwe computer bouwen en was benieuwd naar hoeveel verschil je nu echt merkt bij genoemde taken.

[Reactie gewijzigd door Cerberus_tm op 24 juli 2024 10:18]

[Darkstriker]

Tja, je moet erbij natuurlijk rekening houden, dat hoe meer kernen je al hebt, hoe minder je het bij dagelijkse taken en games gaat voelen dat je HT hebt.

De meeste games en programma's maken grote, waarneembare stappen met HT op een dual-core en hebben vaak ook nog wel enigzins baat bij HT op een quadcore (wel erg beperkt, maar in sommige situaties wel voelbaar). Op een hexacore ga je er voor de meeste dingen die men als consument doet niks van merken. Voor veel games blijft single-core prestaties de limiterende factor en kun je dus betere een i5 met hogere snelheid dan een i7 met meer threads hebben. En belangrijker is natuurlijk, dat bij een game die fatsoenlijk geprogrammeerd is (en dus niet alleen een of twee cores gebruikt) de CPU van begin af aan al minder een bottleneck vormt en je dus in dat opzicht vaak beter af bent met een CPU met hogere kloksnelheden. Browsers en dergelijke kunnen wel wat prestatiewinst uit 12 ipv 6 threads halen, maar je zult het slechts minimaal waarnemen tenzij je honderden tabs gebruikt of in meerdere tabs tegelijkertijd zware webpaginas hebt, die ook in de achtergrond je PC belasten (erg onwaarschijnlijk). Ik zou daarom (zeker sinds de 6-core i5's hun entree hebben gemaakt) de i5 boven de i7 adviseren omdat voor dagelijkse taken het prijsverschil niet te rechtvaardigen is. Sterker nog, voor een game-build zou ik tegenwoordige eerder de i3-8350K (tenzij overclocken een no-go voor je is, in dat geval de i5-8600). Bij AMD is dat probleem niet echt aan de orde omdat ze altijd SMT hebben (vanaf de Ryzen 5). Punt is natuurlijk dat je een i3-8350K voor ongeveer hetzelfde geld in huis hebt als een R5-1500X (en als jet platform meerekent misschien zelfs een R5-1600X hexacore)

[Cerberus_tm]

A, okee, dat klinkt wel logisch. Ik heb af en toe wel honderd tabs open, maar daarvan is het grootste deel dan niet geladen (of hoe heet dat), dus niet actief. Ik merk op mijn huidige Core 2 Duo wel dat dat de browser langzamer maakt, maar ik betwijfel of dat de processor is. Dus dan zou 6 kernen wel genoeg moeten zijn.

Zo'n i3-8350K klinkt op zich wel interessant, maar de i5-8400 is slechts 9 euro duurder, en dan heb je 6 kernen in plaats van 4. Voor overklokken heb je weer een duurder moederbord nodig en hogere stroomkosten (en misschien slijt hij eerder?), dus daar twijfel ik een beetje over. Als deze processor nog 10 jaar mee moet (zoals mijn huidige) lijkt me 6 kernen misschien ook wat meer future proof?

Ryzen zit ik ook nog wel over te twijfelen. Maar dat is weer wat duurder dan de 8400 als je dezelfde kloksnelheid wilt halen, terwijl de Intel dan volgens mij nog een stukje beter presteert. Of je moet weer gaan overklokken, met ook weer wat nadelen. En misschien is het werkgeheugen duurder voor Ryzen. En je hebt geen geïntegreerde GPU, wat ook wel handig kan zijn, voor als ik b.v. het kopen van een videokaart nog even uitstel tot de prijzen genormaliseerd zijn.

[Reactie gewijzigd door Cerberus_tm op 24 juli 2024 10:18]

[Darkstriker]

Wat betreft de Core 2 Duo kan dat verschillende redenen hebben. Die CPU is natuurlijk al behoorlijk in de jaren gekomen en naast lagere prestaties per klok (in de meeste benchmarks zijn die inmiddels verdubbeld) en bovendien lagere kloksnelheden (hooguit rond de 3Ghz terwijl we nu op max 5Ghz zitten). RAM kan hier natuurlijk ook een rol in spelen eveneens als de HDD vs SSD vergelijking.

Als je tien jaar met je PC wilt doen kun je idd beter voor meer cores gaan en de 8350K is echt alleen als je nu maximale game-prestaties voor minimaal geld wilt halen en beetje game-future-proof door het behoorlijke OC-potentiaal dat er in die CPU zit mocht je later toch nog meer prestaties nodig hebben. Maar 6 ipv 4 cores is natuurlijk wat dat betreft de betere keuze voor een allrounder.

Als je dan voor AMD gaat lever je natuurlijk iets in op de single-thread pretaties, maar de Ryzen 5 1600X (die even veel kost als de i5-8400) zit ook op 4Ghz boost (net als de Intel). De per-core prestaties zijn inderdaad nog aardig wat lager, maar daar staat dan weer SMT tegenover. Dat maakt een behoorlijk verschil en terwijl de AMD dus tot 25% langzamer is (in de meest extreme gevallen) in single-core prestaties is ie anderzijds ook weer tot 25% sneller in multi-threads. Tergelijkertijd kun je ook kiezen voor de Ryzen 5 2600 (voor 5€ meer), die in beide opzichten toch weer 5 tot 10% sneller is dan de 1600X. En dat laatste gaat natuurlijk over de komende 10 jaar alleenmaar zwaarder wegen. En moederborden voor Ryzen zijn (bij vergelijkbare uitrusting) doorgaans goedkoper. Wat geheugen betreft heeft zijn de kinderziektes bij de AMDs inmiddels weggewerkt en hoef je eigenlijk geen zorgen om compatibilteit meer te maken. En als je dan toch (bijvoorbeeld het prijsverschil in moederbord) extra in het geheugen investeert, dan verbeter je allicht de prestaties ietjes. Maar tweakers concludeerde vorig jaar dat het verschil redelijk klein is dus dat is niet noodzakelijk een verstandige zet nu.

In hoeverre je de GPU nodig hebt is natuurlijk aan jou. En of de GPU markt weer "normaliseert" binnen afzienbare tijd is maar de vraag. Bij geen van beide fabrikanten lijkt in de nabije toekomst een noemenswaardige prestatieboost in het verschiet te liggen (nVidia gaf laatst aan dat de volgende generatie nog ver weg is) en de cryptomarkt is verre van aan het afkoelen. Als je mij vraagt is ie "here to stay" en het enige wat afbreuk zou kunnen doen aan de daardoor gestegen GPU prijzen is als de fabrikanten GPUs uitbrengen die voor mining minder geschikt zijn dan huidige modellen (lijkt me onwaarschijnlijk) en al doen ze dat zullen ze alsnog een groot deel van de chipproductie voor die oude modellen laten draaien om aan die vraag te kunnen voldoen. Je kunt die aanschaf dus uitstellen, maar of je daar echt veel mee wint is op zn best dubieus. Voor een AMD of nVidia maakt het uiteindelijk niet uit of hun GPUs in mining-rigs of in game-pcs draaien. Het enige wat dit echt zou kunnen verstoren zouden ASICs zijn die vele malen beter presteren dan GPUs (en hoewel daar in het begin een grote belofte werden gemaakt blijkt het toch veel moeilijker dan de hype-bedrijven aanvankelijk dachten). Ik zou dus niet erop rekenen dat de prestatie per euro situatie in de GPU markt binnen de komende twee jaar echt enorm verandert. Het enige verschil gaat uit de nieuwe generaties (en daarmee hopelijk gepaarde prestatiewinst) komen, wat mogelijk over ongeveer een jaar plaatsvind voor AMD, maar als je op die manier redeneert kun je altijd blijven wachten op de volgende generatie.

Het enige waar het misschien loont op te wachten (omdat het echt op kort termijn zou kunnen gebeuren) zijn potentiële 8-core core i5's uit een mogelijke Coffee Lake Refresh. Het is echter zeer de vraag of die dan niet of veel duurder worden dan de CPUs op die je mikt en er blijft natuurlijk de kans dat het gewoon 6-cores blijken te zijn. Of ze noemenswaardig druk uitoefenen uitoefenen op de prijs van de bestaande CPUs in het sub-200€ segment is ook verre van zeker. Ik denk eigenlijk niet dat Intel alle i5s tot 8-cores gaat maken (als uberhaupt 8-core i5s komen) en dat er eerder iets komt dat het gat tussen de 8600K en de i7s gaat sluiten.

[Cerberus_tm]

De meeste dingen die je zegt ben ik het wel mee eens, klinkt logisch allemaal. Ik ben blij zo'n rationele beschouwing te lezen. En dank voor alle handige links.

De 1600x is iets duurder dan de 8400 omdat je er nog een koeler bij moet kopen, maar verschilt inderdaad niet veel. De 2600 heeft toch een lagere kloksnelheid dan de 1600X? Dan zou ik toch verwachten dat die op 1 kern best wel slechter presteert dan de 8400?

Wat betreft de prijzen van micro-ATX-moederborden met M.2 lijkt het erop dat Intel en AMD even duur zijn als je wilt overklokken met AMD (chipset B350) (en niet wilt overklokken met Intel), als ik het goed begrijp. Beide zijn te koop vanaf ca. €60:
categorie: Moederborden
categorie: Moederborden
Als je niet wilt overklokken met AMD kun je €10 besparen (maar dat is dan wel echt zonde, lijkt mij!). Maar de potentiële overklokbaarheid is wel een bonuspunt voor AMD.

Goed om te weten dat het effect van geheugen wel meevalt. Toch zag ik hier en daar wel een verschil van 10% en zelfs 20% in die test van Tweakers, dus misschien is dat een beetje onvoorspelbaar?
https://i.imgur.com/uBaPgLp.png

Wat betreft videokaarten heb je waarschijnlijk gelijk. Misschien koop ik toch een instapper of tweedehands, en kijk ik over 2+ jaar verder. Toch is een geïntegreerde GPU altijd handig voor je weet nooit; als je b.v. problemen hebt met je videokaart, dan kun je de IGPU ten minste nog gebruiken.

Die 8-kernige i5 klinkt op zich wel interessant, maar inderdaad zal die vast duurder worden en weinig druk uitoefenen op de 6-kernige – als hij überhaupt komt. Ik heb wel genoeg gewacht!

P.S. Het enige waar ik nog benieuwd naar ben is het effect van Spectre en Meltdown op de prestaties van NVME. Ik heb gehoord dat die een flink negatief effect kunnen hebben bij Intel, maar ik kan nergens goede vergelijkingen vinden, ook omdat de meeste sites er niet bij zetten of hun tests van de 8400 met of zonder de patches zijn.

[Reactie gewijzigd door Cerberus_tm op 24 juli 2024 10:18]

[Darkstriker]

De 2600 is inderdaad ietsjes lager geklokt, maar hij heeft wel een boost qua IPC dus hij is net een tikje sneller dan de 1600X ondanks de lagere klok (in benchmarks). Bovendien biedt de lagere klok uiteindelijk ook weer meer ruimte bij een mogelijke overklok.

Wat ik bedoelde bij moederborden was niet zozeer dat de AMDs goedkoper beginnen (ik zou sowieso aanraden om voor een moederbord met 4 geheugenplaatsen te gaan ipv de ulta-budget met 2. Daar krijg je later alleen spijt van. Had ik laatst ook!). Het punt is meer wanneer je vergelijkbaar geprijsde moederborden vergelijkt zijn de AMDs (bijna altijd) beter uitgerust. Kijk bijvoorbeeld naar deze vergelijking. Dat zijn de twee goedkoopste Intel board met 4x geheugen en de goedkoopste AMD en een AMD die vergelijkbaar is geprijsd met de Intels (die immers 10€ duurder beginnen).
Noemenswaardige verschillen:
- De AMDs kunnen twee videokaarten hebben (2x PCI-e x16 slots), de Intels niet (kan als je 10 jaar zonder basisverandering in je systeem wilt leven best een uitkomst zijn)
- De vergelijkbaar geprijsde AMD heeft USB 3.1 Gen2 (10Gbps) terwijl alle anderen het met USB 3.1 Gen1 (oftewel 5Gbps en eigenlijk USB 3.0) moeten doen. Bovendien heeft ie 8 ipv 6 USB3 poorten.

Natuurlijk kun je weer voor een paar euro meer een Intel krijgen die dat ook heeft, maar het punt wordt er niet minder om.

TL:DR pak een bord met 4 geheugenslots. Van 2 kun je op lange termijn erg spijt krijgen en het prijsverschil is gering.

Wat betreft NVME en Spectre kan ik geen definitive uitspraken doen. Het lijkt erop dat men online aardig verdeeld is. Een echt recente, goed uitgevoerde test kan ik niet vinden. Intel heeft uiteraard gepubliceert met benchmarks waar de tendens is dat de impact beperkt blijft, maar er zijn ook tests waar het prestatieverschil oploopt tot 50%(!). Hoe dan ook is de snelheid van NVME SSDs in eigenlijk geen enkel gebruiksscenario voor een consument echt de bottleneck, dus super druk zou ik me er niet om maken. Anderzijds investeer je natuurlijk bij een NVME SSD behoorlijk extra (tov SATA) wat betreft prijs/GB en dan wil je er natuurlijk ook het maximale uithalen. Dat is zeker een voordeel voor AMD. De kwestie is, of Intel het op termijn niet voor elkaar krijgen (of wellicht al voor elkaar heeft gekregen) om een deel van die prestatieverlies te herstellen met beter geoptimaliseerde fixes. Er was in het begin veel paniek om de prestatieverschillen, maar dat waren natuurlijk super snel in elkaar gezetten patches omdat het lek zo ernstig was. Het lijkt er niet op dat er hierop echt een bevredigend antwoord te vinden is. Zekere voor het onzeker moet je op dit terrein een AMD nemen. Maar er is wel een kans dat Intel dit deels herstelt.

Wat betreft de online tests van de 8400 zou ik verwachten dat die (bijna) allemaal zonder de spectre patches zijn uitgevoerd omdat de 8400 lang voor spectre uitkwam. Tegelijkertijd kun je wat dat betreft wel gewoon houvast hebben aan benchmarks op andere Intels van Skylake of nieuwer omdat lek en fix hetzelfde zijn.

[ejabberd]

Ik vermoed dat men ook Intel e.a. wil aanzetten om meer in te zetten op veiligheid van hun toekomstige chips.

[Verwijderd]

het meest veilige OS dat er op de markt te vinden is

Je noemt zelf ook het zeer kleine aanvalsoppervlak (alleen installeren wat echt nodig is)
Maar je kan ook zeggen: zeer klein aanvalsoppervlak (nauwelijks in gebruik wereldwijd)
En in het kader van dat laatste is een OS al inherent veilig.
Of het OS ook daadwerkelijk zo veilig is (heel oud OS, weinig devs) vraag ik me altijd af.
Uiteraard is het speerpunt beveiliging en uiteraard zal hierom het OS op veel zaken veilig zijn.
Aan de andere kant is er dat oude OS met weinig aandacht / ontwikkelaars.

[batjes]

Een klein aanvalsoppervlak is niet inherent aan een veilig OS. OpenBSD is juist een buitenbeentje in de OS wereld.

Waar Linux security ook zeker wel serieus neemt, Windows ook sinds Vista... Is de opzet niet hetzelfde als bij OpenBSD. Bij OpenBSD staat security eenzaam op nummer 1. Het is ook niet voor niets al een paar decenia het meest veilige en stabiele OS wat ik ooit gekend heb. (Ik heb echt machtig veel respect voor OpenBSD). Een jaar of 10-15 geleden was destijds het systeem met de grootste e-penis/uptime ook een OpenBSD, de teller stond destijds al op een jaar of 10, dat terwijl ik met mijn Windows nauwelijks voorbij de week kwam en mijn Debian record ook slechts op 2 jaar stond. Paar jaar geleden dit nog eens terug proberen te vinden, maar nooit meer gevonden helaas.

Bij Windows en ook Linux staan usability nog erg hoog in het vaandel, het OS moet in zo veel mogelijk scenario's bruikbaar zijn. Je hoeft ook niet helemaal te weten wat je doet om de bende op te kunnen zetten. Bij OpenBSD is usability echt bijzaak, volgens mij is het ondertussen onderdeel van geworden, maar zelfs tabcompletion op de CLI moest je vroeger apart installeren (de debian-tools).

Men neemt hier ook voorzorgsmaatregelen zoals dit nieuwsbericht. Als het risico bestaat dat iets geexploit kan worden, OpenBSD kan dit voorkomen, dan wordt de keuze gemaakt om dit te voorkomen. En niet eventueel achteraf te gaan lopen patchen als het toch security gatenkaas blijkt te zijn.

Ook wordt bij OpenBSD de bende vele malen beter gepeerreviewed en onderhouden dan de Linux distros of zelfs Windows. Een stukje code komt daar het systeem niet op als niet tenminste tig mensen het nagepluist hebben. Bij Linux en Windows wordt er door de developers nog veel gewerkt op basis van vertrouwen. Men vertrouwt wel dat X of Y die al wat aan reputatie heeft opgebouwd, zijn shit wel prima voor elkaar heeft. Bij OpenBSD is dit er niet. Er wordt nergens op vertrouwt behalve door de eindgebruiker.

OpenBSD wordt niet actief ontwikkeld met weinig aandacht? https://github.com/openbsd/src/commits/master

OpenBSD is misschien wel groter in de PC wereld dan Apple. Echt veel -kritieke- systemen op de wereld draaien OpenBSD en geen Windows of *nix.

[Verwijderd]

Bij Windows en ook Linux staan usability nog erg hoog in het vaandel, het OS moet in zo veel mogelijk scenario's bruikbaar zijn.

Dat is ook geen verkeerde insteek he. OpenBSD heeft een ander doelpubliek dan Linux. Hoewel Linux al maar vaker voorkomt daar waar ik OpenBSD zou verwachten (space, .mil, spionage & security, vlieg industrie). Vermoedelijk omdat Linux in industriële toepassingen toch populairder blijkt, en die industriële zaken (cnc, robotica, etc) al snel in .mil, vliegtuig en space terecht komen.

(De) Linux (community) zie ik als de jongere bende die iets heel erg cool willen maken. De OpenBSD groep zie ik als de wat oudere garde die iets heel erg stabiel, veilig en betrouwbaar willen maken. En de twee eilanden delen best wel veel softwareoplossingen met elkaar, ook. Want bijna alles is toch open source en het is maar een kwestie van wat heen en weer te porten en afspraken i.v.m. POSIX te maken (d.i. ten slotte waar de POSIX standaarden voor bedoeld zijn).

Ach weet je. Zolang we er ooit maar mee naar de ruimte kunnen. Daar dient het uiteindelijk allemaal voor.

[batjes]

De doelgroep van OpenBSD en Linux is best vergelijkbaar. Maar binnen die doelgroeppen heb je ook verschillende eisen. Je zet hetgeen in waar het het beste voor is. OpenBSD heeft ook zijn nadelen, in veel gevallen kan het ook Linux niet fatsoenlijk vervangen.

Je ziet OpenBSD erbuiten ook nog wel, op veel meer plekken dan je verwacht. Je merkt het alleen niet, want die systemen zijn niet stuk te krijgen tenzij hardware failure. En goede kwaliteit hardware blijft tig jaar draaien als het de eerste maanden niet onderuit klapt.

Verder wel mooie vergelijking De wijze oude man versus de rebellende jeugd.

[SpiceWorm]

"(space, .mil, spionage & security, vlieg industrie)"

Wat voor werk doe je als ik vragen mag? Wel bijzonder dat je op zoveel verschillende high-stake plekken komt.

[Verwijderd]

Ik werk momenteel aan software voor CNC machines, wij ontwikkelen met als target een Linux gebaseerde omgeving. Ik ken iemand die OpenBSD kernel ontwikkelaar is die oa. voor FN Herstal wel eens wat dingen gedaan/gemaakt heeft (dat is .mil neem ik aan?) en in Zaventem zijn er enkele mensen die ik dan wel niet noodzakelijk persoonlijk ken, maar waarvan ik wel weet dat ze software schrijven voor zaken die in space rondvliegen. Ik heb naturlijk ook oren, ogen en verstand genoeg om uit een E-mail van een typische recruiter die op zoek is naar een Linux embedded C/C++ ontwikkelaar te distilleren of het voor één van de bedrijven is dat zich in die sectoren bezig houdt. De welke dat zijn, zijn ook nogal gekend onder de specialisten (bv. software voor vliegtuigsimulatoren, software van helmen voor F-16 piloten, software om gruwelijk accurate spiegels aan te sturen in de ruimte zal wel voor surveillance zijn, en zo verder - ik zal de oefening aan jou overlaten om de namen van de bedrijven en hun locatie te vinden).

Wat spionage en security betreft zijn er lekken genoeg (oa. van Edward Snowden, maar ook die Vault7) waaruit je met het grootste gemak kan opmaken dat ze daar nogal graag oa. Linux gebruiken.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 10:18]

[Darkstar]

Een jaar of 10-15 geleden was destijds het systeem met de grootste e-penis/uptime ook een OpenBSD, de teller stond destijds al op een jaar of 10, dat terwijl ik met mijn Windows nauwelijks voorbij de week kwam en mijn Debian record ook slechts op 2 jaar stond. Paar jaar geleden dit nog eens terug proberen te vinden, maar nooit meer gevonden helaas.

Een beetje off-topic, maar ik vroeg me inderdaad af of er nog "nieuwe" van dergelijke verhalen zijn.
Schijnbaar is een Netware server met dik 16 jaar uptime nog een "recent" voorbeeld.
Dit FreeBSD systeem (via Reddit) draait al een jaartje of 12 mee. Impressive stuff toch wel.
Via dezelfde subreddit ook een Cisco routertje dat al een dikke 21 jaar uptime heeft

[Verwijderd]

Een klein aanvalsoppervlak is niet inherent aan een veilig OS

En geen onderbouwing.
Ik zal je mijn onderbouwing geven waarom ik wel van mening ben dat een klein aanvalsoppervlak wel inherent is aan een veilig OS.
Het aantal gebruikte systemen wereldwijd aangesloten op het internet die openBSD draaien is nihil in vergelijking met Linux en Windows. Dat heeft tot gevolg dat er percentueel (veel) minder machines zijn die openBSD draaien EN DUS de kans op aanval kleiner is. De kans is namelijk vele malen groter als een doel een Linux of Windows host is. Niet alleen t.a.v. het aandeel openBSD machines maar vooral ook vanwege het aandeel exploits en aanvallen die al bekend zijn, logischerwijs in veel mindere mate aanwezig zullen zijn voor een OS met maar een fractie van het totale aandeel besturingsystemen vertegenwoordigd wereldwijd.

Datzelfde is ook het geval met het aantal ontwikkelaars voor openBSD t.a.v. de controle en kwaliteit van dit OS.
Kunnen wel veel commits zijn, het is een druppel op een gloeiende plaat t.o.v. Linux of een commerciele Windows. Waarmee ik niet wil zeggen uiteraard dat de mensen DIE er aan werken heel kundig zijn. Maar dat is nou net niet mijn punt.

[ds65ag5g5as78a]

is het meest veilige OS niet qubes?

[walteij]

Nee, Qubes is een van de veiligere Linux distributies. OpenBSD is een complete ander OS, dat geen gebruik maakt van de Linux kernel (waar Qubes dat wel doet).

[jurroen]

Qubes is géén Linux distributie; de basis is Xen. Het maakt wel gebruik van Linux VMs (Fedora en Debian).

Qubes is iets heel anders dan OpenBSD. Beiden hebben ze security als primaire focus; de werkwijze is compleet verschillend. Qubes is security door isolatie/segmentatie, OpenBSD is security door 'hardening'.

[walteij]

Dan is QUbes dus een Hypervisor implementatie, net zoals VMware of Hyper-V, de zwakheid van Qubes zit dus in het 'onderliggende OS', wat Xen is.

En van welke kernel maakt Xen gebruik? Jawel, een (aangepaste) Linux kernel.

[EraYaN]

Daarom nu dus ook het uitschakelen van Hyperthreading. Het kost mogelijk wat performance, maar je bent niet meer vatbaar voor Spectre-achtige lekken.

Dat is dan weer niet correct. Het wordt iets moeilijker, maar zeker niet onmogelijk. Al die fijne 100% statements altijd. Zo werkt het helaas niet.

[Stoelpoot]

Hoewel ik me ook best nog kan voorstellen dat er een of meerdere OpenBSD ontwikkellaars zijn die de scheduler van openBSD toch nog onder handen willen nemen.

Dat zal vast. Zou alleen te lang geduurd hebben dan wenselijk, dus nu eerst uit. Daarna kan er verder worden gekeken.

[PhantomPotato]

SMT heeft weinig met speculative execution te maken, wat dus de boosdoener was bij Spectre en Meltdown. Naar mijn huidige kennis zijn er nog geen kwetsbaarheden gevonden in Intel's SMT implementatie en als je naar de design kijkt is er ook niks soortgelijks mogelijk via SMT als met Spectre.
De taken zitten bij SMT in andere "threads", maar er wordt altijd maar een thread tegelijk uitgevoerd.
Er is in goede kans dat SMT daarom zelfs veiliger werkt dan daadwerkelijk meerdere cores, omdat die wel simultaan hun eigen data verwerken en bijhouden die potentieel kan worden vergaard.
Waarom zetten ze niet gewoon multi-threading uit in het algemeen? Ik vind het een beetje krom.
Tenzij zij iets weten wat ik weer niet weet via de hardware fabrikant en is dit hun reactie vind ik dit geen goede actie.

[GHorsie]

Daarvoor is het dus ook OpenBSD, niet voor niets het meest veilige OS dat er op de markt te vinden is.

Volgens mij is OpenVMS nog steeds het meest veilige OS

( zie ook https://nl.m.wikipedia.org/wiki/OpenBSD : OpenBSD staat bekend als het veiligste besturingssysteem na OpenVMS. )

[Verwijderd]

OpenBSD is niet een OS voor hippe dingen. Het is al decennia een OS voor uiterst stabiele en kritische dingen.

Wie hippe dingen wil, kan Linux gebruiken. Of zelfs Windows.

Daarbij kan je het terug opzetten ook, die hyperthreading. Eigenlijk zou de Linux kernel ook OpenBSD's voorbeeld moeten volgen.

Dat de hardware jongens hun problemen eens zelf oplossen, zonder de kernel jongens lastig te vallen.

m.a.w. Moet Intel maar is gaan nadenken over hoe ze dit in de toekomst gaan vermijden.

[MSalters]

Uiteindelijk is het het OS wat bepaalt welke cores welke instructies uitvoeren. Het OS heeft ook het overzicht welke instructies bij welk programma horen. De CPU weet dat niet. Een CPU heeft al helemaal geen idee van gebruikers. Dat concept bestaat puur op OS-nivo.

Ik snap OpenBSD hier dan ook niet. Twee threads van hetzelfde programma kunnen toch al bij elkaars data. Die twee threads kun je dus zonder enig veiligheidsrisico op dezelfde hardware-core draaien. Het enige wat je niet moet doen is twee threads van twee verschillende programma's tegelijk op dezelfde fysieke core draaien, ook al staat HyperThreading dat toe.

Nee, ik zie veel meer in een andere maatregel: wijs (fysieke) cores semi-permanent toe aan programma's. Indien je een core tussen programma's switched, reset dan de hele CPU cache en branch predictor. Ja, dat kost tijd, vandaar dat je die toewijzing niet elke milliseconde moet wijzigen.

[Verwijderd]

In "simultaneous multithreading bij HyperThreading" staat "Thread" niet helemaal voor hetzelfde als wat pthread_create() maakt. Wat jij bedoelt of lijkt te bedoelen zijn POSIX threads (op Windows is dat CreateThread, maar daar noemt het uiteraard niet POSIX-thread) is een speciaal type process dat het process-geheugen deelt met het process dat de POSIX thread heeft aangemaakt.

Typisch op een UNIX is dat uitgewerkt door enkel clone() te doen ipv fork() wat na clone() een copy-on-write copy van het geheugen van het moeder process maakt, en dat als adres voor het nieuwe process gebruikt. Uitsluitend clone() zal hetzelfde adres als het moeder process gebruiken voor het nieuwe process. M.a.w. de nieuwe thread deelt (zoals je zegt) het geheugen met de andere thread.

M.a.w. is een POSIX Thread een user-land dingetje.

Het probleem is er m.a.w. tussen alle processen. Dit ligt op een ander niveau dan user-land threads of POSIX threads.

ps. Toen er discussies waren over Spectre en Meltdown hebben verschillende mensen een vrij goede technische uitleg gegeven.

[MSalters]

Ik ben redelijk bekend met de verschillende thread implementaties

Wat jij beschrijft met "speciaal type proces dat het geheugen deelt met het originele proces" zijn de oude Linux threads.. Dat zijn inderdaad user-land dingetjes. Het zijn alleen geen POSIX threads.

Voor POSIX threads onder Linux heb je NPTL, Native POSIX Thread Library. Dat is een native library, dus kernel level. Het zijn echte threads. Windows NT heeft datzelfde model, wat logisch is gezien de VMS achtergrond.

Mijn concrete statement nu is dat twee threads van hetzelfde proces, ONGEACHT de exacte implementatie ervan, sowieso bij het hele geheugen van het hele proces kunnen. Spectre kan dat dus niet erger maken. Het is dus veilig om twee threads van hetzelfde proces op dezelfde HT core te schedulen.

Je hebt gelijk als je zegt dat threads vanuit een CPU perspectief iets anders zijn. Inderdaad, een HT core heeft geen idee of de twee threads van hetzelfde proces zijn. Juist daarom stel ik dus dat het de verantwoordelijkheid van het OS is om die scheduling veilig te doen.

[Verwijderd]

Ik vind het goed dat je technisch gedetailleerd hier op in gaat, @MSalters. Dat is leuk en leerzaam voor de jonge gasten hier op Tweakers! En dan hoef ik mij ook niet meer in te houden ;-)

Maar het gaat hier over OpenBSD en ik vermelde "Typisch op een UNIX", niet "Op Linux". OpenBSD gebruikt niet NPTL maar wel RThreads (meteen naar de juiste slide gelinkt). Het gebruikt hiervoor de syscalls rfork(RFTHREAD) en threxit(). En ja, 'dat is een native library, dus kernel level' klopt hier ook. Maar eigenlijk was het niet mijn bedoeling om op Tweakers meteen enorm technisch te gaan (daarvoor hebben we technischere mailing lists zoals die gebruikt worden voor kernel ontwikkeling aan bv. Linux en OpenBSD).

Het klopt dat wat ik beschreef ongeveer is wat de oude LinuxThreads doen/deden. Maar het klopt nog steeds dat NPTL ongeveer hetzelfde doet. Het artikel (waar je zelf naar verwijst) beschrijft hoe NPTL werkt (ze vermelden dat het een similar approach to LinuxThreads gebruikt, i.v.m. clone() system-call. Dat is wat ik dus eerder uitlegde):

NPTL uses a similar approach to LinuxThreads, in that the primary abstraction known by the kernel is still a process, and new threads are created with the clone() system call (called from the NPTL library). However, NPTL requires specialized kernel support to implement (for example) the contended case of synchronisation primitives which might require threads to sleep and wake again. The primitive used for this is known as a futex.

Ik zie zelf POSIX threads als een implementatie van libpthread (niet enkel de NPTL implementatie). Bijvoorbeeld OpenBSD's librthread is binair compatible met libpthread, en wordt daar gebruikt als de implementatie voor pthreads.

Zoals @Squee ook al opmerkte is er vermoedelijk tussen ons een spraakverwarring. Ik twijfel er niet aan dat jij op de hoogte bent van hoe threads op een typische UNIX geïmplementeerd worden (maar zo ver ik weet wel niet met NPTL op OpenBSD). Het is echter, inderdaad, vanzelfsprekend dat een thread in een process aan het geheugen van de andere threads in hetzelfde process (en het process zelf) kan. Dat is min of meer de definitie van een thread.

Het probleem gaat echter dus verder dan die threads (die de user-land wereld te zien krijgt).

edit: Wat linkjes toegevoegd zodat je kan klikken.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 10:18]

[Sandor_Clegane]

Wat hij beschrijft is dat een CPU thread van een ander proces de data kan lezen van een andere thread niet behorende bij hetzelfde proces.

Je hebt dus OS Proc A dat gescheduled wordt, de CPU jast deze naar een fysieke kern en nu komt OS Proc B en deze wordt gescheduled op een HT kern door de CPU. Deze thread kan nu data lezen van OS Proc A omdat er blijkbaar geheugen wordt gedeeld.

Wat jij zegt klopt, maar dat is ook niet het probleem. Ik weet niet of de scheduler in BSD zo granulair kan schedulen, ik weet wel dat er in Windows op een low level in NT wat moest worden aangepast omdat het OS deze HT kernen als een volwaardige CPU zag en dit performance niet ten goede kwam. Ergens zal er dus wel een kenmerk zijn of iets een HT kern is of een volwaardige, of dit gemakkelijk is, ik heb geen idee.

Tenminste, dat is hoe ik het lees.

[MSalters]

Ik denk dat je het verkeerd leest. In elk geval is je begrip van HyperThreading incorrect. Met HT is er niet zoiets als "fysieke cores" versus "HT cores". Je hebt logische cores 0 en 1, die de fysieke core A delen, logische cores 2 en 3 delen fysieke core B etcetera.

Logische core 0 kan niet zomaar het geheugen van logische core 1 lezen. Maar omdat ze allebei dezelfde fysieke core A gebruiken kun je (Spectre/Metldown) uit de branch predictor en cache afleiden wat er in het geheugen van logische core 1 moet zitten. Die branch predictor en cache zijn namelijk niet volledig gescheiden.

Mijn punt is nu dat als logische cores 0 en 1 allebei bij hetzelfde proces horen, dat ze toch al hetzelfde geheugen gebruiken. Dan hoef je je dus ook niet druk te maken over Spectre en Meltdown.

[Squee]

Er is hier duidelijk wat spraakverwarring over het concept van software threads en hardware threads. Niet voor niets dat Sun indertijd probeerde hardware (hyper) threads "strands" te noemen, iets wat ik meestal gebruik in professionele discussies, omdat het een veel duidelijkere terminologie is.

@MSalters maakt een prima correcte opmerking hier over; meerdere userspace software threads delen al hun address space en kunnen al bij alles van elkaar dus als deze samen de verschillende strands van een core draaien kan dat helemaal geen kwaad. OpenBSD wilde alleen hun OS scheduler niet compliceren om het onderscheid te maken tussen contexten die tot het zelfde proces behoren, of die verschillende processen zijn.

[Verwijderd]

Ik sluit me erbij aan om ze strands te noemen. Dat zou de communicatie erover vereenvoudigen, inderdaad.

[Pb Pomper]

Bovendien is hardwarematige beveiliging altijd beter.

[Blokker_1999]

Natuurlijk, maar bugs in hardware kan je niet zomaaar snel even patchen.

[Verwijderd]

Eens met je statement, behalve met de laatste zin:

m.a.w. Moet Intel maar is gaan nadenken over hoe ze dit in de toekomst gaan vermijden.

Helaas blijven we slimmer en/of creatiever worden. De nu ontdekte methodes zijn zo slim opgezet dat er oorspronkelijk helemaal niet aan gedacht is dat een dergelijke methode gebruikt zou kunnen worden om effectief informatie mee uit te lezen.
De ontwerpers zitten er van een hele andere kant, en met een heel ander uitgangspunt in dan diegenen die slim gebruik weten te maken van ontwerpfouten. Je kunt alles nog zo slim bedenken en laten (penetratie-)testen, dat sluit nog niet uit dat er jaren later iemand toch weer een nieuwe mogelijkheid wordt ontdekt.

[Verwijderd]

Dus moet Intel maar is gaan nadenken over hoe ze dit in de toekomst gaan vermijden.

-- Eigenlijk onderlijn je met jouw opmerking nu net de reden waarom ik zei dat Intel maar eens moet gaan denken hoe ze dit in de toekomst gaan vermijden.

[SuperDre]

Uhm, hoe kun je iets vermijden als je niet kunt bedenken wat er misbruikt kan gaan worden… Daar is gewoon niet over na te denken, anders zou men dat al lang opgelost hebben bij het ontwerpen zelf..

[eth0]

De echte oplossing moet niet van OpenBSD komen maar van de CPU fabrikant...

[EraYaN]

Maar die gaat niet komen in huidige (of eigenlijk next gen) hardware. Dus als OS dev zou je toch gewoon je best moeten doen, zou je denken. Dit klinkt gewoon een beetje als een cop out, willen het werk aan de scheduler niet doen, dus dan zetten we het maar uit. En het uit zetten maakt een aanval niet eens onmogelijk, want speculative execution werkt nog steeds.

Men zou zelfs iets van process flags kunnen verzinnen voor alle threads die belangrijk zijn en dus "geïsoleerd" moeten draaien, maar als de performance echt nodig is, ik bedoel in veel applicatie gaat het om een significant verschil, dan kunnen die threads gewoon fysieke cores delen.

[CAPSLOCK2000]

Ik krijg de indruk dat je de OpenBSD community niet kent. Bij de meeste organisaties zou ik je gelijk geven, die zijn liever lui dan veilig. Maar niet bij OpenBSD. Je kan er veel over zeggen, maar lui zijn ze zeker niet. In tegendeel, ze zijn juist masochistisch fanatiek. Bij het minste of geringste beveiligingsprobleem gaan alle ankers uit en gaan ze niet verder voor de hele codebase is gecontroleerd. Helaas gaat de ontwikkeling van het OS daardoor vrij langzaam, is het niet erg snel, en is het aantal ontwikkelaars nogal beperkt waardoor problemen lang blijven liggen. De beschikbare aandacht gaat eerst naar de veiligheid en als het moet worden er keiharde keuzes gemaakt, zoals hier.
Maar, dat alles heeft wel tot gevolg dat het enorm veilig is.

[jurroen]

Precies. En dit is de reden dat ik zo'n fanatieke gebruiker ben. Security over performance. Het werkt niet zo rap als bijvoorbeeld Linux - maar daar kies je dan ook voor.

OpenBSD is in sommige aspecten een pioneer, ze hebben een leidende rol gehad in verschillende exploit mitigations. En dat blijven ze doen, met KARL heb je elke keer een unieke kernel (ipv address randomization technieken als ASLR) en door middel van Pledge worden syscalls gehanteerd en geforceerd.

Naast deze - extreme - focus op security hebben ze ook veel innovaties gedaan die door andere partijen is geadopteerd, waar OpenSSH het bekendste voorbeeld is. Die zit zeer waarschijnlijk in je broekzak - Android en iOS. LibreSSL heeft ook een vrij brede adoptie, macOS heeft het standaard - ipv OpenSSL.

De volledige 'waslijst' is hier te vinden: https://www.openbsd.org/innovations.html

[The Zep Man]

Dus als OS dev zou je toch gewoon je best moeten doen, zou je denken.

Niet alle hardwarefouten zijn tot in detail op te lossen via software. Soms is het beter om risicovolle hardware uit te schakelen om de betrouwbaarheid te vergroten.

Al staan prestaties van een (significant HT gebruikende) applicatie boven stabiliteit, dan is OpenBSD niet het juiste besturingssysteem om die applicatie onder te draaien.

[kodak]

Wat jij voorstelt is niet haalbaar en niet realistisch.

OpenBSD kiest er voor om het een keuze te maken om voor ondersteuning van hyperthreading te kiezen, maar dat moet dan een eigen keuze zijn.

Ze kunnen heel veel tijd stoppen in pogingen om work arounds te ontwikkelen, maar dat lost het onderliggende probleem niet op en doet dat ook niet op korte termijn. Hyperthreading is praktisch niet ontworpen om veilig te zijn. De keuze om het standaard niet te gebruiken kan bijna nergens anders meer genomen worden. Dus kiest OpenBSD voor de meest veilige optie: staat uit, tenzij je risico wil nemen.

[SuperDre]

Blijkbaar niet, want blijkbaar is het dus op te lossen door de scheduler van OpenBSD aan te passen, maar daar hebben ze zelf geen trek in.. Dus ja, het kan dan alsnog vanuit Intel komen die dan zelf een team er op zet om de scheduler aan te passen.. Maar Hyperthreading uitschakelen betekent ook meteen behoorlijke performance pleite.. Nou dan liever die paar mogelijke veiligheids probleempjes die eigenlijk voornamelijk theoretisch zijn.

[Mathijs]

Hyperthreading is niet zoveel winst hoor. Zo'n 10% dus vrij verwaarloosbaar.

[SuperDre]

jij noemt 10% verwaarloosbaar? als het 1% of minder ok, maar 10% is toch behoorlijk..

[Mathijs]

Ja, 10% is ook niet de moeite om te overklokken, te upgraden of wat dan ook.
30% is zo'n beetje de drempel waarna je er iets aan hebt.

[SuperDre]

Dat vindt jij dus, ik denk daar toch heel anders over.

[Mathijs]

Dat vind ik prima, jij hebt ook recht op je eigen mening.

[mae-t.net]

Het is minstens zo elegant als de gemiddelde patch van MS voor dit soort problemen. Verder kun je het zelf aan of uitzetten, dus eleganter dan de gemiddelde patch van MS.

[Ro-Maniak2]

Wat voor performance impact mag je daarvan verwachten?

[Squee]

Wat voor performance impact mag je daarvan verwachten?

Hangt helemaal af van hoe je je systeem gebruikt, en ook wat de hardware implementatie precies doet. In het geval van Intel zijn er bepaalde structuren in de core statisch gepartitioneerd als HyperThreading aan staat, waardoor een enkele thread minder entries kan gebruiken (in o.a. de TLB staat me zo bij, maar ze zijn vaak niet zo scheutig met dit soort details). HT uitzetten kan dus voor enkele single-thread applicaties een klein beetje extra performance opleveren omdat ze dan alle entries. (mits je niet meer applicaties hebt draaien dan cores). Met andere woorden, als je je systeem niet volledig belast op alle cores/threads, dan zal je er qua performance niet op achteruit gaan.

Heb je een adaptieve workload (zoals vaak in servers) waar je meer threads kan inzetten afhankelijk van hoeveel cores/Hyperthreads een machine heeft, dan zal je zo goed als altijd meer performance behalen uit een systeem met Hyperthreading aan - de individuele threads lopen misschien wat langzamer dan wanneer ze in hun eentje op een core zitten, maar de totale throughput is hoger. Wat mensen vaak verkeerd beoordelen qua performance met Hyperthreading, is dat ze verwachten dat je er effectief een 'hele' core bij krijgt; en dat is niet zo, want je deelt de core resources. Je kan op bijna alle workloads er wel een hogere efficientie in het gebruik van je core mee behalen. Hoeveel deze winst is is nogal applicatie (en architectuur) specifiek, maar je zal eerder aan een performance van 1.5x met twee threads op een core moeten denken dan 2x. Alleen in heel erg uitzonderlijke gevallen zal je in totale zin minder performance halen uit twee threads.

Wat dat betreft vond ik deze opmerking:

Kettenis wijst erop dat multithreading niet altijd snellere prestaties biedt, maar dat dit afhangt van de werklast. Die moet ervoor geoptimaliseerd zijn.

... een beetje een verkeerde indruk geven, omdat het in deze verwoording lijkt alsof Hyperthreading je bijna nooit een voordeel geeft, en alleen als je werklast er speciaal voor geoptimaliseerd is.

Het gaat er om wat belangrijk is voor de applicaties die je draait. Als single thread performance kritiek is (bijv voor minimale response tijd), dan had je Hyperthreading als het goed is sowieso al uit staan, en veranderd er niks. Als throughput belangrijk is dan ga je er duidelijk op achteruit zonder Hyperthreading, zoals ik hierboven beschreef.

[Fermion]

Heeft het 16 cores Hyperthreading nog wel zin?

[Dreamvoid]

Vraag maar aan Oracle Die hebben zelfs 8-voudige hyperthreading op hun 16-32 core chips.

[Squee]

Vraag maar aan Oracle Die hebben zelfs 8-voudige hyperthreading op hun 16-32 core chips.

Nou vooruit, voor een keertje stap ik nog even op mijn oude (vorige) zeepkist dan

Ja, het heeft zin voor throughput georienteerde workloads. Het allerbelangrijkste is dat je een chip hebt met genoeg geheugenbandbreedte, anders is dat simpelweg de bottleneck voor performance. Voor veel server werk heeft het nut. Wat ook goed werkt, zoals Solaris/SPARC deed sinds de T4 out of order implementaties, is het dynamisch gebruik van SMT. Voor taken die echt single thread performance nodig hadden, zorg je dat hij een hele core voor zichzelf krijg (de 'critical thread' feature), en als je meer throughput achtig werk hebt dan gebruik je alle, tot 8, threads op een core. Na een stuk of 4 threads loopt de winst wel rap terug, maar nog steeds konden we met 8 threads net iets meer performance uit een systeem persen dan met 7 threads. Verder dan dat gaan had weinig zin zover ik weet.

[jurroen]

Voor consumenten nauwelijks. Zakelijke markt zeer zeker. Virtualisatie, multi-user en systemen met een hoge workload, geoptimaliseerd voor Xeon-like processoren.

[batjes]

Hoe meer cores je hebt, hoe meer zin HT eigenlijk heeft. Want hoe meer cores, hoe meer load je kan verdelen, hoe meer ruimte je over kan houden voor extra load.

HT is meestal vrij zinloos als je de CPU volgooit en gaat pushen. HT heeft veel voordeel als de CPU een heleboel kleine simpele instructies te verwerken krijgt.

Als je 1+1 die CPU in propt, komt er 2 uit, hij heeft dan tijd nodig om dit in het geheugen te zetten of aan te passen. Terwijl die dat doet, kan je met HT al beginnen met 1+2 uit te rekenen. Waardoor je op software/gebruikers niveau eigenlijk 2 threads op 1 core hebt draaien.

Maar ga jij een miljard cijfers achter de komma voor Pi uitrekenen, dan krijgt die core de tijd niet om even snel een andere instructie er tussendoor te gooien.

AMD is ook pas heel laat Intel achterna gegaan met HyperThreading, pas echt sinds Ryzen. Want toen kwamen we op het aantal cores waar dit juist grote voordelen kan behalen.

Intels HT was een paniekreactie op AMD's multicore van de Athlons

[RobIII]

Kettenis wijst erop dat multithreading niet altijd snellere prestaties biedt, maar dat dit afhangt van de werklast. Die moet ervoor geoptimaliseerd zijn.

Is dus nogal afhankelijk van waarvoor je OpenBSD inzet.

[kodak]

Omgekeerd evenredig met de afgenomen beveiligingsimpact zou aardig zijn.

Het zal de preformance waarschijnlijk niet verbeteren. Voor een keuze zou je toch goed willen berekenen of testen wat de diverse effecten op meer gebieden zijn, naast performance. Meestal heeft niet alleen performance met representatieve waarden als geld en levens te maken.

[Loggedinasroot]

Iemand misschien een artikel/link die de architectuur qua multithreading van AMD/Intel een beetje naast elkaar legt? In hoeverre dit uiteraard openbare informatie is.

[SSDtje]

Wellicht dat ik je hiermee meer opheldering kan geven:
- quora.com: Why is the hyper threading absent in AMD processors? (beschrijft de verschillen tussen Intel's Simultaneous Multi Threading genaamd SMT, en AMD's Clustered Multi Threading CMT)
- arstechnica.com: Meltdown” and “Spectre”: Every modern processor has unfixable security flaws
- arstechnica.com: What’s behind the Intel design flaw forcing numerous patches?


Edit: nog eentje kunnen toevoegen.

[Reactie gewijzigd door SSDtje op 24 juli 2024 10:18]

[Squee]

Wellicht dat ik je hiermee meer opheldering kan geven:
- quora.com: Why is the hyper threading absent in AMD processors? (beschrijft de verschillen tussen Intel's Simultaneous Multi Threading genaamd SMT, en AMD's Clustered Multi Threading CMT)
- arstechnica.com: Meltdown” and “Spectre”: Every modern processor has unfixable security flaws
- arstechnica.com: What’s behind the Intel design flaw forcing numerous patches?


Edit: nog eentje kunnen toevoegen.

Dit is wel oude informatie. De SMT implementatie in de huidige Zen core van AMD zal veel meer lijken op die van Intel's Hyperthreading, de CMT aanpak was echt voor de Bulldozer familie, en bleek toch niet zo goed te werken als gedacht. Helaas zullen Intel en AMD niet scheutig zijn met de diepe details over hun SMT implementaties, hoe bepaalde structuren gedeeld worden tussen de hardware threads en dergelijke. Al is het alleen al om bepaalde patent claims te voorkomen... want dergelijke dingen zijn heel, heel erg moeilijk te meten/achterhalen in een processor.

[edit]: kleine verduidelijking

[Reactie gewijzigd door Squee op 24 juli 2024 10:18]

[Verwijderd]

Lijkt mij de juiste beslissing. Te meer omdat OpenBSD vooral in kritische zaken (incl. militair, bv.) ingezet wordt.

Gaat de performance naar beneden, koop dan meer harde waren. Los dat niet in software op door de zaken minder veilig te maken.

[Game_overrr]

Ik ben er niet geheel in thuis, maar Hyperthreading is toch niet geheel een software oplossing? Ik dacht juist dat het een deels uitgevoerde dubbele core was - dus, hardware.

[B00m3rang]

Niet helemaal. Op het moment is ht een soort van 2e lane in de processor zelf waar de processor data in zet terwijl hij bezig is met het verwerken van iets, dan, als lane 1 klaar is met dat stukje data kan de lane
2 direct beginnen terwijl de lane 1 zn data pakt en verwerkt, dan is die lane klaar en pakt zn data enz enz. Een single core chip met ht heeft 1 imput lane en 2 outputlanes. Zo creëer je een core die eigenlijk de hele tijd data verwerkt i.p.v. eentje die moet wachten op zichzelf.

https://www.youtube.com/watch?v=zloLAGKr3b4

Dus je kan die 2e lane ook "uitzetten" zodat er geen data langs kan lekken middels bugs en exploits.

"Thanks everybody voor de duidelijkere uitleg dan dat ik dat kon. Ik dacht dat ik wel ff een beknopte beschrijving kon geven aan de hand van een paar yt filmpjes en mijn minieme elektronische kennis maar schijnbaar niet. "

[Reactie gewijzigd door B00m3rang op 24 juli 2024 10:18]

[Squee]

Niet helemaal. Op het moment is ht een soort van 2e lane in de processor zelf waar de processor data in zet terwijl hij bezig is met het verwerken van iets, dan, als lane 1 klaar is met dat stukje data kan de lane
2 direct beginnen terwijl de lane 1 zn data pakt en verwerkt, dan is die lane klaar en pakt zn data enz enz. Een single core chip met ht heeft 1 imput lane en 2 outputlanes. Zo creëer je een core die eigenlijk de hele tijd data verwerkt i.p.v. eentje die moet wachten op zichzelf.

https://www.youtube.com/watch?v=zloLAGKr3b4

Dus je kan die 2e lane ook "uitzetten" zodat er geen data langs kan lekken middels bugs en exploits.

Sorry, maar ik vond dit, en ook de video, een vrij slechte uitleg van het concept van HyperThreading/SMT en de potentieele problemen ervan. Er zijn niet twee "lanes" waar tussen gewisseld wordt of iets dergelijks bijvoorbeeld.

Wat er gebeurt als Hyperthreading aan staat, is dat de processor een enkele core presenteert als twee logische cores (soms wordt het ook wel virtuele cores genoemd). Je hebt nog steeds een enkele core, met een enkele pipeline die dan dynamisch gedeeld wordt. Er zijn twee kopie-en van de architecturele staat van de core, dus je program counter, je architecturele registers, etc etc, zodat er twee programma's (of software threads) tegelijkertijd op de core kunnen draaien. Dit gebeurt op twee niveaus; ten eerste op het niveau van de scheduler van je besturingssysteem die bepaald welk proces/programma wanneer op een core mag draaien. Wanneer er een tweede programma of software thread door het besturingssysteem toegewezen wordt op de tweede logische core op een fysieke core, dan zal de core om en om van beide programma's instructies ophalen en executeren. Binnen de executie engine van de core zal dit werkelijk helemaal door elkaar kunnen lopen, dat is juist hoe er een hogere efficientie bereikt wordt. Er zijn twee redenen dat je een hogere efficientie kan bereiken; ten eerste zal een enkel programma vaak niet alle executie units in een core tegelijk kunnen benutten, en ten tweede zal het af en toe op geheugen staan te wachten. Door de executie engine te voeren met twee onafhankelijke stromen van instructies kan er meer tegelijk uitgevoerd worden.

De core houdt bij welke instructies bij welke logische core horen, zodat ze op de juiste versie van de architecturele staat werken en elkaar niet kunnen beinvloeden. Alleen blijven er wel bepaalde structuren gedeeld, die niet (in alle implementaties) strict gescheiden zijn tussen de logische cores; onder andere de branch predictor en de TLB. En laten deze twee structuren nou precies zijn die in Spectre en Meltdown misbruikt worden om informatie te laten lekken tussen verschillende processen. Nu zijn er wel oplossingen bedacht in software, zoals voor Spectre het resetten van de branch predictor op een context switch tussen verschillende software threads/programma's, wat werkt tegen een kwaadaardig en een normaal proces die een enkele core delen. Dit werkt niet als je een Hyperthreaded core hebt en ze allebei tegelijk op hun eigen logische core op een fysieke core kunnen draaien, dan helpen deze software oplossingen niet.

... en dat is precies waarom OpenBSD deze keuze maakt. Voor de beste veiligheid tegen tegen Spectre/Meltdown zal de scheduler van je OS moeten zorgen dat je nooit twee verschillende processen op een enkele fysieke core zet. Dat vonden ze te complex om te implementeren en zelfs dan zijn ze bang voor nog meer (tot nu toe onbekende) security problemen. Ze gaan voor een sterkere scheiding tussen processen door slechts een ding per fysieke core te draaien.

[MSalters]

1 input lane? en 2 output lanes?

Haswell cores hebben de mogelijkheid om per cycle 8 uops te starten, en 4 af te ronden ("retire"). Ik weet niet precies wat jij met je "lanes" bedoelt, want dat is geen standaard terminologie.

Wat je met HyperThreading krijgt is een tweede set registers, inclusief een tweede Instruction Pointer Register. Daarmee kun je dus uops vanuit een tweede thread starten, die dan op de tweede set registers werken, maar de Execution Units die op de registers werken zijn wel hetzelfde.

[robvanwijk]

Een single core chip met ht heeft 1 imput lane en 2 outputlanes.

Deze terminologie heb ik nog nooit gehoord, maar hoe ik het ook probeer te begrijpen, het klopt simpelweg niet. Als je perse het woord "lane" wilt gebruiken, dan nog zitten we op twee input lanes en twee output lanes (die "achter de schermen" tijdelijk één processing lane zijn).

Beste vergelijking die ik zo snel kan verzinnen is een weg van twee rijstroken (dezelfde kant op), die tot één rijstrook wordt samengevoegd om een smalle brug over te steken (waar het rekenwerk wordt uitgevoerd). Let op dat Intel (en AMD) CPUs bij het samengaan ("schedulen") van twee virtuele cores op één fysieke core geen vaste verdeling maken. Het werkt niet met het systeem zoals jij het beschrijft (eerst een stel instructies van de ene, dan wisselen nar een paar instructies van de ander, dan weer terug naar de eerste). Het werkt ook niet met een strikt om-en-om systeem ("ritsen" in de snelweg-vergelijking) al zou dit wel mogelijk zijn; deze oplossing wordt gebruikt in CPUs van andere fabrikanten. Het systeem van Intel (en AMD) is samen te vatten als "wanneer beide virtuele cores werk te doen hebben, dan krijgen ze allebei een gedeelte van de capaciteit, als één van de twee staat te wachten (bijvoorbeeld op geheugen, of omdat er simpelweg geen code op draait) dan kan de ander de volledige capaciteit gebruiken".

[SaiKoTiK]

nee, bij hyperhtreading kan het os een enkele fysieke core als 2 virtuele cores adresseren.

softwarematig ziet je os 2 cores waar er hardwarematig 1 is.
dus heb je bv 4 fysieke cores met hyperthreading ziet je os dit als 8 beschikbare processoren.

cache en interfaces van 2 virtuele cores op 1 fysieke core zijn gedeeld, vandaar de mogelijke beveiligingsrisico's.

[Iblies]

HT houd van cache, hoe meer je er van hebt, hoe beter het functioneert.

Hardwarematig is er verder weinig anders.

Mocht je vaak software gebruiken die graag gebruik van maakt, dan kan het lonen om een CPU te kiezen met zoveel mogelijk cache.

[Kabouterplop01]

Gaat de performance naar beneden, koop dan meer harde waren. Los dat niet in software op door de zaken minder veilig te maken.

Het lijkt bijna een lange termijn strategie, om zo nog hardware te kunnen slijten, aangezien ze dit al wisten.

Voor de rest lijkt het mij niet meer dan logisch als je je zo in de markt zet als OpenBSD, dat je dan zo'n beslissing maakt. Ik ben het er helemaal mee eens.

[bbob]

Het lijkt bijna een lange termijn strategie, om zo nog hardware te kunnen slijten, aangezien ze dit al wisten.

Dus het lijkt er volgens jou op dat intel en andere fabrikanten die hyperthreading gebruiken dat bewust gedaan hebben wetende dat er bugs in zouden zitten die aan het licht zouden komen waardoor ze meer hardware zouden verkopen.

Ik weet niet waar je het vandaan haalt maar het lijkt er voor mij eerder op dat deze bugs gewoon bugs zijn daar door mensen ontwikkeld en nooit perfect en dat het totaal geen strategie is om meer hardware te verkopen.
Maar goed voor mensen met aluhoedjes is natuurlijk alles mogelijk.

[proatjeboksem]

Dat denk ik ook niet, maar wel “ als ze er niet achter komen is dat mooi, en als ze er wel achterkomen, zetten ze het uit en hebben ze meer hardware nodig voor dezelfde performance”, win-win dus

[Tarij]

Waarom zouden de ontwikkelaars van OpenBSD meer hardware willen verkopen? Wat hebben zij zoiezo met hardware te maken anders als dat hun OS er op draait. Hebben opensource ontwikkelaars baat bij meer hardware verkopen?

Of bedoel je Intel wat ook raar is want Intel heeft niks uitgezet.

[proatjeboksem]

Intel. Die heeft ervoor gezorgd dat het uit te zetten valt

[Kabouterplop01]

Dat is wat ik er mee bedoel.

[Kabouterplop01]

Nee, zo zwart wit zal het ook vast niet zijn. Maar het lijkt er op. Tuurlijk zijn het bugs, maar men wist er al langer van als dat wij het wisten. (En zo'n hele architectuur om designen, dat is een deftig klusje)

[friend]

Echt kritische zaken delen over het algemeen geen omgevingen van andere onbekende gebruikers op dezelfde hardware, dan is dit meestal niet zo'n probleem.
Dit geldt meer voor multi-user cloud server omgevingen, waarbij een veelvoud van virtuele omgevingen door meerdere gebruikers worden gedeeld die elkaar niet kennen, die op deze wijze informatie uit een andere virtuele omgeving kunnen vissen.

[Gomez12]

Ehm nee, dit geld juist voor single-user omgevingen. multi-user cloud omgevingen hebben nog tig andere beveiligingslagen eromheen zitten waardoor het heel moeilijk is om iets zinnigs met spectre te krijgen.

Maar single-user omgevingen zijn er juist perfect voor om bank-inlogs te stelen vanuit een printer driver.

[Archcry]

Gaat het nou om "simultaneous multithreading" of "multithreading"?

[Squee]

HyperThreading is Intel's naam voor hun SMT implementatie, dus hardware multithreading. Als OpenBSD compleet 'multithreading' uit zou zetten dan heeft alle software ineens wel een heel erg groot probleem

[Archcry]

Ja inderdaad, dat dacht ik dus ook, hadden ze wel net even iets beter mogen omschrijven in het artikel.

[C.Hariri]

Simpel gezegd bestaat het meeste 'werk' van de CPU uit het wachten op data. Daarom hebben ze een hierarchie geintroduceerd:

CPU
---
L1 cache (+- 100kb)
L2 (+- 1 mb)
L3 (+- 10mb)
(L4 +- 100mb)
Memory (gb en groter)
Hardeschijf (tb)

Dus.. is de data niet in L1, kijk dan in L2,.. tot aan de hdd. De CPU moet wachten op dat die data binnen is, voordat het dat kan verwerken. Nu kun je je voorstellen dat als iets van de hardeschijf binnengehaald moet worden (kost enkele milli-seconden), dit relatief een eeuwigheid duurt voor de CPU (cpu werkt op GHz niveau, dus +- 1 miljoen tijdseenheden sneller).

Elke instructie (actie) wordt op de CPU opgehakt in kleine stukken die 1 voor 1 uitgevoerd worden. (zie cpu pipeline @ wiki). Neem aan dat ze in een specifieke order uitgevoerd moeten worden (geen OoO), dus A -> B -> C -> D.

Als B vertraging heeft omdat die moet wachten op data uit memory, dan loopt de CPU dus een hele tijd niks te doen tot dat deze data binnen is. Met hyperthreading lossen ze dat op door ondertussen een andere thread uit te voeren.

Intel is daar niet de enige in , bijv. Sparc draait op 8 threads per core:
https://en.wikipedia.org/wiki/SPARC#Implementations

en GPU's werken met tot wel duizende threads: zo is er altijd wel eentje die uit te voeren is.

[Aragnut]

Volgens mij is dat scheduling wat je nu uitlegt. Hyperthreading (simultanious multithreading) is dat er per pipeline in de CPU sommige onderdelen (zoals de interger ALU) meerdere keren zijn uitgevoerd. Dit maakt het mogelijk om binnen dezelfde kloktik meerdere instructies uit te voeren. Voor SPARC (en POWER) is het mogelijk om 8 threads per core uit te voeren op dit moment.

[C.Hariri]

Volgens mij is dat scheduling wat je nu uitlegt. Hyperthreading (simultanious multithreading) is dat er per pipeline in de CPU sommige onderdelen (zoals de interger ALU) meerdere keren zijn uitgevoerd. Dit maakt het mogelijk om binnen dezelfde kloktik meerdere instructies uit te voeren. Voor SPARC (en POWER) is het mogelijk om 8 threads per core uit te voeren op dit moment.

Dat superscalar
https://en.m.wikipedia.org/wiki/Superscalar_processor
Hyperthreading gebruikt dezelfde resources:
https://users.cg.tuwien.a...rsthesis/html/node42.html

[Aragnut]

Hyperthreading is inderdaad de architectural state, maar geeft wel de mogelijkheden om verschillende delen op de core samen tegelijk te gebruiken.

Bij mijn weten gebruikt intel op superscalar onderdeeltjes voor de (qua transistor telling) goedkope stukjes.

Zoals @Squee ook aanhaalt zit er wat fijne spraakverwarring tussen threads (OS/software) en threads (hardware).

[wica]

HyperThreading wat is dat?
Zonder dollen, dit zette ik altijd al uit op mijn servers. ik heb nooit het voordeel er van in gezien in mijn setups.

[lordawesome]

Lekkere reclame voor AMD.

[pasarica]

Hoezo lekkere reclame voor AMD?

OpenBSD schakelt HyperThreading bij Intel-processors standaard uit vanwege de beveiligingsrisico's die hiermee gemoeid zouden zijn. Op termijn schrapt het besturingssysteem simultaneous multi-threading bij alle processors.

Nota bene in het eerste alinea wordt aangegeven dat het niet alleen Intel treft: