Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Google: bescherming tegen Spectre-aanvallen voor Chrome-desktopversies is actief

Google heeft een beveiligingsmaatregel ingeschakeld voor het overgrote deel van de desktopgebruikers van zijn Chrome-browser. Het gaat om de feature site isolation, die moet voorkomen dat kwaadaardige websites gevoelige informatie stelen.

Google meldt dat de functie inmiddels voor 99 procent van de Chrome-gebruikers standaard is ingeschakeld, waarbij de laatste 1 procent wordt gebruikt om prestaties in de gaten te houden en zo nodig te verbeteren. De introductie van de functie vond plaats in versie 67 van Chrome, die eind mei uitkwam. In versie 66 van de browser voerde Google een beperkte test van de functie uit onder gebruikers, maakte het bekend bij de release van die versie. Het was voor zakelijke gebruikers al langer mogelijk om site isolation in te schakelen via een flag. Die mogelijkheid bestond sinds Chrome 63.

Illustratie van Google

De functie moet voorkomen dat een kwaadaardige website in staat is om gevoelige informatie te stelen van een andere website die geopend is in de browser, aldus Google. Het is een soort 'tweedelijnsverdediging', omdat same origin policy in principe al voorkomt dat websites gegevens van elkaar kunnen inzien. Site isolation gaat verder dan dat, doordat pagina's van verschillende websites in aparte processen en eigen sandboxes worden ondergebracht. Dat geldt onder meer voor tabs en iframes. Volgens Google heeft de maatregel tot gevolg dat Chrome ongeveer tien tot dertien procent meer geheugen gebruikt.

Het bedrijf schrijft dat het door het isoleren van renderer processes per site afhankelijk is van het besturingssysteem om daadwerkelijk aanvallen tussen processen te voorkomen. Voordat de functie in Chrome aanwezig was, werd een iframe van een andere site in hetzelfde proces ondergebracht als dat van de site waarop de gebruiker op dat moment aanwezig was. Dat kon ertoe leiden dat een aanvaller een succesvolle Spectre-aanval kon uitvoeren. Een dergelijke aanval maakt het uitlezen van gevoelige gegevens mogelijk, in de browser bijvoorbeeld cookies of wachtwoorden.

Google zegt dat het nu gaat onderzoeken op welke manier site isolation te integreren is in de mobiele Android-Chrome-browser. Of dat ook in de iOS-versie gebeurt, vermeldt de zoekgigant niet. Google start een experimentele implementatie voor zakelijke gebruikers in versie 68 van de Android-versie. Het bedrijf had al tegenmaatregelen in Chrome geïntroduceerd bij de publicatie van Meltdown en Spectre in januari, bijvoorbeeld door timers minder precies te maken. Deze maatregelen draait het nu weer terug, omdat die dankzij site isolation niet meer nodig zijn.

Door Sander van Voorst

Nieuwsredacteur

12-07-2018 • 10:34

63 Linkedin Google+

Reacties (63)

Wijzig sortering
Persoonlijk vind ik het zeer vervelend dat al die beveiliging ten koste gaat van geheugengebruik en performance.

Ik snap dat het voor sommige mensen en beroepen interessant en belangrijk is, maar ik vind een snelle browser met weinig geheugengebruik toch wel belangrijker dan beveiligd te zijn tegen de laatste obscure security incidenten. Ik besteed dat geheugen en processor kracht liever aan Visual Studio en mijn compiler terwijl ik 20 tabs aan documentatie en achtergrondinfo open heb staan.
Ik vind het persoonlijk vervelend dat we jarenlang beveiliging links hebben laten liggen voor de performance.

We zijn momenteel met weer een security inhaalslag bezig. De vorige was ten tijde van XP, toen men erachter kwam dat security best belangrijk was (tot aan ~2000 was het echt een non-issue). Een aantal jaar was iedereen hard bezig met security en de boel dicht timmeren. Dat is een aantal jaartjes rustig gebleven. Men bleef stil zitten, het leek alsof we 'veilig waren'.

Niets is minder waar, gezien we met deze spectre/meltdown exploits terug kunnen gaan naar de jaren 90. Dit zijn naar mijn idee echt bewuste keuzes geweest. Intel moet hier gewoon van geweten hebben. Misschien niet als bedrijf zelf, maar je kan mij niet meer vertellen dat er echt geen engineer oid de afgelopen 25 jaar zijn vraagtekens heeft gehad bij het predictive branching gebeuren, maar een oplossing kost performance, en dat kon Intel natuurlijk niet gebruiken in hun strijd jegens AMD.

Maar bedenk je eens, als in het meest complexe onderdeel van onze computers dit soort exploits gevonden worden, en 20+ jaar ongezien blijven. Bedenk je eens hoe ontzettend gaar de rest van de hardware kan zijn.

Ik denk dat we de komende jaren nog wel veel meer performance gaan inleveren om ons spul veiliger te maken.

Leuk dat jij snelheid en performance belangrijker vind dat de veiligheid van een applicatie. Je bent deel van het probleem waar we nu allemaal mee te maken krijgen. Men vond veiligheid in het verleden een non-issue, de meeste mensen vinden security momenteel nog bijzaak of in de weg zetten. We zijn wat dat betreft dus geen fuck opgeschoten in het bewustzijn van een veilige digitale omgeving, ondertussen wel allemaal zeiken op de overheid die het schijnbaar bagger slecht doet, daar werken dezelfde mensen, daar werkt hetzelfde fucking volk wat zelfs hier op Tweakers niet weet hoe ontiegelijk belangrijk die security mindset is.

Als je performance te kort komt, koop dan meer performance in. Geheugen gebruik is -vooral proffesioneel- echt een fucking non-issue. Waarom druk je er geen 64gb of 128gb in je workstation als je je zorgen maakt of je 20 tabs en Visual Studio te kort komen met het vrij standaard 8gb.

Performance nodig? Druk er Xeons in of pak de laatste Threadripper. Huur een stukje cloud in voor de performance.

Als dit soort security fixes jou systeem verandert van soepel naar sloom, zat je toch al aan de grens van de beschikbare performance zonder een beetje beenruimte over te laten.
Niets is minder waar, gezien we met deze spectre/meltdown exploits terug kunnen gaan naar de jaren 90. Dit zijn naar mijn idee echt bewuste keuzes geweest. Intel moet hier gewoon van geweten hebben. Misschien niet als bedrijf zelf, maar je kan mij niet meer vertellen dat er echt geen engineer oid de afgelopen 25 jaar zijn vraagtekens heeft gehad bij het predictive branching gebeuren, maar een oplossing kost performance, en dat kon Intel natuurlijk niet gebruiken in hun strijd jegens AMD.
Ik vraag me dit toch af, zoiets hou je lijkt mij niet 25 jaar "onder de pet" als groep van cpu fabrikanten in de tech sector, ook het feit dat op wat theoretische toespelingen na geen enkele onafhankelijke beveiligingsonderzoeker dit niet eerder aan de kaak heeft gesteld doet mij denken dat dit echt niet bekend was. Zeker ook gezien het feit dat zo'n beetje iedere cpu fabrikant er last van heeft, het is niet alleen Intel, maar ook ARM (en afgeleiden, bijvoorbeeld Apple in haar SoC's), AMD, IBM (Power) Oracle (Sparc) zijn in meer of mindere mate vatbaar voor deze security flaws.
Zijn die andere chip bakkers niet minder kwetsbaar, omdat ze het wel zagen en het proberen op te lossen, of iig te minimaliseren?

AMD had namelijk al wel gezien dat predictive branching 1 groot security risico was, en heeft security checks en features ingebakken om dit te minimaliseren/voorkomen/tegen te houden/pittig te maken.

Intel, met een R&D budget groter dan de rest bij elkaar, is de enige die zo hard geraakt wordt. Dat geeft vraagtekens die Intel dusver niet beantwoord. Ik geloof gewoonweg niet dat AMD dit wel zag, maar Intel niet.
AMD had namelijk al wel gezien dat predictive branching 1 groot security risico was, en heeft security checks en features ingebakken om dit te minimaliseren/voorkomen/tegen te houden/pittig te maken.
Dus je kunt niet met zekerheid zeggen dat Intel zich überhaupt bewust was van dit probleem, maar je brandt ze tot de grond toe af. Tegelijkertijd wist AMD duidelijk wel dat er een probleem is, maar als zij zich er vanaf maken met een gedeeltelijke oplossing, dan prijs je dat aan? Dat is echt volkomen onlogisch.
Intel, met een R&D budget groter dan de rest bij elkaar, is de enige die zo hard geraakt wordt. Dat geeft vraagtekens die Intel dusver niet beantwoord.
Hoe meer budget voor R&D, hoe geavanceerder de optimalisaties die je kunt maken. Als een extreem voorbeeld, een fabrikant die geen budget heeft om een out-of-order CPU te ontwerpen (en bij in-order blijft steken), zal nooit tegen Spectre en Meltdown aanlopen.

Heb je je ingelezen in wat deze kwetsbaarheden precies inhouden? Ik kan me levendig voorstellen dat niemand dit ziet. Zeker bij een groot team, waarbij de verantwoordelijkheden verdeeld zijn over meerdere groepen, is een probleem als dit (wat afhankelijk is van de exacte details van meerdere onderdelen van het ontwerp) makkelijk te missen.

Dus wat mij betreft is het volkomen realistisch dat ze er niet van op de hoogte waren én ik heb een soort-van onderbouwing voor de stelling dat ze het inderdaad echt niet wisten. Zonder maatregelen in hardware is deze aanval onzichtbaar uit te voeren. Oftewel, als Intel hiervan wist én hun eigen processoren gebruikt in al hun eigen computers (geen idee of dat zo is, maar "Intel gebruikt zelf alleen maar AMD cpus" lijkt het soort krantenkop die snel uitlekt), dan nemen ze bewust het risico dat al hun eigen data en geheimen gestolen worden, zonder dat ze ooit kunnen achterhalen óf het gebeurd is, en zo ja, wie het gedaan heeft. Is dat een realistische aanname voor het moment waarop ze erachter komen, terwijl ze als een gek proberen het zo snel mogelijk te fixen? Ja, bij gebrek aan een alternatief (en, wat zouden ze anders kunnen doen?) zullen ze wel moeten. Maar is dat een realistische aanname vanaf het moment dat ze erachter komen... en vervolgens talloze jaren besluiten dat het wel prima is? Nee sorry, dat zie ik echt niet gebeuren.
Ik geloof gewoonweg niet dat AMD dit wel zag, maar Intel niet.
En ik geloof gewoonweg niet dat de aarde rond is. En nee, daar ga ik geen enkele zinnige onderbouwing voor geven, daarvoor weet ik het te zeker...!?
AMD is niet kwetsbaar voor Meltdown, Intel en ARM wel in bepaalde ranges cpu's, Spectre zijn ze allemaal vatbaar voor zo voor zover mij bekend. AMD Ryzen vanwege de checks die je al noemt zo lijkt het wel lastiger dan bijvoorbeeld Intel in het geval van Spectre. Maar goed Ryzen is ook een relatief nieuw ontwerp qua architectuur. Het ontwerp waar bijv. Intel op voortborduurt is alweer zo'n 10-11 jaar oud (uiit mijn hoofd gelanceerd in 2009 in de eerste iteratie en daarvoor dan minimaal 1-2 jaar in ontwikkeling), en wat ik begrijp kan zo'n ontwerp niet zomaar aangepast worden, maar is daar echt een volledig nieuw design voor nodig.
Ryzen is een doorontwikkeling op Bulldozer, zo 'relatief nieuw' is het niet en Intel borduurt nog voort op het P3 ontwerp, wat ook weer een doorontwikkeling is. Er zit in Bulldozer al bepaalde checks die Meltdown voorkomen en Spectre vrij zinloos maken.

Er is volgens mij nog steeds niet een realistische usecase waarbij een Spectre aanval op AMD zinvol is. Naast dat je eerst de bios in moet duiken en deze flashen/hacken om het uberhaupt uit te kunnen voeren, zelfs als dit je lukt, moet je als het niet meezit maandenlang wachten en hopen dat het een keer gaat lukken.

Van ARM weet ik de details zo niet, zo ver ik begreep was de impact daar meer te vergelijken met AMD dan met Intel. Dus ook ARM en hun bakkers hebben dit toch aan moeten zien komen.
Ryzen zou juist geen doorontwikkeling zijn op Bulldozer, zie:
Zen is a clean sheet design that differs from the long-standing Bulldozer architecture. Zen-based processors use a 14 nm FinFET process, are reportedly more energy efficient, and can execute significantly more instructions per cycle. SMT has been introduced, allowing each core to run two threads. The cache system has also been redesigned, making the L1 cache write-back. Zen processors use three different sockets: desktop and mobile Ryzen chips use the AM4 socket, bringing DDR4 support;
Heb je meer info over die bios aanpassing? Ik meende namelijk dat dit geen bios aanpassing betrof maar het aanzetten van BPF JIT binnen de Linux kernel (niet van toepassing op Windows machines).

Zie de volgende quote:
A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time.
Hoe dan ook, dat zou alleen voor variant Spectre V1 van toepassing zijn en die variant wordt al volledig gedicht voor zowel Intel als AMD in OS patches.

AMD zelf geeft aan dat in ieder geval Bulldozer en up vatbaar zijn voor Spectre V2, met de kanttekening dat ze denk dat het zeer lastig te exploiten zal zijn, iets dat ik best geloof. Echter iets dat nu lastig is, kan over een maand, een jaar een stuk makkelijker zijn. Vandaar dat AMD ook hier gewoon, net zoals Intel, werkt aan Microcode om deze vunerability te verhelpen, naast de benodigde OS patches.

Wat ARM betreft ben ik ook niet volledig op de hoogte, ik begreep echter wel juist het tegenover gestelde, dat ARM meer de Intel kant op zit (want bijv. ook vatbaar voor Meltdown).
Ah vandaar dat Ryzen zo veel weg heeft van Bulldozer maar dan... beter. Het is geen Bulldozer 2.0, maar het is wel een doorontwikkeling van. Net zo goed als dat Core een doorontwikkeling is op de Pentium 3, maar het is geen Pentium 3 V2.0. Ryzen is op veel vlakken Bulldozer, min de flaws, plus wat leuke extratjes en een infinity fabric. Bulldozer was de 'clean sheet' van AMD.

https://www.securitynow.c...tion_id=649&doc_id=741399
The Masterkey variant installs malware on the BIOS
De kwetsbaarheid van AMD kan in de toekomst inderdaad makkelijker te misbruiken zijn, gelukkig dat AMD er wel mee bezig is om dat te voorkomen.
Masterkey heeft echter niets met Spectre / Meltdown of varianten te maken, dat was onderdeel van die enigzins wazige CTS labs onthulling.
Wat ARM betreft ben ik ook niet volledig op de hoogte, ik begreep echter wel juist het tegenover gestelde, dat ARM meer de Intel kant op zit (want bijv. ook vatbaar voor Meltdown).
Nee, er zijn maar een zeer beperkt aantal ARM SoCs vulnerable voor Meltdown.
Ryzen lijkt in niets op Bulldozer. Werkelijk alles is anders. Frontend, ALU's, caches, multithreading. En er zitten geen checks in om Meltdown te voorkomen, het verschil met Intel is dat bij de laatste de bounds check later in de pipeline zit, wat agressievere optimalisatie mogelijk maakt.

Iemand nog interesse in een FX-8350E? Met gratis uitgebrand moederbord erbij! Blijkbaar zijn 4 power phases te weinig voor een volledig belaste Bulldozer. Bord heeft het toch nog 3 maanden volgehouden, knap. Leermomentje ;-)
Side channels (want tot deze categorie behoren de Meltdown en Spectre attacks) zijn eigenlijk pas echt onderkend sinds het AES selectie proces, zo'n 20 jaar geleden. Het vereist een compleet nieuw paradigma qua denken om ze te voorkomen en toch te kunnen optimaliseren. Er is een hele goede reden dat AES tegenwoordig in hardware uitgevoerd is.
Het gaat om authenticity, confidentiality, en integrity.

Parallel daar aan: veilig, toegankelijk/gebruikersvriendelijk, en performance is een combinatie die moeilijk samen gaat. Vaak is het niet zo ingewikkeld 2 v/d 3 te combineren, maar 3 v/d 3 wel.
We zijn momenteel met weer een security inhaalslag bezig. De vorige was ten tijde van XP, toen men erachter kwam dat security best belangrijk was (tot aan ~2000 was het echt een non-issue). Een aantal jaar was iedereen hard bezig met security en de boel dicht timmeren. Dat is een aantal jaartjes rustig gebleven. Men bleef stil zitten, het leek alsof we 'veilig waren'.
Dit is projecting nonsense, dat nergens op slaat (kijk maar naar ASLR dat na XP gemeengoed is geworden). Windows is slechts 1 v/d OSen, en beveiliging is een constant kat- en muis spel. Voor XP had je al UNIX machines waar je op in kon bellen met guest accounts, of services die standaard allemaal moesten draaien "want dat was handig" (ja, ook Linux deed daar aan mee). Windows 9x was single user. Maar je kunt niet zeggen dat de opvolgers van XP (Vista, 7, en 10) geen verbeteringen hadden tov beveiliging, of dat Windows 2000 geen verbetering had tov NT 4.0.

Wel is het zo dat het internet opkwam en ineens machines een veel groter potentieel publiek hadden met alle gevolgen van dien. Ook is het zo dat niet iedere vooruitgang niet gepaard gaat met neveneffecten. En er liggen nog steeds kansen voor verbetering want bijvoorbeeld ECC geheugen is nog steeds verre van standaard.
De inhaalslag van XP waar ik het over had, begon tijdens XP's levensduur en heeft tot Windows 7 ergens geduurd. Toen het internet zich naar de massa aan het verplaatsen was (alleen makkelijker om Windows periodes te gebruiken)

De huidige inhaalslag is een jaar, misschien 2 geleden gestart?

Ging me niet om Windows 2000, maar om het jaar 2000 :P Tot aan het jaar ~2000 na Christus, werd security in de IT totaal niet serieus genomen.

Er zijn wel verbeteringen op veiligheidsgebied geweest. Linux liep daar een aantal jaar mee voorop op Windows. Maar... het was zoals je zelf ook al aangeeft. Niet serieus genomen.
En ook dat klopt niet. Vooral bij de Unixes is security altijd belangrijk geweest, zowel in de vorm van hardware (process and privilige separation, execute permission) als software (chroot jails, buffer overflow hardening). Zoals ik eerder al zei zijn side channel attacks relatief nieuw, voor AES had ik er nog nooit van gehoord.
Helaas schijnt ECC ook niet echt te beschermen tegen rowhammer. Normaal DDR4 van Samsung of SK Hynix waarschijnlijk dan weer wel (niet van Crucial, en ook niet low-power-geheugen). Dat is in elk geval het laatste dat ik erover gelezen heb.
Daarom moet je ECC ook combineren met memory address scrambling. Of je gebruikt Chipkill, die kan ook burst errors corrigeren.
...en dan van de genoemde fabrikanten!
Ik heb een apparaat die mij moet helpen productief code te kloppen. Die word regelmatig vers opnieuw geïnstalleerd omdat ik die vaker zelf sloop, dan dat ik iets van malware heb gekregen (tot nu toe staat de teller nog op 0).

Mijn PC is geen interessant target voor mass aanvallen, want er is niks leuks algemeens (creditcard info, bankgegevens, etc.) op te vinden alleen specifiek waar een gerichte aanval voor nodig is. Hiervoor is een gewone aintivirus goed genoeg.

Als een concurrent echt heel graag wil inbreken dan werkt de beste beveiliging toch niet. (Of je krijgt een patentenclaim binnen en dan moet je alsnog al je bedrijfsgeheimen op tafel gooien en maar hopen dat de aanklager jouw intellectual property netjes behandeld)

Mijn privé PC, dat is een ander verhaal. Die moet gewoon goed beveiligd zijn.

[Reactie gewijzigd door jorisvergeerTBA op 12 juli 2018 11:37]

Ik ben dan wel benieuwd hoe je met systeem om gaat als je dat vandaag de dag nog met regelmaat opnieuw zit te installeren. Ik kloot ook veel met mijn systeem aan zowel de software als hardware kant. Mijn originele Windows 10 install staat er nog op, welke geupgrade werd van Windows 8, welke geuprade werd van een ~2 jaar oude Win7 installatie. Alhoewel dit niet echte upgrades waren, mijn software/games en meuk staat niet op de OS disk en de meeste software gaat niet meer stuk bij ontbrekende registry entries e.d. Dus het is technisch een verse install eigenlijk.


Als je een code klopper bent, is security echt wel belangrijk. Zelfs als je niet getarget wordt, kan je op leuke darknest lijstjes terecht komen, en er is vanzelf iemand die jou werk interessant vind. Want ik neem aan dat je de software niet voor jezelf schrijft maar voor derden.

Lekker als men dus toegang krijgt tot jou source code omdat je de moeite niet neemt veiligheid serieus te nemen. Gister nog nieuws over die Hola addon en hoe simpel het eigenlijk is om je gebruikers/klanten de lul te laten worden van je eigen brakke security policies.
Is de gedachte misschien in je opgekomen dat het misschien ook te maken heeft met, upgraden voor velen zinloos is sinds medio 2014?

Zo heeft de consument natuurlijk weer een goede reden om in de (nabije) toekomst te upgraden.
Hier ben ik het dus ook mee eens. Gelukkig heb ik recentelijk een CPU upgrade gedaan, maar voorheen had ik echt elke cycle nodig tijdens het gamen, omdat ik anders FPS drops kreeg.
maar voorheen had ik echt elke cycle nodig tijdens het gamen
Dan sluit je toch gewoon je browser?
Ja, dat helpt idd, maar ik gebruik mijn browser regelmatig -> alt-tab en dan even een search voor een quest of guide oid.
Dan zie 't maar zo: je verliest (in je oude situatie of niet) dan misschien een paar FPS maar dat is nog niks vergeleken bij de FPS die je verliest als je PC onder de virussen, coinminers en cryptolockers zit (of erger; je rekening geplunderd, je PC stuk en dus geen centen meer voor een nieuwe = 0 FPS) ;)
Heb je gelijk in, echter doe ik op dat moment een reinstall van windows en is het probleem weg. Een geplunderde rekening lijkt mij vrij stug. Als je al drops hebt naar 40fps, dan zijn de paar extra FPS toch echt een hoop waard ;)
Een geplunderde rekening lijkt mij vrij stug.
Niks stugs aan maar realiteit en heel goed mogelijk
Daarvoor heb ik een extra laptop en iPad. Ik kwam er al snel achter dat dat een stuk beter werkte ... voor mij. Kon ik het er zonder extra performance in te leveren mooi naast houden.
Ik snap dat het voor sommige mensen en beroepen interessant en belangrijk is
Totdat je rekening wordt leeggeplunderd toen je ging telebankieren. Maar gelukkig draaide je Visual Studio een fractie sneller! *O*
Het is ook zo lekker zwart-wit allemaal... man man.
Ik wil je wel eens horen piepen anders als je computer onder de virussen zit, je bankrekening geplunderd is, je mail op straat ligt of je privé-foto's op het web te vinden zijn. Dat is allemaal (en véél meer dan dat) mogelijk met zulke vulnerabilities. Ja, daar offer ik graag 10-13% van m'n performance voor op ja. Nog wel meer ook als 't moet. Je kunt wel chagrijnen maar als 't je overkomt piep je wel anders :>
Oh ik snap wel wat je bedoelt hoor, alleen er zijn zat scenario's waarin het niet echt een issue is.
alleen er zijn zat scenario's waarin het niet echt een issue is
En hoe moeten de Chrome devs weten dat 't voor Pietje (vandaag, toevallig) geen issue is (maar morgen waarschijnlijk alsnog?). Ik bedoel: hoe zie jij 't voor je dat ze dan zo'n vulnerability aanpakken? Met een opt-in vinkje? Liefst nog met er de tekst "Ja, ik wil graag veiliger browsen ten koste van 10-13% van m'n performance" er bij zeker... enig idee hoeveel mensen dat vinkje dan gaan aanzetten? Sommige keuzes moet je gewoon niet aan de (eind)gebruiker over laten; soms moet je gewoon wat vervelends voor lief nemen ten koste van het groter goed. Simpel.
Ik doelde meer op het sentiment dat er patches zijn die negatief de performance beïnvloeden en dat sommige mensen dit irritant vinden.

Ben benieuwd of dit dan ook voor Meteor applicaties gaat gelden.
Oh dear, dat is niet echt een populaire mening hier op tweakers. :)
Net als met het patchbeleid op Windows....

Maar ik snap het wel.
Als je zo min mogelijk geheugen wilt gebruiken dan kun je beter geen chrome gebruiken. Door de sandboxing heeft deze browser altijd al een redelijk hoog geheugengebruik gehad.

Er is keuze in de browserwereld en als je licht wil browsen kun je volgens mij beter firefox gebruiken, maar dat kun je misschien zelf beter even opzoeken. Zelf gebruik ik wel gewoon chrome en neem ik het geheugengebruik voor lief. Als je voldoende hebt merk je er niks van.
Bij mij is bijna de helft van mijn 32GB RAM standaard in gebruik door Chrome.. :|
Heb je meer dan 100 tabs open soms?!
Niet meer dan 100, maar over de 50 zit ik over het algemeen nogal vlug.
Helaas 🥜 kaas, veiligheid gaat boven performance. Tijd voor een andere browser of workstation. Visual Studio nou ook weer niet zo demanding en Chrome gebruikt nu eenmaal veel ram.
Ik dacht dat dit op OS niveau al kon worden afgevangen?
Site isolation gaat verder dan dat, doordat pagina's van verschillende websites in aparte processen en eigen sanboxes worden ondergebracht. Dat geldt onder meer voor tabs en iframes. Volgens Google heeft de maatregel tot gevolg dat Chrome ongeveer tien tot dertien procent meer geheugen gebruikt.
Dat is best flink, hopelijk gaat dit dan ook niet ten laste van de snelheid?
Ik dacht dat dit op OS niveau al kon worden afgevangen?
[...]
Dat is best flink, hopelijk gaat dit dan ook niet ten laste van de snelheid?
Het hele idee van de spectre-aanvallen is juist dat het ene proces de data van een ander proces (dus ook het OS zelf) kan lezen, terwijl het OS er weinig aan kan doen zonder fors in te leveren op het gebied van performance (pakweg 10% tot 35%) en zelfs dan is men nog net helemaal veilig.

Op OS-niveau kan men alleen een scheiding aanbrengen tussen verschillende processen. Nou gebruikt Chrome inderdaad 1 proces per tabblad, maar dit zijn child-processes van het hoofdproces van Chrome, waardoor er dus veel (lees, meer dan genoeg voor een aanval) informatie van het Chrome-hoofdproces wordt doogegeven aan het kind.

De hardware kan de pijn enigszins verzachten door voor ieder proces een eigen ruimte (context) te maken waarin een bepaald groepje processen kan draaien. Helaas is het zo dat de betreffende processor maar net de PCID-feature moet hebben en dat zelfs dan de hardware slechts 4096 contexten beschikbaar kan stellen.

Heeft de CPU de PCID-feature en draait men niet al teveel losse processen (lees iedere open tab is een proces met Chrome), dan kijkt men aan tegen een 5% verlies van performance. Heeft men de PCID-feature niet of gaat men meer dan 4096 processen starten, dan kijkt u aan tegen de eerdergenoemde 10% tot 35% verlies van snelheid.

Google neemt dus gewoon het zekere voor het onzekere en voegt maar gewoon een extra laag beveiliging toe. Google wil geen rechtszaken van gebruikers omdat zij nalatig zijn geweest bij het bouwen van, misschien wel het belangrijkste stuk software dat de hele wereld nu gebruikt (de Chrome browser). Pech dus voor de performance.... Dit hele debacle is tevens de schuld van Intel en niet van Google.

[Reactie gewijzigd door vliegendekat op 12 juli 2018 11:32]

Heb je toevallig ook bronnen voor dit performance verlies, en dan het liefst geen synthetische benchmarks. Het zijn namelijk cijfers die je veel hoort, maar veelal onderbouwd met synthetische benchmarks en / of totaal onrealistische (test) workloads, die in ieder geval in mijn ervaring totaal niet representatief zijn voor het daadwerkelijke verlies in bijvoorbeeld een gemiddelde bedrijfsomgeving, on-premise of bijvoorbeeld in een datacenter. Maar ook niet representatief zijn voor bijvoorbeeld gaming pc's of het performance verlies dat tante ingrid heeft bij het browsen of het typen van een briefje.

Ik heb hier vooral zakelijk, maar ook privé testen voor uitgevoerd. En ik kom eigenlijk bij realistische workloads voornamelijk op verliezen van 0 tot 5%, zowel bij kantoorwerk scenario's (beetje browsen, office applicaties, erp e.d.), gaming tests (voornamelijk prive) maar ook bij volledig operationele vSphere of Hyper-V clusters zie ik gemiddeld in de praktijk zo'n 0-5% verlies, en dan vaker dichter bij de 0% dan bij de 5%. Enkel bij bepaalde niche scenario's (hoog aantal i/o's) is het verlies wat hoger (tot 15% voor die speciifieke workload).

[Reactie gewijzigd door Dennism op 12 juli 2018 11:53]

Heb je toevallig ook bronnen voor dit performance verlies, en dan het liefst geen synthetische benchmarks. Het zijn namelijk cijfers die je veel hoort, maar veelal onderbouwd met synthetische benchmarks en / of totaal onrealistische (test) workloads.
Bron: LKML (linux kernel mailinglist), logisch nadenken met gezond verstand.

Het vervelende is dat er eigenlijk geen getal op te plakken is, want het is compleet afhankelijk van de workload die een machine heeft. Het probleem is dat de pipelines en het cache van de processor leeg moeten bij iedere switch naar een ander proces om te voorkomen dat er op deze plaatsen data van het ene naar het andere proces kan weglekken. Dit kost gewoon erg veel tijd.

Al men PCID heeft, dan biedt de hardware de garantie dat het ene proces niet bij de data in de pipelines of het cache van een ander proces kan. Deze checks kosten minder tijd dan het flushen van de pipelines en het cache, maar ze kosten eveneens nog steeds tijd en alles dat tijd kost, heeft impact op de performance.

Het is zeer moeilijk om te zeggen hoeveel tijd het precies gaat kosten, omdat impact op de performance wordt bepaald door het aantal context-switches dat uw software van uw systeem vereist.

Draait u een game en zit alles in ram, dan zal het allemaal wel meevallen, maar draait u een database of webserver die bij elke request een operatie op de harddisk moet doen, dan gaat de performance misschien nog wel verder naar beneden dan die 35% procent. Elke operatie op de harddisk vereist namelijk een context-switch, zodat de kernel zijn ding kan doen.
Ik heb hier vooral zakelijk, maar ook privé testen voor uitgevoerd. En ik kom eigenlijk bij realistische workloads voornamelijk op verliezen van 0 tot 5%, zowel bij kantoorwerk scenario's (beetje browsen, office applicaties, erp e.d.), gaming tests (voornamelijk prive) maar ook bij volledig operationele vSphere of Hyper-V clusters zie ik gemiddeld in de praktijk zo'n 0-5% verlies, en dan vaker dichter bij de 0% dan bij de 5%. Enkel bij bepaalde niche scenario's (hoog aantal i/o's) is het verlies wat hoger (tot 15% voor die speciifieke workload).
Zo te zien heeft u dus een workload waarin u "mazzel" heeft en de schade meevalt. Blij mee wezen. Ik heb zelf een synthetische benchmark gedraait en in een absurd scenario zelfs een verlies van 43% gezien. Inderdaad bij een hoog aantal IO's. Bij een andere synthetische benchmark met een krankzinnig hoog aantal threads kwam ik uit op 19% verlies. Met PCID aan bleef de schade op beide gevallen steken op 4% tot 6%.

[Reactie gewijzigd door vliegendekat op 12 juli 2018 12:13]

LMKL heb ik hetzelfde probleem mee, alle (of in ieder geval de meeste) daar genoemde cijfers zijn synthetics. Ik, in prive, of onze klanten (zakelijk) wil niet weten wat ik in een theoretische situatie zou kunnen verliezen in een worst case scenario, maar wat we verliezen bij ons normale gebruik (het ene gebruik is natuurlijk het andere niet.

Synthetics geven in principe alleen een antwoord op de mogelijke maximale performance in een bepaalde situatie. Iemand ziet 30% staan en gaat roepen "Intel verliest 30% performance!!!1111!!11", terwijl het goed mogelijk is dat er op zijn workload 0% verlies is. Ik heb echt het gevoel dat er zoveel misinformatie het net op wordt geslingerd over bijv. Spectre en Meltdown performance verlies, die in 9 van de 10 realworld situaties niet eens in de buurt komt van het vaak rond geschreeuwde "Tot wel 35% verlies" verlies.
Zo te zien heeft u dus een workload waarin u "mazzel" heeft en de schade meevalt. Blij mee wezen. Ik heb zelf een synthetische benchmark gedraait en in een absurd scenario zelfs een verlies van 43% gezien. Inderdaad bij een hoog aantal IO's. Bij een andere synthetische benchmark met een krankzinnig hoog aantal threads kwam ik uit op 19% verlies. Met PCID aan bleef de schade op beide gevallen steken op 4% tot 6%.
Dat ik, of onze zakelijke relaties "mazzel" zouden hebben geloof ik niet zo. Dit zijn waardes (grotendeels amper verlies per workload (de genoemde 0-5% en dan vaker 0 dan 5%, soms een uitschieter met wat meer verlies, de genoemde 10-15%) die ik consistent zie over een redelijk aantal zakelijke MKB omgevingen (50 tot 1000 seats) met applicatie servers, RDS servers, webservers, RDS servers, database servers. Als het alleen mijn prive PC zou zijn zou ik inderdaad nog over "mazzel" kunnen spreken, heb je helemaal gelijk in. Maar consistente cijfers over een paar duizend werkplekken en bijbehorende workloads dan doet dat mij toch echt denken dat de theoretische (synthetische) verliezen de connectie met de cijfers in de praktijk totaal verloren hebben en zeer overdreven worden in de berichtgeving.

Zeg bijvoorbeeld zelf, jij ziet 43% en 19% verlies in synthetics, maar hoeveel meetbaar / merkbaar verlies heb jij zelf op bijvoorbeeld een dag werken in real world workloads.

[Reactie gewijzigd door Dennism op 12 juli 2018 12:42]

U heeft zo te zien vooral de typische office-MKB workloads. Daar gaat u weinig verschil merken, want de invloed van spectre en meltdown zijn voor deze workloads weinig interessant. Ik kan echter niet uitsluiten dat het in de toekomst nog relevant wordt.

Zoals het er nu uitziet, zijn de de database- en storage-servers de enige plaatsen waar u in dergelijke omgevingen noemenswaardige problemen zou kunnen ondervinden.
Voor zover ik weet, is bij het gemiddelde MKB de impact weinig relevant omdat andere factoren zoals de netwerkverbinding of de beeldcompressie van een RDS (ik neem aan dat u Remote Desktop Servers bedoelt) vaak domineren. Beiden vereisen relatief weinig context-switches en meestal heeft het MKB toch meer rekenkracht in huis dan dat zij strikt nodig heeft.

Echter zit ik zelf niet in de MKB-wereld, dus dergelijke informatie heb ik niet voor handen. Zelf werk ik vooral aan de backends van grote webservices die tijdens kantooruren honderden requests per seconde krijgen en daar is de impact wel merkbaar, maar (nu nog) meestal rond de 10%.

Houdt er echter wel rekening mee dat het deksel net pas van de beerput af is en nog lang niet alle vormen van deze processorbugs zijn gevonden. Laat staan opgelost en gepatcht. Er zijn al een paar nieuwe varianten ontdekt waar de huidige patches niet tegen werken en er komen in de toekomst, met een aan zekerheid grenzende waarschijnlijkheid, nog wel meer lijken uit de kast vallen met betrekking tot "speculative execution".

Ik heb geen idee wat er daardoor nog performance penalty's bij kan komen, omdat alle software-mitigations anders dan, "flush cache, flush pipelines" geen definitieve oplossingen zijn en in het (theoretisch) ergste geval gaat uw performance zelfs naar 1/20-ste van uw huidige performance. Nou zal de soep niet zo heet worden gegeten als dat deze wordt opgediend, daarin geef ik u zeker gelijk, maar u leest wel correct dat elke CPU van vanaf ongeveer 1998 zonder speculative execution (en dus vrij van deze problemen) het in bepaalde gevallen beter kan doen, dan een moderne cpu met spectre-patches. Speculative execution is namelijk één van de fundamentele technieken die voor de speedups van de laatste 20 jaar heeft gezorgd. En daar is, door ontwerpfouten in veel processoren, nu dus iets mis mee.

Wat ik wel zeker weet is dat deze ellende bij ons zal blijven, totdat Intel en AMD hun processor-designs hebben aangepast en iedereen zijn oude processoren heeft vervangen.
Dit gaat dus zo nog 10 tot 15 jaar duren en gedurende die tijd zullen wij nog een aantal keren nieuwe varianten zien opduiken, waar de huidige software niet tegen bestand is.

Ik hoop dat u nu begrijpt waarom de berichtgeving klinkt alsof het van een aantal onheilsprofeten af komt, want "wij" als mensheid zitten inzake speculative execution wel degelijk met een heel groot probleem. Aan de andere kant hoop ik ook dat u nu begrijpt, dat de auteurs van deze patches niets anders kunnen doen dan het maken van een synthetische benchmark, om vervolgens te concluderen "dat het allemaal wel meevalt" en dat de meeste mensen in de praktijk geen tot weinig problemen zullen ondervinden. Maar u zal maar een grote bank, overheid, Equens (alle pin-betalingen), Apple, Microsoft of Google zijn en dan ineens ontdekken dat u door een paar stomme fouten van Intel en AMD, nu 1/3e van uw serverpark mag bijzetten door een paar patches....

Het zijn de systemen waarop men werkt met gevoelige data, of grote bergen data en code van veel verschillende auteurs, die echt geraakt worden. Dus: alle cloud-providers, banken, medische dienstverleners, payment processors, en zo voort. Dat zijn minstens evenveel computers als er bij de mensen thuis staan.

[Reactie gewijzigd door vliegendekat op 12 juli 2018 13:59]

Ik ben het zeker met je eens dat de impact voor reuzen als Google, Amazon, Microsoft een stuk groter is dan voor de gemiddelde consument, of zelfs zakelijke gebruiker.

En dat we met een groot probleem zitten is natuurlijk hopelijk voor iedereen duidelijk, totdat er nieuwe generaties cpu's komen zal het pappen en nathouden zijn met microcode, OS patches en software patches, heb je 100% gelijk in. En dan nog de vraag of dit wel 100% opgelost kan worden zonder ons terug te brengen naar de digitale spreekwoordelijk "steentijd", ook daar heb je zeker gelijk in. Dat er mogelijk nog een berg nieuwe lijken uit de kast gaan vallen heb ik hier ook al vaker voor gewaarschuwd :)

Mijn punt is echter een beetje, wat nu naar mijn mening veelal juist gemist wordt. In plaats van consumenten correct te berichten en aan de te geven dat dit ernstige lekken zijn, beveiliging benodigd is, en dat voor de consument de performance impact nihil is (in ieder geval op dit moment). Zie je dat hier, maar ook op andere sites er juist iedere keer weer een berg "doomsayers" op staan in de reacties en soms zelfs in de nieuw berichten zelf die beginnen over "Tot 35% performance verlies!!111!!!11!" "Installeer geen patches want je PC wordt 30% langzamer!!!!" zonder enige begeleidende context dat deze verliezen alleen gezien worden in zeer specifieke workloads, waardoor iedereen die dat leest en wat minder ingewijd is gelijk denk dat als hij de patches installeert zijn favoriete games ineens 25 of 30% langzamer kunnen lopen of dat zijn PC niets meer waard is. Hierdoor weet de consument, maar ook zakelijke gebruikers, eigenlijk niet meer wat nu daadwerkelijk echt te impact is voor hem. En dat wordt mijn inziens regelmatig slecht gecommuniceerd.

Ik bedoel bericht rustig over de performance impact, maar lever er ook de juiste context (Impact X bij workload Y) bij en geen blanket statements van "Tot 35%!". Ingrid die aan het browsen is zal namelijk echt geen 35% performance verlies hebben, Microsoft of Amazon die voor Pietje Puk B.V. een i/o heavy database workload in Azure of AWS draait zal mogelijk echter wel een flinke impact hebben

[Reactie gewijzigd door Dennism op 12 juli 2018 14:29]

AWS, had er juist door de manier waarop men het heeft opgezet, geen last van spectre en dergelijke. Ze hadden wel last van Rowhammer, maar dat is een totaal ander verhaal.

Ik snap uw punt over het correct informeren van consumenten en zakelijke partners...

Ik pak het meestal als volgt aan:
Wat spectre en meltdown zijn leg ik aan leken meestal uit aan de hand van een spoorwegennetwerk rondom een militaire basis of fabriek en stel dan dat je een hoop af kan leiden door te observeren wat er in en uit gaat. Daarna stel ik dat de boel inderdaad trager kan worden door te eisen dat een station volledig moet worden vrij gemaakt van passagiers, koffers, tassen, zwerfvuil en dat alle afvalbakken geleegd moeten worden, voordat de volgende trein er mag stoppen of er zelfs maar doorheen mag rijden. Hoe erg de boel vertraagt, is grotendeels afhankelijk van de frequentie waarmee u dit doet. Één keer per dag? Geen probleem! Ieder uur of vaker? Groot probleem! Maar in plaats van één keer per dag praten we in een computer dan wel over minimaal 10-duizend keer per seconde of vaker, terwijl we maar pakweg 2 miljard dingen per seconde kunnen doen en pakweg een paar miljoen keer een andere trein door het station kunnen sturen.

Ik zeg er ook altijd bij, dat als u dit soort informatie van mij moet vernemen, dat u dan gewoon de patches moet installeren en braaf moet doen wat de Microsoft- of Apple-goden u min of meer opdragen. Als de boel daarna alsnog te traag wordt, kunt u het beter tolereren en een paar honderdjes of duizendjes aftikken voor nieuwe apparatuur waarmee u de lasten verlicht of waarin dit alles gerepareerd is. De schade die u zich mogelijk op de hals haalt door de patches en updates niet te installeren is waarschijnlijk vele malen groter dan die paar honderdjes of duizendjes.

Verder onderstreep ik vaak ook heel erg het feit dat het gebruik van anti-virussoftware en adblockers, het halen van updates, het uitschakelen van javascript (en als dit niet kan, dan moet men erop aandringen bij de leveranciers), het niet insteken van onbekende usb-sticks of BYOD-apparaten, het niet lukraak openen van alle bijlagen en het niet installeren van allerlei software software en frameworks zonder uitgebreide inspectie (en ja dat geldt ook voor de developers met al hun "kleine" rot-tooltjes en tienduizenden bibliotheken die men aan elkaar lijmt), door deze lekken nu nog belangrijker is geworden dan ooit tevoren. Immers: Als u hier geen gade op slaat, is het alsof u alles en iedereen toestaat om mee te kijken (en schrijven) terwijl u uw pincode of wachtwoord intoetst en daarna uw bankpas in het apparaat laat zitten. Dit is immers precies wat de meltdown en spectre bugs in de chips mogelijk maken.
Google neemt dus gewoon het zekere voor het onzekere en voegt maar gewoon een extra laag beveiliging toe. Google wil geen rechtszaken van gebruikers omdat zij nalatig zijn geweest bij het bouwen van, misschien wel het belangrijkste stuk software dat de hele wereld nu gebruikt (de Chrome browser).
Dat het op dit moment de meest gebruikte browser is (55%). Ja leuk, maar dat maakt het nog niet het belangrijkste stuk software.
Dat het op dit moment de meest gebruikte browser is (55%). Ja leuk, maar dat maakt het nog niet het belangrijkste stuk software.
Wat doen de meeste mensen op hun computer?
Voor praktisch elke gebruiker is het wel degelijk het belangrijkste stuk software.
Zonder OS doet dat stukje browser software anders niets.
Zonder OS doet dat stukje browser software anders niets.
Het feit dat Chrome op bijna ieder OS draait (Windows, Linux, OSX, Android, iOS, enz.) en dat men het ook op meerdere systemen gebruikt, geeft aan dat het OS minder relevant is dan de Chrome browser zelf.
Veel succes met het gebruiken van de Chrome browser op een apparaat zonder OS erop.
Wordt een willekeurige OS opeens toch wel belangrijk.

Beetje kip - ei discussie.
I.p.v. Chrome kan men ook andere browsers gebruiken en i.p.v. de ene OS zijn er nog tig andere OS-en

Dus als Chrome er morgen niet meer is/niet meer werkt, dan vergaat de wereld gelukkig niet, want dan gebruikt men wel een andere browser.
Mijn laatste antwoord in deze flame-war:
Het zal de user nu een worst wezen wel OS een machine draait, als de machine maar een variant van Chrome kan draaien. Daarmee is voor de meeste gebruikers het OS ondergeschikt aan de browser geworden.
Flame-war?
Nee hoor. Alleen die adoratie, daar heb ik wat tegen.

En dat de Chrome browser zoveel markt aandeel heeft, komt volgens mij alleen maar doordat het met Android als standaard browser wordt meegeleverd.
Niet, omdat het zo'n goede browser is. Dat is voor mij persoonlijk FF
Om het nu het belangrijkste te noemen.. het is maar een browser. Marktaandeel staat niet gelijk aan belangrijkheid. Ik vind software op mainframes bij banken, defensie, etc, toch iets belangrijker.
Ik dacht dat dit op OS niveau al kon worden afgevangen?
Meltdown: Ja, door KPTI toe te passen. Voor Spectre v2 tussen processen kan het OS wel wat doen, maar voor v1 en v2 (en ook v1.2, v1.2 en v4...) ben je binnen het zelfde proces wel nog steeds kwetsbaar. Dit is dus in situaties waar je binnen een proces meerdere dingen hebt lopen die van buitenaf geladen worden, die niet van elkaar mogen lezen (zoals je Javascript VM in je browser). Dan kan je dat of in software oplossen, of bepaalde hardware features uitschakelen met alle nadelige performance effecten van dien (en die kunnen alleen v2 en v4 oplossen ten koste van flink wat performance). Blijkbaar heeft Google nu in Chrome voldoende software gebaseerde oplossingen/workarounds gestopt zodat het weer veilig zou moeten zijn.
Denk hierbij ook aan meer geheugengebruik en kortere accuduur. Vooral dat laatste is een dingetje voor mensen die reizen.
Dit zal relatief eenvoudig geweest zijn voor Chrome aangezien ieder tabblad toch al in zijn eigen proces draaide.

Bij Firefox is dat niet het geval, vooral door de afweging tussen snelheid en geheugengebruik. Er is wel een project aan de gang om tabbladen verder te scheiden tussen processen. Hiervoor wordt hard aan de weg getimmerd om het geheugengebruik van individuele processen te verlagen.

Dat wil natuurlijk niet zeggen dat Firefox niet ook maatregelen heeft tegen Spectre. Zo zijn de JITs er op aangepast (zie de javascript.options.spectre opties in about:config).

[Reactie gewijzigd door Mitsuko op 12 juli 2018 11:19]

waarbij de laatste 1 procent wordt gebruikt om prestaties in de gaten te houden en zo nodig te verbeteren

zeggen ze hiermee dat ze 1% van de gebruikers (nog) niet beschermen tegen spectre? en gaan ze dit in de toekomst wel doen?
ik snap dat je metingen nodig hebt, maar ik vind dit een klein beetje raar.
Of dat ook in de iOS-versie gebeurt, vermeldt de zoekgigant niet.
Onder de kap is het gewoon Safari, dus dat zal puur van Apple en iOS afhangen.
Ik lag me stuk, dacht ik vorig jaar dat ik aan 16gb ram genoeg had en 64gb overkill is blijkt dat ik toch beter 64gb ram had moeten kopen. Nu is het echt onbetaalbaar geworden.

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True