News: 1639387632

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

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

(2021/12/13)


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 [1]parachuted into the bridge to grab the helm and bark "Full steam ahead!"

Its first berth at [2]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.

[3]

Chipmakers are notoriously paranoid: Silicon Valley was born in intrigue and suspicion. Despite Intel's iconic CEO Andy Grove making [4]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.

[5]

[6]

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 [7]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.

[8]

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.

[9]

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.

[10]Intel updates mysterious 'software-defined silicon' code in the Linux kernel

[11]Self-driving towards an IPO? Intel unveils plans for Mobileye offering

[12]What a cluster fsck: New scheduling code plus Intel's Alder Lake CPU mix equals a slower Linux kernel 5.16

[13]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. ®

Get our [14]Tech Resources



[1] https://www.theregister.com/2021/05/12/vmware_new_ceo/

[2] https://www.theregister.com/2021/10/27/intel_alder_lake/

[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Ybcn6GSA9D8i4pgkrYDBfwAAABE&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[4] https://www.goodreads.com/book/show/66863.Only_the_Paranoid_Survive_Lessons_from_the_CEO_of_INTEL_Corporation

[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Ybcn6GSA9D8i4pgkrYDBfwAAABE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Ybcn6GSA9D8i4pgkrYDBfwAAABE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[7] https://www.theregister.com/2021/12/08/intel_software_defined_silicon_update/

[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Ybcn6GSA9D8i4pgkrYDBfwAAABE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Ybcn6GSA9D8i4pgkrYDBfwAAABE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[10] https://www.theregister.com/2021/12/08/intel_software_defined_silicon_update/

[11] https://www.theregister.com/2021/12/07/mobileye_ipo/

[12] https://www.theregister.com/2021/12/01/linux_5_16_alder_lake/

[13] https://www.theregister.com/2021/11/16/intels_chip_flaw/

[14] https://whitepapers.theregister.com/



SCP

Oh for the happy days of "fixing" your AMD K7 with a 2B pencil.

More seriously though it does seem perverse that a model of production that should reduce costs to everyone is hamstrung by concerns that some won't "play fair". In several ways I am reminded of Arthur Dent's line of argument with L. Prosser - it all seems very reasonable, but we can see where the bulldozers are going to end up.

Michael Hoffmann

Well written, almost poetic!

Now, for contrast, I'd like to see what Linus had to say about it. I'm always on the look-out for new swear words. Wish he still used his mother tongue more!

Is there a "pull request declined with most extreme prejudice and unkind words about the submitter's mother"?

Doctor Syntax

I certainly hope so.

Doctor Syntax

"After the vessel driftied through the Straits of Lateness towards the Rocks of Irrelevance"

Are you saying they Haven't A Clue?

msobkow

I agree with the intent of the article whole heartedly.

But I must point out that Linux land has been quite happy to leave things "hidden" when it serves their purpose, like being able to play games with their NVidia hardware...

Open source in general is there to be subverted

Warm Braw

There is bound, at some point, to be a major face-off between Open Source and commercial interests. We already have examples of the opposite happening: proprietary graphics drivers because manufacturers refuse to release details of the hardware. Unfortunately in the battle of open vs. closed, it's the users who end up being inconvenienced.

There are several possible outcomes for the general user. One is that there is an acceptance that Open Source will have to better accommodate commercial interests by providing, for example, binary driver interfaces. Another is that the threat of commercial obfuscation leads to a greater interest in and supply of decent Open Source hardware. I see very little prospect of the former and the latter is still some way off.

As I've said before, though, I think the power now lies not with the chip manufacturers, nor with Open Source developers, but with the major consumers of silicon - the big cloud companies. They may well want to cut proprietary deals - on their own terms - and will make their own software changes to accommodate them. If you're concerned about corporate carve-ups, that's the place to focus your attention. Don't even expect to be able to buy the CPUs that power cloud services in the future, never mind worry about how they might function.

It's only submitted code

Pascal Monett

It doesn't have to be accepted.

If the Linux kernel managers don't like it, they can refuse to incorporate it.

Which, apparently, they should.

Because indeed, if they can't test it, they can't trust it, and if they can't trust it, why include it ?

Farewell we call to hearth and hall!
Though wind may blow and rain may fall,
We must away ere break of day
Far over wood and mountain tall.

To Rivendell, where Elves yet dwell
In glades beneath the misty fell,
Through moor and waste we ride in haste,
And whither then we cannot tell.

With foes ahead, behind us dread,
Beneath the sky shall be our bed,
Until at last our toil be passed,
Our journey done, our errand sped.

We must away! We must away!
We ride before the break of day!
-- J. R. R. Tolkien