OK, this speculative execution issue has turned the birdsite into an unreadable mess of b-s and mis-interpretation. Yesterday there was some signal (e.g. @Kensan and @csirac2) but now… oh dear. There are people acclaiming Paul Graham as the voice of reason :D

@cynicalsecurity @csirac2 Oh and yeah: my "contributions" were basically pointing to what other people have said/done and tricking D. Gruss into explaining why he named it .

So no original work from me. My excuse is that technically I am still on vacation until Monday :p

@Kensan I confess to liking @csirac2’s work in listing precursor papers a lot. Now they are all backslapping each other on the birdsite about their brilliance and/or how they always knew and/or other assorted noise.

My only question is why blow it out of all proportion? Yes, if you have VMs it is a real bummer but, objectively, VM security has always been a matter of faith rather than technology (exception LPARs). I believe @mulander mentioned Theo’s VM rant from 2007. Spot on.

@cynicalsecurity @mulander @csirac2 What I like about the issues is that they illustrate design flaws independent of the maker even though everybody is caught up on Intel. I find the technical side of the attacks interesting but then again they fall right into my area of interest. That being said, I am sure there are other bugs released in the meantime which are more relevant to end users.

@csirac2 @mulander @cynicalsecurity Maybe they will raise some attention to the performance fetish. It would be great if I could decide for myself which trade-offs for performance, flexibility/usability, security etc I want to make.


@cynicalsecurity @mulander @csirac2 What I also like about the curated list of papers is that there has been a lot of work by different people in this area which goes back a long time. Eg. Colin Percival's paper from 2005 really demonstrated that Hyper-Threading is problematic.

@Kensan @csirac2 @mulander I shall be painfully honest: I *never* understood the existence of Hyper-Threading. Seriously, I fundamentally cannot understand its “raison d’être” while at the same time I understood perfectly well the SPARC threading concept in the T-series and how it applied to Java.

@cynicalsecurity @mulander @csirac2 It is an illusion that sells really well: zOMG, cat /proc/cpuinfo shows twice the number of cores!

Lately BIOSes have removed the option of disabling HT so we had to implement this in Muen *sigh*

@Kensan @csirac2 @mulander My confusion was always around this idea that somehow it was “two cores for the price of one” where clearly it could not be the case: there was still only one execution unit so you now had on-core multitasking managed by…
microcode! The feeling was always “this cannot work properly” not to mention the “why would I want to do that?”

I’d love a good technical explanation as to why but all I can think of is “marketing solution by the microcode group”.

@cynicalsecurity @mulander @csirac2 I do not really know enough about the details but my impression is that it was a cheap way to get a little bit more PERFORMANZ (20-30% depending on the combination of workloads?) *and* simultaneously create the illusion of having a full new core.

@csirac2 @mulander @cynicalsecurity However it is apparent that so many more resources are shared between logical cores than physical cores that it is bound to be problematic in so many use cases. At least with HT there is a way to choose not to go down this path and choose a different tradeoff by disabling HT cores. This spares us a lot of complexity.

@cynicalsecurity @mulander @csirac2 Not wanting to appear like bashing Linux as I am sure there a other motivations/good reasons and they make different tradeoffs but as an illustration: it even has a HT-aware scheduler so the complexity is rooted in the Hardware feature and all users are paying for it. ¯\_(ツ)_/¯

@Kensan @csirac2 @mulander OK, what does an HT-aware scheduler do? Does it find “compatible” processes to maximise performance per-core?

@Kensan @mulander @cynicalsecurity sorry to dig up an old thread; I've since discovered Agner Fog's amazing asm/C++ Microarchitecture Optimization manuals - and he has some great blog posts too, including this one on hyperthreading: agner.org/optimize/blog/read.p

@cynicalsecurity @mulander @csirac2 I do not know. Reducing stall time due to IO-bound Hyperthreads?
It's just an odd artifact but as already mentioned, at least in this instance you can make different tradeoffs.

@cynicalsecurity @Kensan @csirac2 @mulander Isn't HT is just the same thing as the SPARC's, except for only two threads per core instead of four?

@amiloradovsky @Kensan @csirac2 @mulander my (limited) understanding of the SPARC threading model was that it made threads more efficient and it can be made to look like virtual processes. Perhaps I never understood it properly but I thought it did not expose itself as full processors?

@cynicalsecurity @amiloradovsky @Kensan @csirac2 @mulander AFAIK, the whole point of virtual threads, is to reduce the overhead associated with context switching.

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!