Hacker News new | past | comments | ask | show | jobs | submit login

What he said isn't wrong, this new ucode changes fencing and branching prediction semantics regardless of using the instructions added for spectre.

The problem is varied. While most people should run the new ucode and pending kernel and toolchain fixes, not all must. Most businesses buy computers on rated performance, and they are about to take an unexpected performance haircut. Intel ucode isn't really optional, as there is no public change log and it is unknowable what critical stability fixes are within. so even in a closed system you can't selectively ignore it without some amount of negligence. This presents a big problem for HPC and other closed systems.

IBM, a more professional and customer focused HPC vendor, is offering a firmware flag to preserve pre-spectre behaviors. Most closed monolithic HPC clusters can ignore these vulns and the associated nvidia one.

I wonder if this will end with Intel selling a lot of new chips, or Intel having to issue massive recalls. I doubt Intel will be able to be able to get away with discount/trade-ins without some serious legal complications.

I doubt we'll see entire data centers move to AMD as that would get stupid expensive. For the short term, we might see data centers order extra AMD blades and changing their provisioning systems to pin high IO tasks to those machines. And that's for people who co-locate or host their own stuff.

I'm interested to see how this affects Infrastructure providers who abstract a lot of that away, like AWS, DigitalOcean, Rackspace and others.

They might even be working on analysis and auto-migration to move high IO nodes to higher performance machines transparently. It will be interesting to see what hosting providers start blogging about in the next few weeks.

The first would set a strange precedent without some kind of good faith amends by intel, and so far they have signaled apathetic callousness. I think the legal implications haven't even begun to arise yet because large users are still scrambling to understand the impact and deal with what they have on hand. I speculate some kind of recall or prorate program will come out of it in time.

Dieselgate is the closest thing I can think of recently where a product was marketed primarily on performance that was later rescinded through mechanical and/or software clamping. I wonder if there will be any FTC action for consumers.

Separate from the above thoughts, intel was already testing customer patience with Skylake. It wasn't a substantial performance increase, but it was a substantial pricing increase. A lot of that, because, in merging the 4S (E5-4xxx) and 8S (E7) into one marketing line, a majority of users are paying big premiums for unwanted UPI scalability to get clock speed, cores, and caches they do want. They also gambled poorly on clamping I/O lanes to fight GPU, and with omnipath which is a niche at best. History will most likely judge Krzanich poorly. I expect AMD and IBM will have a good couple years coming up.

Doesn't the microcode expose new MSRs to control branch prediction? If you don't want to, don't clear the cache.

It's hard to make sense of what Intel are doing in the ucode since communication has been so poor, but "LFENCE terminates all previous instructions" has been variously reported, and there are rumblings that RET or conditional jumps have been changed too. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886367#17

Intel deserves an extra pwnie award just for the way they handle ucode without changelogs.

No disagreement that reverse engineering Linux patches is not the optimal disclosure policy.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact