Intel's "redundant prefix issue"

Posted Nov 16, 2023 11:23 UTC (Thu) by farnz (subscriber, #17727)
In reply to: Intel's "redundant prefix issue" by paulj
Parent article: Intel's "redundant prefix issue"

The argument differs to the 90s one - the argument is not that the hardware is too sophisticated, needs special management, only the vendor has the expertise (and OSS hackers do not). Instead, the argument is that the microcode is closely coupled to a single implementation, and that implementation is not only not documented other than as VDHL/Verilog + schematics, but Intel wants to protect the implementation against reverse engineering by competitors (e.g. AMD, Huawei, Apple).

There's then side issues around the physical damage you can do with microcode changes (e.g. burn out a spot on the chip), but the big deal is protecting the hardware against reverse-engineering via microcode.

Intel's "redundant prefix issue"

Posted Nov 16, 2023 13:55 UTC (Thu) by paulj (subscriber, #341) [Link] (1 responses)

The "but competitors might reverse engineer!" argument was very much used against opening hardware drivers in the 90s.

Intel's "redundant prefix issue"

Posted Nov 16, 2023 14:21 UTC (Thu) by pizza (subscriber, #46) [Link]

> The "but competitors might reverse engineer!" argument was very much used against opening hardware drivers in the 90s.

It's _still_ used to this day. Anectdotally, it actually seems to be more prevalent now.

The pendulum swings back and forth between "smart hardware, dumb driver" and "dumb hardware, smart driver".

One scenario much more common now than in the 90s: If your product is patented, and stuff covered by the patent is in implemented in the driver, publishing that driver under a Free Software license can effectively give everyone, including your competitors, free access to your patent. Or, perhaps more importantly, it could expose how your product works to a patent troll.