image

OpenBSD schakelt hyperthreading uit wegens beveiligingsrisico

woensdag 20 juni 2018, 10:36 door Redactie, 4 reacties
Laatst bijgewerkt: 20-06-2018, 13:40

De makers van het besturingssysteem OpenBSD hebben besloten om hyperthreading standaard op systemen met een Intel-processor uit te schakelen, aangezien het een serieus beveiligingsrisico is. Dat laat Mark Kettenis van het OpenBSD-project op de OpenBSD-mailinglist weten.

Simultaneous multithreading (SMT) is een techniek die de prestaties van moderne processors moet verbeteren. Het zorgt er onder andere voor dat cachegeheugen onder verschillende processor-threads wordt gedeeld. Dit maakt het volgens Kettenis veel eenvoudiger om cache timing-aanvallen uit te voeren en zou er ook voor zorgen dat verschillende Spectre-achtige kwetsbaarheden zijn aan te vallen.

Het probleem speelt vooral bij Intels propriëtaire implementatie van SMT genaamd hyperthreading, aldus Kettenis. "We moeten geen verschillende beveiligingsdomeinen op verschillende processor-threads op dezelfde core draaien", zo laat hij weten. Het is echter lastig om dit binnen OpenBSD aan te passen. Daar komt bij dat moderne computers niet de mogelijkheid bieden om hyperthreading via het bios uit te schakelen en er dus geen manier is om het gebruik van extra processor-threads in de OpenBSD-scheduler uit te schakelen. "Aangezien we denken dat het om een serieus beveiligingsrisico gaat, hebben we ze nu standaard uitgeschakeld", gaat Kettenis verder. Gebruikers kunnen de optie wel weer inschakelen.

Op dit moment geldt dit alleen voor OpenBSD-systemen met een Intel-processor, maar het ontwikkelteam is van plan om de feature ook voor processors van andere leveranciers en andere hardware-architecturen door te voeren. Kettenis merkt op dat SMT niet per definitie een positief effect op de prestaties hoeft te hebben. Dit hangt vooral van de werklast af. "Het is waarschijnlijker dat het de meeste werklasten zal vertragen als je een processor met meer dan twee cores hebt", aldus Kettenis. Op Hacker News is er inmiddels een uitgebreide discussie over de beslissing ontstaan.

Reacties (4)
20-06-2018, 12:34 door Anoniem
ik had mijn hypertr al uit gezet maar ik merkt er niets van ( nog niet ) misschien bij te veel openen van je programma's
??????????
20-06-2018, 14:16 door Anoniem
Door Anoniem: ik had mijn hypertr al uit gezet maar ik merkt er niets van ( nog niet ) misschien bij te veel openen van je programma's
??????????

Dan gebruik je je systeem te weinig of de programmatuur die je gebruikt kan niet overweg met multithreading. ;)
20-06-2018, 18:34 door Anoniem
Door Anoniem: ik had mijn hypertr al uit gezet maar ik merkt er niets van ( nog niet ) misschien bij te veel openen van je programma's
??????????
Hyper-threading levert alleen merkbare winst op bij applicaties die onderhuids vaak van taak wisselen. Met hyper-threading worden de processorkernen optimaal belast en staan ze zo min mogelijk tijd niets te doen omdat ze op gegevens wachten. Zonder zal je niet veel merken bij gewone taken, omdat het verschil klein is. Pas als je iets doet waarbij er veel geschakeld wordt stapelen de kleine winsten zich op en krijg je grotere en merkbare winsten. Typische voorbeelden zijn het renderen van video of raytracing van 3d-renders. Let op dat het dus niet gaat over het wisselen tussen applicaties door de gebruiker zelf. Dat stelt niets voor in vergelijking met het duizenden keren per seconde wisselen waar het hier over gaat.

Zelfs in scenario's waar hyper-threading veel winst oplevert is dat vaak meetbaar, maar is het als gewone gebruiker maar nauwelijks merkbaar.
21-06-2018, 07:22 door karma4
Door Anoniem: ik had mijn hypertr al uit gezet maar ik merkt er niets van ( nog niet ) misschien bij te veel openen van je programma's
??????????
Hyperthreading is het gebruik van een tweede pulse in de Klok cyclus. Je hebt dan ogenschijnlijk 8 ipv 4 cpu's of 16 ip 8.
Het uitzetten reduceert het aantal logische cpu's. Het doet niets aan de kloksnelheid. Heel veel applicaties zijn single threading dan merk je niets. Ook niet als je belasting normaal onder de 25% zit. Niet elke logische cpu heeft direct toegang tot caches/io. Het is een hele orchestrate.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.