Intel's mystery Linux muckabout is a dangerous ploy at a dangerous time

Opinion This is a critical time for the Good Chip Intel. After the vessel driftied through the Straits of Lateness towards the Rocks of Irrelevance, Captain Pat parachuted into the bridge to grab the helm and bark "Full steam ahead!"

Its first berth at Alder Lake is generally seen as a return to competitive form, but that design started well before Gelsinger's return and there's still zero room for navigational errors in the expeditions ahead.

At least one of the course corrections looks a bit rum. Intel has long realised the importance of supporting open source to keep its chips dancing with Linux. Unlike the halcyon days of Wintel dominance, though, this means being somewhat more open about the down-and-dirty details of exactly how its chips do their thing. You can't sign an NDA with the Linux kernel.

Chipmakers are notoriously paranoid: Silicon Valley was born in intrigue and suspicion. Despite Intel's iconic CEO Andy Grove making paranoia a corporate mantra, Intel became relatively relaxed. Qualcomm and Apple would throw you into their piranha pools merely for asking questions if they could, while Intel has learned to give as well as take. But it may be going back to bad habits.

One of the new things not open to discussion is something called Software Defined Silicon (SDSi), about which Intel has nothing to say. Which is odd because it has just submitted supporting code for it to the Linux kernel.

The code itself doesn't say anything about SDSi, instead adding a mechanism to control whatever it is via some authorised secure token. It basically unlocks hardware features when the right licence is applied.

That's not new. Higher performance or extra features in electronic test equipment often comes present but disabled on the base models, and the punter can pay to play later. But what might it mean in SDSi and the Intel architecture?

It is expensive for Intel and OEMs alike to have multiple physical variants of anything; much better if you make one thing that does everything and charge for unlocking it. It's a variant of a trick discovered by hackish school kids in the late 1970s, where cheaper Casio scientific calculators used exactly the same hardware as the more expensive model. Casio just didn't print all the functions on the keyboards of the pleb kit. Future Intel chips will doubtless have cores and cache disabled until magic numbers appear, and with the SoC future beckoning that can extend to all manner of IO, acceleration, and co-processing features. It might even be there already.

From engineering, marketing, and revenue perspectives, this is great. Intel could make an M1-like SoC that can be configured on the fly for different platforms, getting the design, performance, and fab efficiencies that Apple enjoys while making sense for multiple OEMs. There could be further revenue from software upgrades, or even subscription models.

Which suddenly doesn't sound so much fun. DRM for core hardware? Indeed, the major problems with this approach, at least in the consumer world, are psychological. Those who get the locked-down variants know that they've paid for hardware capable of so much more. This rankles. Those who pay for the top-end, all-stops-out version know that they've paid scads more for what the cheapskates have. That rankles too – and unsurprisingly, there's a lot of work put into finding ways to cheat the system.

• Intel updates mysterious 'software-defined silicon' code in the Linux kernel
• Self-driving towards an IPO? Intel unveils plans for Mobileye offering
• What a cluster fsck: New scheduling code plus Intel's Alder Lake CPU mix equals a slower Linux kernel 5.16
• Intel's recent Atom, Celeron, Pentium chips can be lulled into a debug mode, potentially revealing system secrets

Far worse, in this case, is Intel's presentation of the enabling code to the Linux kernel without explanation. It smacks of treating open source like a tool of corporate marketing; it is at the least condescending, at worst a statement of intent that Linux in particular and open source in general is there to be subverted, if it pleases Lord Intel. To add obfuscated corporate functionality to open source's crown jewels is beyond unfortunate.

It's not just rude, it's foolhardy. Submitting mystery kernel updates is a security nightmare. How do the maintainers test something when they don't know its function and there is no available hardware? It's especially bonkers to do this for a feature which immediately stands out as a prime target for attention.

Here again, the psychology of real users has escaped Intel. If you look at the hacking teams who historically attack and defeat DRM, copy protection, and locks on gaming platforms, they are lauded as heroes. It is a very high-status gig to defeat the Mighty Corporation and give the humble user the freedom to use the thing they paid for as they wish. Harsh on the producer, but if your business model cannot withstand reality, it is not reality at fault.

All of this is speculation – but valid speculation. Why so coy? Had Intel proposed this at the same time as it could give developers target hardware, it would be better; with proper use cases, testable systems, and a cogent argument about how this benefits the ecosystem, it would be less objectionable. Still not good.

This is the final danger. Intel needs a lot to go right for it now. It needs good product. It needs good roadmaps. Mostly, it needs good friends, people at the heart of the industry who trust it. It does not need the reputation it has had in the past as a trickster company, one that ignores its customers and uses its heft to get its own way.

Tampering with the Linux kernel and not saying why is no way to make valuable friends, but a great way to claim a power you no longer have to weather storms now much bigger than you. It may just be a squall to be smartly avoided by a tap on the wheel by Captain Pat.

If he's deliberately steering for a tempest, there'll be plenty who decline to follow him in. ®