hangt af van het type bescherming dat je zoekt.
als je PC heel oud is ( en dat issie) dan is de kans groot dat er gewoon geen bios upgrade komt, en zodra Spectre tot exploits leid, ben je gewoon de bok en kan een booswicht onder omstandigheden op je pc.

Dan maak je dus periodiek een offsite backup die je niet synct, maar kopieert. (sync synct ook je gecrypte foto's en video's, dius dan heb je 2 keer niks) ben je beschermd tegen datacorruptie.
Dus dan gebruik je overal en nog ergens aparte niet gerelateerde wachtwoorden, zodat je redelijk beschermd bent tegen het overnemen van al je digitale identiteiten, mits je niks of weinig door je browser laat onthouden.

En je zorgt ervoor dat er geen data op je pc staat die je niet op het internet of in de kantine wilt tegenkomen, zoals naaktfoto's, toegang tot je zwitserse bankrekening of dat nare gedicht voor je schoonmoeder dat je nog niet verstuurd hebt.

of dat allemaal, en een nieuwe pc. ;-)

Hoe dan? De aanvalsvector via de browser is al gesloten in de bekende browsers. En mocht een hacker toch toegang krijgen tot het geheugen van jouw PC, dan is het alleen-lezen-toegang. Daarmee kunnen in theorie wachtwoorden en encryption keys worden achterhaald, echter dat is in de praktijk (met de sloten geheugen die hedendaagse systemen hebben) echt niet eventjes snel gedaan.

Kortom: laat je niet gek maken!


Dat is altijd verstandig.


Dat is erg vergezocht.


Dat is mijns inziens onnodig (ik ga het in ieder geval niet doen voor mijn oude computers).

Zelfs als jw nu een nieuwe pc kooot is het de graag of deze al gepatched is qua BIOS en windows en drivers en andere hard en software tegen deze 2 dreigingen. En zelfs al komen er nieuwe pc's die standaard gepatched/beveiligt zijn tehen deze 2 dreigingen dan komt er wel weer een nieuw lek voor deze 2 dreigingen of nieuwe soortgelijke dreigingen die mede de hardware betreffen. Ik koop geen 600 euro kostende notebook om steeds toch gevaar te lopen of zelf te moeten patchen. Conclusie: ik koop geen nieuwe pc maar ga er 1 leasen/ huren komt er zo'n lek dan eis ik een nieuwe of 1e hands wel gepatchte pc of ontbinding vd huurovereenkomst.

Voorlopig kan je het beste rustig even afwachten hoe het verloopt. Intel heeft vandaag een oproep gedaan om hun patch voor spectre niet aan te brengen omdat hij teveel problemen veroorzaakt:
https://newsroom.intel.com/news/root-cause-of-reboot-issue-identified-updated-guidance-for-customers-and-partners/

Toeval of niet, dit is een dag nadat Linus Torvalds (degene die Linux heeft bedacht en nog steeds projectleider van de Linux-kernel) de patches van Intel "COMPLETE AND UTTER GARBAGE" (hoofdletters van hem) genoemd. Het lijkt erop dat de patches van Intel dingen doen die niet meer nodig zouden moeten zijn omdat software door een paar instructies te veranderen de zaak kan omzeilen, maar die wel een ernstige performace-impact hebben. Is er iets dat Intel weet maar (nog) niet aan de wereld vertelt? En waarom vinden ze de patches wel nodig maar is de wijziging default niet actief en moet het besturingssysteem het activeren? Dat soort vragen is kennelijk nog niet goed beantwoord bij mensen die er heel direct mee te maken hebben omdat ze over de kernel van een OS gaan.
https://lkml.org/lkml/2018/1/21/192

Ik denk niet dat niemand op dit moment simpele antwoorden kan geven. Het is in hetzelfde soort stadium als "breaking news" als er iets groots gaande is in de wereld en het is domweg afwachten waar het precies heen zal gaan.

Heeft weinig met BIOS te maken, dit is een architectuur probleem en zou alleen verholpen kunnen worden door kernel en userland plus microcode patches aan te brengen met de benodigde verlies van snelheid.
Of ze moeten de architectuur aanpassen om dit soort dingen niet meer toe te laten en dan nog heb je verlies van snelheid.

Ja. maar helemaal passief afwachten (zo lees ik je suggestie) is niet raadzaam. Intel geeft wel een zinnig advies - uit de oude toverhoed; dat wel, maar toch: (citaat)...We continue to urge all customers to vigilantly maintain security best practice and for consumers to keep systems up-to-date.

Waarom zij - Intel - een verschillend handelen adviseren voor Customers (klanten) en Consumers (gebruikers) vind ik een beetje raadselachtig want beste beentje voor zetten door niet als een blinde alles aan te klikken wat onder de cursor komt, doen we al (toch?...) en de zaak up to date houden is een raad die we al kennen sinds de noodzaak van patchen duidelijk werd.

Feitelijk stipuleren zij extra wat al jaren is vastgelegd omdat zij momenteel niet weten? hoe de Spectre kwetsbaarheid aan te pakken, maar zij hebben wel gelijk met de aloude raad: houd je systeem up to date.


Tsja... Vanavond kreeg ik wel een melding in (Linux) updatebeheer dat er een vernieuwde Intel Micro-code beschikbaar is. Moet ik dan denken m.b.t. Torvalds opmerking: dit is tegenstrijdige informatie? Neen ik laat mijn bedenkingen maar overwaaien.
Ik heb de niveau 3 update geïnstalleerd en zie zojuist 0:05 uur dat er alweer een nieuwe kernel beschikbaar is 4.4.0-112.135 en ja nu kijk ik wèl even de kat uit de boom. Ik denk zo dat iedereen een beetje op zichzelf aangewezen raakt, (Apple? Linux, Windows) en daarmee kom ik op je laatste opmerking...


...Inderdaad.

Tuurlijk joh. Een brandend huis kun je niet verzekeren, en verhuurders zullen hun risico ook afdekken - je krijgt hetzij een tarief waarvoor je heel snel ook een nieuwe had kunnen kopen, of een voldoende clausules ('overmacht'/'patches volgens industrie standaard') dat ze er geen verlies op zullen maken.

De BIOS update is eigenlijk alleen noodzakelijk wanneer het OS G E E N aangepaste ('veilige') microcode aanbiedt.

Ik ging ervan uit dat dat een open deur is. Met afwachten bedoel ik niet dat je updates die je normaal wel zou doen opeens niet meer doet.

Als Debian-gebruiker zie ik men daar in de stable-release (ze hebben ook unstable en testing) nog op de Intel-firmware van 2017-07-07 zit, testing zit op de versie waar Intel nu over waarschuwt (2018-01-08), en in unstable (waar het nieuwste van het nieuwste beschikbaar is zonder enige garantie op stabiliteit) is die teruggedraaid naar de versie van 2017-11-17, een versie die stable nog niet had bereikt. Wat je daar ziet is dat men niet overhaast dit soort wijzigingen doorvoert in de stabiele release maar alles eerst door een testtraject gooit (in unstable komt alles binnen en in testing bouwt men een steeds hogere stabiliteit op die uiteindelijk een nieuwe stable-release oplevert). Het security-team van Deban heeft duidelijk in hun afweging tussen urgentie en risico gekozen om niet overhaast de nieuwste microcode te activeren. Ik ben geneigd hun oordeel te vertrouwen, in de 18 jaar dat ik Debian stable gebruik heb ik de ervaring dat ze bovenop securityproblemen zitten maar ik kan me niet herinneren dat een security-upgrade ook maar een keer een probleem heeft veroorzaakt.

Microsoft maakt ongetwijfeld voor wat ze uitrollen naar gebruikers vergelijkbare afwegingen, wat zou moeten betekenen dat de vraagsteller gewoon de normale update-procedures kan vertrouwen en gebruiken. Zelf vertrouw ik voorlopig niet op wat de maker van mijn BIOS aanlevert en doe ik geen BIOS-upgrades, vooral omdat ik niet zou weten hoe ik een vorige versie terug moet zetten, wat me bij Debian wel duidelijk is.

Als je als Windows-gebruiker in staat bent om te zien welke versie bij een upgrade wordt aangeboden dan zou je wat Debian voor stable levert als second opinion kunnen hanteren. Welke versie die voeren kan je op deze pagina zien (in de versieaanduiding zit een datum, momenteel staat er: 3.20170707.1~deb9u1):

https://packages.debian.org/stable/intel-microcode

Voor degenen die meer details willen weten , een paar relevante links.

Intel (en AMD) microcode update leveren een paar gedragswijzigingen bij branch prediction waarbij Spectre moeilijker wordt.
Ze vereisen wel kernel support, en Linus is erg ontevreden over de stijl en richting van die aanpak - en ze zijn erg 'duur' - ze kosten veel performance.

Dan is er een andere workaround ('retpoline') - deze vereist ook compiler support , maar is redelijk universeel en de kosten in performance vallen mee.
Dit was een idee van Paul Turner van google.

retpoline :
https://lkml.org/lkml/2018/1/4/174
https://support.google.com/faqs/answer/7625886

Uitleg van David Woodhouse over de microcode patches en retpoline

https://lkml.org/lkml/2018/1/22/598

En blijkbaar is de Skylake microarchitectuur een lastig probleem

Dat geldt alleen voor de Meltdown bedreiging.
Voor de Spectre helpt dat niet! Daar is een Bios update de enige manier om het gevaar (uiteindelijk) te elimineren.
Met als gevolg een tragere computer en op dit moment divers extra problemen.

Beter maar even afwachten. De bedreiging is nog op geen enkel systeem daadwerkelijk uitgevoerd. Dat komt natuurlijk wel, maar zolang ze niet letterlijk bij je computer kunnen komen zit het enige gevaar hem in een niet geupdate browser.

Nee, je kan het oplossen zoals hier word aangekaart : https://lkml.org/lkml/2018/1/22/598
Het probleem is zit in de CPUs en dus een logische stap zou zijn veranderingen aan de toekomstige CPUs.
Dat je snelheid moet inleveren is normaal want dit is nou eenmaal mogelijk omdat Out-of-order execution een belangrijke rol speelt bij het versnellen van Intel CPUs daardoor is meltdown mogenlijk.

Microcode is iets wat de instructieset van een CPU definieert, en is afkomstig van de fabrikant van de processor (Intel in dit geval). Het is mogelijk om de bij fabricage ingebakken microcode te vervangen door een nieuwe versie, en dat gebeurt als je het systeem start. Dat kan zowel door de BIOS/UEFI als door het OS worden gedaan. Maar het is precies dezelde microcode die in je CPU belandt, met precies dezelfde effecten. Het is dus onzin dat een BIOS-update iets voor elkaar krijgt dat het OS niet kan.

Voor Meltdown was in het geheel geen microcode-update nodig. Meltdown wordt aangepakt door te voorkomen dat een applicatie read-onlytoegang heeft tot meer kernelgeheugen dan het nodig heeft om system calls uit te kunnen voeren. Het bijhouden van "page tables" waarin dat geregeld wordt is een taak van het besturingssysteem. Daarom was Meltdown al opgelost voor Intel met nieuwe microcode kwam.

Op het web wordt gediscussieerd en getest

Een fractie van 1 seconde tot 7 seconden (op een heel oud systeem) = "echt niet eventjes snel" ?

Je data zijn dus weg in een oogknippertje als je pech hebt.
Luister misschien maar niet teveel naar de uit de lucht gegrepen aannames van delafoss.
Want voor je het weet ben je wel degelijk de kloss.

Het is niet out-of-order-executie die het probleem vormt, maar speculatieve executie, iets dat veel verder gaat. Er worden instructies uitgevoerd waarvan nog niet vastgesteld kan worden of ze wel uitgevoerd moeten gaan worden, en wel op een manier waarvan neveneffecten informatie prijsgeven die niet prijsgegeven mag worden.

Of dat een fundamenteel onvermijdbaar probleem is is iets waarover de meningen lijken te verschillen. Ik ben bijvoorbeeld ergens (ik weet niet meer waar in de wirwar van berichten en commentaren hierover op diverse tech-sites) tegengekomen dat iemand stelde dat je door een iets andere benadering ervoor te implementeren dan Intel nu toepast de voorspelbaarheid van het mechanisme voor een aanvaller zo sterk gereduceerd wordt dat een aanval waarschijnlijk praktisch onmogelijk wordt. En er was iemand die claimde dat vele jaren geleden in een universitaire opleiding over CPU-ontwerp precies dit issue al werd behandeld, inclusief hoe je het goed doet. Ik weet en snap er lang niet genoeg van om het realiteitsgehalte van dit soort opmerkingen goed in te kunnen schatten, ik sluit dus niet uit dat het onzin is maar evenmin dat daar mensen aan het woord waren die er werkelijk verstand van hebben.

Volgens de uitleg van Linux-kernelontwikkelaar David Woodhouse, die direct bij het oplossen van het probleem in Linux betrokken is, over de microcode patches en retpoline (Anoniem 10:54 hierboven linkt ernaar), is de Spectre-ellende grotendeels opgelost met een compiler die bepaalde instructies door een alternatief vervangt (retpoline) en die geen noemenswaardige performance-impact hebben, en die aanpassingen zijn al geïmplementeerd. Alleen Intel-processoren met de Skylake-architectuur zouden ook in sommige omstandigheden bij de alternatieve instructies het probleem vertonen. Voor die processoren voegen de wijzigingen van Intel wel iets toe en zijn de performanceproblemen relatief beperkt. Hoe ernstig de resterende kwetsbaarheid na toepassen van retpoline voor Skylake zijn is kennelijk nog niet duidelijk, maar in de reacties op de genoemde uitleg dragen mensen een oplossing aan die de probleemsituaties kennelijk op een elegante manier vermijdt zonder dat de patches van Intel daar nog bij nodig zijn.

Ik vind met name die discussie sterk suggeren dat het snelheid verminderen dat de Anoniem op wie ik reageer vanzelf vindt spreken helemaal niet normaal hoeft te worden gevonden.