Linux kernel 5.19.12 'may harm' Intel laptop screens A bug in version 5.19.12 of the Linux kernel "may harm" screens on laptops powered by Intel's 12th-generation Core processors. The Alder Lake family of chips are significantly different from earlier Intel generations, and this has caused previous problems in the open source kernel, though those were relatively modest …
Looks like destructive malware just got another tool in it's [sic] toolkit.
How so? Is the malware going to install kernel 5.19.12 (after detecting you have a vulnerable system)?
If malware already has kernel-level access, it's game over. Messing with the cooling system, for example; there are already third-party fan-control utilities for laptops which come with stern warnings about incorrect settings. Attacks against firmware which can brick devices (Viasat terminals, say) are well known. Around five years ago, Brickerbot made the news by bricking IoT devices it encountered; a couple of years ago, Trickbot was doing the same to general-purpose PCs by trashing UEFI firmware.
The code which creates the issue is in the 5.19.2 kernel.
Malware authors can look at that code and embed it into other stuff.
You don't need the whole kernel to do this, just presumably few lines of code. And if you are not sure which of the code that creates this issue, it should be relatively easy to look at 5.19.3 changes and figure out what code is probably involved.
No doubt it will not be a simple cut and paste job, but malware authors have proven to be inventive in all the bad ways. May need a chain of exploits to get there, but if they want to, they will get there.
Hopefully they don't think it is worth working on.
I was running 5.19.12 all last week with no flashing on either my Lenovo T440 laptop or my ancient dual Athlon desktop house server.
This afternoon I'd updated both systems to 5.19.13 as part of my weekly 'first backup and then update' session before this story had appeared on either Ars Technica or El Reg. Ars was first to describe the problem.
"I have seen Linux people struggling for hours to print a document. Printing from Linux is not always easy or straightforward. And don't blame the lack of drivers. That is just part of the problem."
And your point is?
I have seen Windows people struggling for hours to print a document. Printing from Windows is not always easy or straightforward. And don't blame the lack of drivers. That is just part of the problem.
And this additional firmware, which you reckon is Intel’s problem….
Now obviously we don’t want to allow evil Intel to snoop on what we’re writing to the screen, without knowing what’s running on our silicon. So….we’ll want an open-source firmware, right? Which will run on what OS….well, Linux is the best for embedded, right.
And which CPU should it run on? Clearly not the x86 that the user space is running on, because that’s running Linux and it needs to be partitioned. But on the same die to minimise I/O. I guess would be there to manage the device, so let’s call it a Management Engine. Intel Management Engine. Great!
As an embedded systems engineer, I read the opening paragraphs of this article and thought WTaF?!? Exactly as you've done, I couldn't believe the OS is expected to be responsible for something as fundamental as power supply sequencing, so a) I'm rather bemused by why you've received so many downvotes vs so few upvotes, and b) I'm rather irritated by the number of said downvoters who haven't then bothered to take the time to explain why they think you (and thus also me) are so wrong about this that it deserved a downvote. I honestly don't mind being wrong about stuff, I'd just like to be given the chance to understand WHY I'm wrong as part of being told I'm wrong...
As another embedded guy I'm wondering about the description of the problem's cause. None of the linked sources give any explicit information, but I can see two obvious possibilities, both of which result in confusing the display's onboard processor. The first and most obvious is sending a command to the display before it has finished initialising on power up, and the second (and less likely) is sending an invalid command. Either case suggests that the display processor is fragile. This has happened before - I remember the Intel 8271 floppy disk controller, which was an excellent device but could be irrevocably burnt out by sending a specific illicit byte to a specific register.
I agree. I've done my share of OS and driver level software, and this sounds like a hardware design fail. Granted, it's almost certainly done for cost reduction, which is not a bad thing, but the failure mode is unacceptable and IMO good engineering would design it to fail in a safe way.
The downvotes are because we've normalized cost reduction as the greatest good above all other goals, and also normalized "shipping broken hardware that depends on OS level workarounds to even function because that's cheaper than spinning another rev of the chip".
It's probably the Microsoft shills giving downvotes because the OP didn't trash-talk Linux. It does happen, you know. I guess El Reg isn't just read by nerds avoiding work anymore, it's grown up and professional now. The corporate butt-hurt brigades like to come in and beat down on the opposition. Sometimes it's Googlers, sometimes it's Microsofties, sometimes it's Amazonians.
I remember my late '90s supermarket special beige PC had a generic 14" CRT that just wouldn't play with X.
I emailed the "manufacturer" (i.e. the importer) to ask if they could give me a set of X parameters that would, you know, actually put an image on the screen.
To their credit, they promptly replied, stating that they had attached a device driver file for it.
Sadly it was a Windows (95/98) .INF file. Chocolate spanner territory.
I never did get it to work. In the end I bought an LCD panel. Cost a fair amount and could only display 4096 colours, at 1024x768, but it worked straight out of the box. Never had a CRT since.
-A.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
