Intel's mystery Linux muckabout is a dangerous ploy at a dangerous time 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 …
<sigh> 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.
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"?
Linus accepted Round One into the kernel. He did not have to, indeed he is notorious for his blunt refusals of shite he takes a dislike to.
Our vulture was wrong to write "Submitting mystery kernel updates is a security nightmare." No it isn't. Accepting those updates is the nightmare. Ain't it th'truth, Linus?
>Ding! Ding!< Round Two! Now, get back in the ring boy, and do your stuff this time.
Because someone with root access (and maybe also the ability to reboot without someone noticing, as they probably don't support hot feature enabling) could find a hole in it? It only affects CPUs that support it, and you could compile that feature out of the kernel if you know you aren't going to be purchasing upgrades for CPUs.
While I suppose it could be a method for Intel to add a backdoor, that ship sailed long ago with microcode updates, management engine, etc.
If it is compiled with support for the module then even if the module isn't present on the system an attacker could provide an identical copy (i.e. bring one from another RHEL install) so to be really sure you probably want to compile it with a 'N' for that feature than an 'M'.
Only if root is your ultimate goal. If for example there was a bug in Intel's CPU feature enablement functionality that allowed breaking out of a VM, then gaining root would be just a step in the exploit chain.
There have been some exploit chains that are five exploits long reported, gathering a little more privilege with each step.
Do you FOSS worshipers believe that Linux is developed by monks in a remote monastery, living of the products of the earth, and mostly of tin air?
Intel is a platinum sponsor of the Linux Foundation, and many people there live a nice life because of a lot of CORPORATE money funneled into the Linux kernel development (as you don't pay for it, right?), because that companies found it a cheaper way than having to pay many more developers to develop the same code for themselves.
In turn, don't believe the Linux Foundation will refuse that CORPORATE code just because it comes from a company you don't like. Maybe some has been briefed under NDA about what that code does (and won't tell you), maybe not, still they are not so stupid to block the largest CPU manufacturer just because its code is not anointed enough - Linux is still a commercial endeavour, not a religion, even if some of you believe so...
*snicker*
It is under a GPL license.
Of course it is a "religious" issue for a lot of people. You'll find them in a circle at midnight chanting "All Hail Lord Stallman!" while burning ritual copies of the BSD and Apache licenses on sheepskin scrolls...
This post has been deleted by its author
It's the new kinder gentler less profane and angry Linus, now. Extreme prejudice, maybe, but no unkind words about the submitter's mother.
Some dry wit and well targeted adjectives might be in order, though...
Intel has to consider the perception of "unlock keys" for their hardware. I think it will cause them to lose sales. I bet AMD is paying very close attention. (they could easily implement this as part of the final assembly and test process and not reveal it exists outside the company, then just sell it with a different model number)
Also worth mentioning, RPi has a feature unlock key for a hardware MPEG decoder last I checked.
RPi explained the MPEG decoder unlock. It's to pay for a patent license for the MPEG patents. If you're not going to use it, you shouldn't have to pay, so they don't include those charges in their board prices. And if you are going to use it then it's the patent holder's fault you have to pay. RPi don't make any significant money on the unlock codes, they mostly just cover their costs.
AMD has been selling lower core count CPU's since forever. Remember the x3 cores back in the Phenom days?
AMD's MO has always been to test the hardware and then disable a core if it doesn't work properly and then sell it as a treble core for a bit less than the full quad core. Sometimes you could re-enable the additional core with software, and sometimes it worked properly most of the time without problems.
I think he is saying that Intel was drifting off to sleep and sleepy. They were a bit mimsy but perhaps they a switching back to uffish.
For our overseas listeners, I think that the good Doctor was referring to the closing lines of that antidote to panel shows, BBC Radio Four's "I'm Sorry I Haven't A Clue", which is traditionally closed by the host using an expression like that. A few of them are collected here, from which I extract this gem:
"As the rogue purple underpants of time begin their assault on the whites-only wash cycle of destiny, and the twin buttocks of fate are sucked into the malfunctioning chemical toilet of eternity..."
... I see that it's the end of the show. Goodbye!
For our overseas listeners, I think that the good Doctor was referring to the closing lines of that antidote to panel shows, BBC Radio Four's "I'm Sorry I Haven't A Clue", which is traditionally closed by the host using an expression like that. A few of them are collected here, from which I extract this gem:
"As the rogue purple underpants of time begin their assault on the whites-only wash cycle of destiny, and the twin buttocks of fate are sucked into the malfunctioning chemical toilet of eternity..."
... I see that it's the end of the show. Goodbye!
RIP Humph, Willie Rushton & Tim Brook Taylor.
Thankfully the rest of the cast are still with us including Samantha and Sven.
This post has been deleted by its author
Not one person I've ever met, online or off.
I guess I don't know any raving FOSS fanatics, just "regular" developers that use the best tool for the job from those made available.
In my case, every Linux box got an old NVidia card I had lying around from the last gaming system upgrade. The next one gets a GTX1650.
I also like NVidia. I have no problem with BLOBS because sometimes they are necessary, for regulatory reasons (WiFi drivers) as well as graphics stuff. So long as the driver has the right hooks that enable kernel reconfig and recompile, that is good enough for me. No need to force everyone to unzip their secret compartments for everyone (and their competition) to go fishing in.
At least they ARE supporting Linux, and in NVidia's case, also FreeBSD
(my 2 FreeBSD workstations have NVidia cards and I am happy with them)
"At least they ARE supporting Linux, and in NVidia's case, also FreeBSD"
True, and I also use primarily FreeBSD and have NVidia cards in my two main boxes. But both a fairly old now, as are the GFX cards in them. The general consensus on the FreeBSD forums is that AMD is the way to go. NVidias support for FreeBSD (and Linux) isn't bad per se, but can be slow to catch up and often doesn't support all function, especially on more recent cards. Their non-Windows drivers very much seem to be an afterthought. But then, like many hardware manufactures, they probably don't see *nix as much of a market and so give it about as much effort as they think is worth it.
I have no problem with BLOBS because sometimes they are necessary, for regulatory reasons (WiFi drivers) as well as graphics stuff.
Er, no.
You don't need a BLOB for regulatory purposes. You need a signed open database. A BLOB (binary large object), by definition, has no exposed structure, so it uses 'security by obscurity' to conceal what it is doing, and also possible security by encryption as well as not publishing ABIs/register definitions and suchlike.
You can argue that regulatory data could and should be signed, although some people will argue for the right to absolute freedom ('radical freedom', as described by Jean-Paul Sartre, which encompasses the freedom to break the rules), but if nothing else, having visibility of the code that wants to run on your system would seem to be a reasonable position to take, especially if you are at all personal-security minded.
You can, of course, decide what code you want to run on your system, but not everyone will want to make the same choices as you, and they might have good arguments for their position.
NN
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.
"...a greater interest in and supply of decent Open Source hardware...and the latter is still some way off.
Most of the hardware I have works well under Linux but then I check if it is compatible on the various Linux compatibility lists. It's the software that gives me problems, especially drivers.
Having just spent the better part of last week struggling to get my system to use the NVIDIA driver for my video card I have to say that there is ample room for improvement in the handling of drivers in Linux. With the help of some knowledgable people on the PCLinuxOS forum I eventually got my rebuilt box to accept the use of the proprietary driver as the Nouveau one was failing miserably and screwing up the functioning of the whole system. In the end a step back from the current kernel installed as a default to an earlier one, in my case 5.10.81-pclos1, did the trick but if the Nouveau driver had been better I would not have had all the trouble I did have just to get a decent output on my monitor.
It goes against the grain using proprietary stuff on my Linux boxes, one of the reasons I started using Linux, but if the alternative is a sub-optimal experience, it's one I am prepared to live with until such time as the FOSS offerings are as good.
This has been discussed on several occasions here and on dozens of other Linux related websites.
You can't write a decent driver when the hardware manufacturer withholds crucial specifications from you. The Nouveau driver is written using pieces of information Nvidia reluctantly decides to share with the world and don't expect Nvidia to help in case things are not working properly. To make this clear once and for all, Nvidia team and Linux team are not working with the same set of specs and APIs and only one of the two teams has direct access to engineering team.
And it's not only Nvidia.
If I may the nouveau lot have designed and implemented very powerful PCIe snooping/logging tools in Linux which are used to dump what the Nvidia driver is saying to the card.
That enabled them to reverse engineer a lot of functionality by constantly replaying simple examples with minor variations to the card to see what the command sets were.
I don't believe Nvidia has been prepared to admit more that they may in fact make zero or more graphics cards when it comes to 3d acceleration for the Linux graphics stack :)
There have been many face-offs over the years. Some have reached court. Others have brought changes to the open source licenses. Many have brought forks in which proprietary and open versions duke it out in userland. Copyleft is surely the most significant single weapon in the F/LOSS protective armoury against subversion, which is why GPL licenses have tended to a Darwinian rise and rise.
If you want binary driver interfaces in the kernel, why not submit some patches? But you'll have to open up the functionality so your fellow open-sourcerers know which bits to leave alone when squashing bugs and vulnerabilities.
Oh, and didn't you know? The SOC houses are turning to RISC-V in a big way now, as the only way to feed their growth - precisely because it is open-source. So yeah, do encourage the incumbents to go against the flow, close the doors and see if they can hold out against the siege. Give us all a laugh.
@Pascal Monett my thoughts exactly.
Why would Linux kernel managers except code into the kernel that they can't test and therefore trust.
In the case of this code I would expect they will refuse to incorporate it as it can not be tested, because you can't test something:-
A) If you do not know what it is meant to do.
B) There is no hardware to test it on.
>If the Linux kernel managers don't like it, they can refuse to incorporate it.
Which, apparently, they should.
It should be rejected with extreme prejudice, until such time as Intel puts the full API and 'MIB'(*) for the Intel Software Defined Silicon (SDSi) into the public domain and thus usable under the same licence as Linux, enabling ALL CPU chip manufacturers to build chips using this interface without payment of any royalties to Intel.
Linux is Open Source, the core distribution doesn't need extensions for proprietary features embedded in it.
(*) I use the term MIB to mean the data strings, currently Intel proprietary, that will turn on/off chip features. Yes I know the features contributed are just data string transfer agents, but might as well start with a fully open specification and feature set.
In principle I am content to get my crippled CPU at a price the is effectively subsidised by other people paying for uncrippling keys. In practice I have been burned by Intel's inadequate support for their lowest end products too often. Perhaps Intel will test their driver updates on all their CPUs or perhaps they will decide that it is not worth the bother to test on the most crippled variations. I would also be concerned that part number XQ9100 gets good reviews but what is actually sold is part XQ9I00 and converting the I to a 1 requires a $299 key. Intel could also provide all new CPUs with a free x10 performance key ... that has a 12 month life span.
I only consider Intel when there is strong competition from AMD
> could also provide all new CPUs with a free x10 performance key ... that has a 12 month life span
"Could"? No, it's the whole point! "As a Service" is nowadays the wet dream of every bean counter, as it doesn't only allow full 24/7 control of the users (no hacking), but also yields a nice continuous income: Pay up, whatever we ask for, else your precious CPU turns into a pumpkin.
I'm ready to bet that some "unlock your CPU" feature with weekly/monthly fees is arriving momentarily. It will obviously try to appeal to peoples' greed, like "why pay for CPU power you don't need right now? Be smart and sexy, pay only for what you need, when you need it!"...
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2022
