Hacker News Reader

Comment by Valmar | Hacker News Reader

Said current patches haven't been merged. Just posted to the mailing list for review.

Retpolines for Spectre, and PTI for Meltdown, are still in the kernel. Linus doesn't have too much disagreement with them. It's the IBRS / IBPB code for Intel's CPUs that Linus has a problem with.

Also, not everything can be mitigated in microcode, for many reasons, not all of which I understand myself. Sometimes, only a fundamental hardware-redesign can fix the issues proper.

View on HN

Well, for one thing, modern CPUs aren't microcoded much. Real microcoded CPUs went out with the 1980s. The microcode in today's fast CPUs is mostly initialization, and maybe emulation support for some instructions nobody uses any more, like decimal arithmetic or 16-bit mode. The microcode can maybe turn some stuff off and tweak some tuning parameters. Anyone know what Intel's "fixes" really do?

Wat? All the major hardware manufacturers from Intel to the hundreds of no name ARM licensees fix and cover up major issues in silicon with fixes in microcode (unless most chips from a particular mask/process are too screwed up, see Intel's 7nm process).

Doing otherwise would throw the onus onto kernel maintainers for Windows, Linux, and the various BSD distros, and they don't want a crapton of one off fixes for the plethora of CPU errata that Intel and others patch in microcode.

Microcode is a little more capable than that. See https://media.ccc.de/v/34c3-9058-everything_you_want_to_know...

Edit: s/Intel m/M/

That talk is about AMD.

All instructions that decode into more than four micro-ops still go trough microcode. Typically 5% of micro-ops are still coming from the microcode sequencer even in modern architectures.

Compiler has large effect. Common operations like CALL and PUSH go trough microcode even in m64 but there are alternatives. Many floating point operations have assists. Nonoptimal memory alignment might go trough microcode.

Reply on news.ycombinator.com