RT @lavados@twitter.com: We systematically analyzed #Meltdown, #Spectre and #Foreshadow and came across interesting new transient execution attacks: https://arxiv.org/abs/1811.05441 Great collaboration with @cc0x1f@twitter.com @jovanbulck@twitter.com @misc0110@twitter.com @mlqxyz@twitter.com @dimonoid@twitter.com, Frank Piessens :)
Angeblich hätten die meisten Entwickler gar nicht mehr entsprechende Hardware verfügbar und überhaupt sei die Architektur hoffnungslos veraltet. Das sicherlich in Teilen korrekt sein. Dennoch enthält diese Argumentation einen gehörigen Anteil von Arroganz. Was ist beispielsweise mit #Meltdown, #Spectre sowie in Teilen auch #Spectre-NG? Diese Fehler sind immer noch nicht vollständig behoben und daher gültige Sicherheitslücken. Und was ist mit der rein menschlichen Komponente? Man sollte meines Erachtens niemals vergessen woher man kommt und wie die Wegstrecke dazu ausgesehen hat. Oder ist es inzwischen auch probat nahezu überall schnellstmöglich zu "vergessen"? Gibt ja genug "Ressourcen" und daher können wir auch ganz verschwenderisch damit umgehen. Was ist dann mit der umwelttechnischen Komponente? Also jedwede als "alt" markierte Hardware-Komponente auf den Müll werfen? Prima, trägt ja ordentlich dazu bei wieder Andere zu belasten und beispielsweise Elektroschrott an die Küsten Afrikas zu spülen.
At work we have the same hardware for each of the developers (corporate-mandated Windows laptops). We develop in GNU/Linux VMs. We received them when we were purchased back in April by a larger company.
There's a full compiler stack I wrote for the development of certain systems. It uses Saxon and is therefore really heavy on resources (and syscalls). Lots of inefficiencies. (Don't write your next compiler stack in XSLT. I wouldn't have if I knew it was going to become what it is today.)
I noticed that newer devs' systems, with identical configurations, were taking more than twice the amount of time to compile the same software using this stack. A coworker and myself spent a bit of time debugging and it was eventually found to be the microcode. Once my coworker updated his Intel microcode and BIOS to include the Spectre and Meltdown mitigations, the virtualization performance was terrible---over 100% performance degredation in this case (~5m for a normal build without mitigations, ~12m after mitigations). That's far worse than any benchmarks I've read. Disabling the microcode mitigations restored performance to previous levels.
So evidently disabling a big chunk of the #spectre and/or #meltdown patch in Linux can be accomplished by passing 'pti=off' or 'nopti' to the kernel as a boot parameter.
Eventually I'm gonna find out if this makes my machine usable again once it hits swap. Because right now it's become absolutely insufferable.