Intel's "redundant prefix issue"

Posted Nov 27, 2023 15:42 UTC (Mon) by farnz (subscriber, #17727)
In reply to: Intel's "redundant prefix issue" by paulj
Parent article: Intel's "redundant prefix issue"

But it's those specifics that you care hugely about, and not the broader functional units; great, the LSQ is the same, but now you've got a completely different set of interactions with microcode to last time, because the hardware designers are confident in different bits of it, and have attached microcode hooks to different bits of the LSQ. And no, I don't believe Intel does have internal documentation for microcode writers; IME, microcode is written by people embedded in the CPU design team, and they use the actual design sources as the documentation.

I suspect that Intel doesn't have anything it can release as a microcode "interface"; you're asking them to write this documentation, unlock the microcode (making reverse engineering their CPUs easier for competitors) and for no gain to Intel. This isn't something Intel will do, for obvious reasons - it's all costs to them, for no gains, and it's stuff they have to redo for each generation.

Intel's "redundant prefix issue"

Posted Nov 27, 2023 16:28 UTC (Mon) by paulj (subscriber, #341) [Link] (1 responses)

Ok, fair enough, I'll defer to the more specific experience you and pizza have.

I still think that, even without _any_ documentation, if the microcode were at least user-replaceable, there would be clever people out there - outside of AMD and Intel - who would start to reverse engineer at least some of its functions, and we'd get some useful things out of it. There'd be bored EEE students writing fuzzers, measuring the visible changes on x86 ISA, and mapping out at least some subset of the microcode to hit on something useful.

Intel's "redundant prefix issue"

Posted Nov 27, 2023 16:35 UTC (Mon) by farnz (subscriber, #17727) [Link]

I'd certainly agree that people would reverse engineer the microcode and do things with it - I'm just not sure how I'd write that as a positive for Intel, since most of them will be aiming to either find a cool new vulnerability in Intel's designs, or trying to work out how Intel manages to be "better" than their preferred design at doing something.

We only got what we got for GPUs because Intel (and later AMD) needed something to get them design wins over the leading GPUs on the market, and the business case was that, while writing OSS drivers would help competitors reverse-engineer their designs, having OSS drivers would result in them getting sales to customers who see OSS drivers as a positive - and with ATI and nVidia winning (for Intel) and later nVidia dominating over AMD, they valued those design wins over protecting themselves from reverse-engineering. And this was especially clear since people could, and did, reverse engineer nVidia's closed drivers because they had documentation for the CPUs they ran on, even though they didn't have documentation for the GPUs.