One of you needs to build a secret lair and plot to take over the world so that the two of you can become arch-nemeses. The Intel HT spat from a couple years back just wasn't nearly epic enough to hold my attention.
First of all, calling me a "crypto person" is probably giving me too much credit. Two semesters of number theory (the second with an explicit crypto slant) make up the extent of my formal education on the topic. I've taught myself a fair bit beyond that, but I've never published any papers or anything.
That said, I'm mostly but not entirely on cperciva's side. At the granularity level of "disable HT" versus "put head in sand", I favor the former and think that Linux's choice of the latter was irresponsible. I also think all the ad hominems regarding self-promotion, cribbing from DJB, etc., were off the mark. However, your observation that a local privilege escalation vulnerability of any sort would be a more serious issue than the HT vulnerability, and that such is virtually guaranteed to exist, was a good one. The right answer, perhaps, would have been to disable HT in vanilla FreeBSD, and then re-enable it for PC-BSD.
The right answer, perhaps, would have been to disable HT in vanilla FreeBSD, and then re-enable it for PC-BSD.
I wasn't aware of PC-BSD at the time, but if someone had come to me and said "we're shipping a version of FreeBSD aimed at desktop users", I would have encouraged them to leave HT turned on by default. I always did my best to point out that this issue was not relevant to single-user systems, that all FreeBSD was doing was changing the default behaviour, and that in many cases it would make sense for system administrators to re-enable HT via the sysctl... unfortunately, the nuances tended to get lost as the story spread, so all most people heard was "Colin says that HyperThreading is evil and FreeBSD is disabling it".
