Greg Kroah-Hartman: Outside Phone Vendors Aren't Updating Their Linux Kernels (linux.com) 86
"Linux runs the world, right? So we want to make sure that things are secure," says Linux kernel maintainer Greg Kroah-Hartman. When asked in a new video interview which bug makes them most angry, he first replies "the whole Spectre/Meltdown problem. What made us so mad, in a way, is we were fixing a bug in somebody else's layer!"
One also interesting thing about the whole Spectre/Meltdown is the complexity of that black box of a CPU is much much larger than it used to be. Right? Because they're doing -- in order to eke out all the performance and all the new things like that, you have to do extra-special tricks and things like that. And they have been, and sometimes those tricks come back to bite you in the butt. And they have, in this case. So we have to work around that.
But a companion article on Linux.com notes that "Intel has changed its approach in light of these events. 'They are reworking on how they approach security bugs and how they work with the community because they know they did it wrong,' Kroah-Hartman said." (And the article adds that "for those who want to build a career in kernel space, security is a good place to get started...")
Kroah-Hartman points out in the video interview that "we're doing more and more testing, more and more builds," noting "This infrastructure we have is catching things at an earlier stage -- because it's there -- which is awesome to see." But security issues can persist thanks to outside vendors beyond their control. Linux.com reports: Hardening the kernel is not enough, vendors have to enable the new features and take advantage of them. That's not happening. Kroah-Hartman releases a stable kernel every week, and companies pick one to support for a longer period so that device manufacturers can take advantage of it. However, Kroah-Hartman has observed that, aside from the Google Pixel, most Android phones don't include the additional hardening features, meaning all those phones are vulnerable. "People need to enable this stuff," he said.
"I went out and bought all the top of the line phones based on kernel 4.4 to see which one actually updated. I found only one company that updated their kernel," he said. "I'm working through the whole supply chain trying to solve that problem because it's a tough problem. There are many different groups involved -- the SoC manufacturers, the carriers, and so on. The point is that they have to push the kernel that we create out to people."
"The good news," according to Linux.com, "is that unlike with consumer electronics, the big vendors like Red Hat and SUSE keep the kernel updated even in the enterprise environment. Modern systems with containers, pods, and virtualization make this even easier. It's effortless to update and reboot with no downtime."
But a companion article on Linux.com notes that "Intel has changed its approach in light of these events. 'They are reworking on how they approach security bugs and how they work with the community because they know they did it wrong,' Kroah-Hartman said." (And the article adds that "for those who want to build a career in kernel space, security is a good place to get started...")
Kroah-Hartman points out in the video interview that "we're doing more and more testing, more and more builds," noting "This infrastructure we have is catching things at an earlier stage -- because it's there -- which is awesome to see." But security issues can persist thanks to outside vendors beyond their control. Linux.com reports: Hardening the kernel is not enough, vendors have to enable the new features and take advantage of them. That's not happening. Kroah-Hartman releases a stable kernel every week, and companies pick one to support for a longer period so that device manufacturers can take advantage of it. However, Kroah-Hartman has observed that, aside from the Google Pixel, most Android phones don't include the additional hardening features, meaning all those phones are vulnerable. "People need to enable this stuff," he said.
"I went out and bought all the top of the line phones based on kernel 4.4 to see which one actually updated. I found only one company that updated their kernel," he said. "I'm working through the whole supply chain trying to solve that problem because it's a tough problem. There are many different groups involved -- the SoC manufacturers, the carriers, and so on. The point is that they have to push the kernel that we create out to people."
"The good news," according to Linux.com, "is that unlike with consumer electronics, the big vendors like Red Hat and SUSE keep the kernel updated even in the enterprise environment. Modern systems with containers, pods, and virtualization make this even easier. It's effortless to update and reboot with no downtime."
Re: (Score:2, Insightful)
It seems the default line from vendors is - well, if you want the latest Android, buy a new phone. Samsung and others need to get off their collective bums. Either roll us the updates, or drop phone prices radically. Complete BS dropping a few hundred (times number of people in your household) every 2-3 years when the old phones are still perfectly fine. We've only replaced when phones have been severely damaged in drops (rare).
Re:if you want the latest Android, buy a new phone (Score:1)
Re: (Score:3)
I wouldn't judge too harshly on that. My Nokia 8 tells me there are security updates about every month or two and I find it slightly annoying. I think more people would find it annoying if it were more frequent, and there would be more incentive to turn it off (bad idea).
The other factor to consider of course is, are the Intel (and ARM I guess...) security problems really that big a deal? Red Hat and SUSE would need to patch them but speculative execution things while in theory possible shouldn't really be
Re:Androids are targeted at poor people (Score:5, Informative)
Red Hat and SUSE would need to patch them but speculative execution things while in theory possible shouldn't really be a big deal for a cellphone because you're not virtualising anything (AFAIK).
1) Sandboxing
2) Javascript
3) Malware doesn't get caught by the app store screening processes
Re:Androids are targeted at Cheap people (Score:2)
I work on HP superdomes (Score:1)
RHEL 7.x with a 3.1x kernel isn't keeping up.
Re: (Score:2)
And my brother is named for both our grandmothers. (Their maiden family names are his given names.) What of it?
Re: (Score:1)
Found the n00b. AIDS was an MS-DOS virus which exploited the fact that .COM would be executed before .EXE if both files had the same name and existed within the same directory.
Go back to sucking on mommy's tit, child. Adults are talking.
Re: (Score:2)
Same here (Lumia 950). I sure wish Microsoft hadn't given up on phones, but even so I have to credit them with the security updates.
Re: (Score:2)
Re: (Score:2)
red flag linux is communist's distro.
natsoc's distro is hitlerlinux
Re: (Score:2)
the one that came out of the closet?
Binary Blobs is the problem with Linux kernels. (Score:5, Insightful)
Its always been the same issue, over and over and over. If you need sources for 3rd party closed drivers, you cant update the kernel without them.
This needs to be fixed. This will fix everything, older android can be updated, linux systems like phones and tablets can be updated, forever.
Re:Binary Blobs is the problem with Linux kernels. (Score:4, Informative)
This will fix everything, older android can be updated, linux systems like phones and tablets can be updated, forever.
No it won't. Basic premise for Android is:
That last bit simply isn't happening. As much as they can get away with, carriers or phone vendors just do a few updates (say over a year, 2 years if you're lucky), and that's it.
The way around that requires a couple of things:
Bottom line: in most cases end users are still stuck, even if open source drivers are available. Android's update model is simply broken to begin with.
Re: (Score:2)
The way around that requires a couple of things:
Just one actually: Governments legislate that phone vendors have to provide updates for at least three years after first sale.
There are already plenty of laws around requiring manufacturers to support their product, this one is a simple follow-on from those. Nothing else will do it, there just aren't enough OSS enthusiasts around to keep playing catchup with what phone vendors are doing.
Re: (Score:3)
FTFY
Re: (Score:2)
The battery won't last seven years. Until we have better energy storage technology, three makes much more sense.
Re: (Score:2)
Replaceable batteries. My Microsoft Lumia 950 has one of those. I think the only reason not to have one is to make sure you buy a new phone after a few years. (I've heard that the replaceable battery makes the phone thicker. I don't care.)
Re: Binary Blobs is the problem with Linux kernels (Score:1)
A phone with an unlocked bootloader is an extreme problem in terms of security. I relock my bootloader every time i finish installing a custom firmware.
With an unlocked bootloader (or even custom recovery), you left a gaping security hole that anyone can modify the boot sequence \ software. They can, for example, shim your touch interface driver and capture all input. Modify the OS...
Please, for the love of security, don't speak and don't do unless you understand the risks involved.
Re: Binary Blobs is the problem with Linux kernels (Score:1)
There's a HUGE difference between an unlocked bootloader and an unlockable bootloader.
Most phones save a few have an unlockable bootloader. Precisely 0 factory devices have an unlocked bootloader
Re:Binary Blobs is the problem with Linux kernels. (Score:4, Interesting)
As the mountains of orphaned but still perfectly functional phones continue to pile up, interest in and support for community supported custom ROMs continues to increase, LineageOS being the leading project. Because vendors aren't releasing the necessary technical details, a lot of this is reverse engineering and binary hacks to use the phone's original hardware drivers, while updating the kernel and all the libraries using open source Android. There is just an endless supply of hardware to play with, which is all basically free. I myself have a perfectly functional Nexus 4 sitting here, useless because Google refused to provide an update to fix the notorious navigation button touchscreen bug. So that makes it a toy to play with custom roms, nothing to lose, and a functional phone to gain.
By the way, the Nexus was replace by a Moto. I'm never buying hardware from Google again because they got arrogant and don't stand behind it, never mind the Apple envy pricing.
Re: (Score:2)
Re: (Score:2)
Nope, most people won't do a procedure not endorsed by the manufacturer such as flashing an unofficial ROM
Most people don't need to do the procedure. One nerd or one screwdriver shop can do hundreds of these. The thing is, these phones are basically free because without a ROM update they are useless. By my count, orphaned smartphones already outnumber in service ones. Everybody has a couple stashed away in a drawer.
Re: (Score:2)
Re: (Score:2)
They'll ebay it for next to nothing. It will keep changing hands for less and less money until it ends up in the hands of somebody who know how to reflash it. Especially if reflashing is easy, and it is. Then it goes from being junk to being a fun toy again. This is going to happen to some fraction of used phones, the only question is, how many. You can be sure it will increase over time as more rescue candidates heap up at the bottom.
Re: (Score:2)
Re: (Score:2)
I'm talking about phones that are already out of service because the owner owns a newer one. As I see it, a lot of these become toys for playing with custom roms. I've got two of those now, how about you? Some of those will actually go back into service because of running the latest, fully patched Android release. Something you can hand your kids without getting to worked up if it gets lost, broken or stolen.
Re: (Score:2)
Re: (Score:2)
My Kitkat phone is useless because many important apps won't install on it. Over time, that factor alone will create enough pressure to create the "rescue" segment.
Re: (Score:2)
Re: (Score:2)
The vast majority of people don't want to play with old hardware or play with custom roms to try and achieve a functional phone.
The phone is worth zero to them so they can just give it away to somebody who does like to play with roms. And feel good about it because that's one less piece of electronics in a landfill.
Re: (Score:2)
A lack of driver source code could be a problem upgrading the kernel from for example 4.4 to 4.9, since internal kernel interfaces may have changed. However, upgrading the kernel from 4.4.7 to 4.4.123 will only include bug fixes with no interface changes and the vast majority of consumer electronics manufacturers aren't doing those upgrades either.
Are you *SURE* about that? (Score:1)
As someone who has lived through the 1.2, 2.0, 2.2, 2.4, 2.6, 3.x, and 4.x kernel minors, I can tell you that there can be a lot of API/ABI flux even in patchlevel updates. 2.6.9-2.6.10 and 2.6.31 to 2.6.32 I believe were the most heinous. 2.2 and 2.4 also had similar issues where newer versions required everything from different compilers to different glibcs to work together properly.
Maybe these particular patchlevels didn't, but it merits scrutiny.
Re: (Score:2)
The third digit since 3.0 is comparable to the fourth digit before 3.0.
Re: (Score:2)
Sorry, number, not digit. In any case, the patch level is the last number in the series and since 3.0 the version number was shortened from 4 numbers to 3 numbers.
Re: (Score:2)
Re: (Score:2)
The biggest problems with updating kernels are vendors who don't comply with the GPL (not releasing kernel source at all, releasing incomplete kernel source, releasing kernel source that doesn't match the shipping binaries, taking forever to release kernel source after a new update to the device, stuff like that) and vendors who lock down the devices so that replacing the kernel isn't possible.
Re: (Score:2)
Re: (Score:2)
Always wondered how binary blobs are even legal with the GPLv2
Because the kernel isn't GPLv2, it's often lauded as the biggest success story of the GPL but in fact it has a very specific exception [github.com] which would otherwise put any software with an incompatible license making syscalls to the kernel in violation of the GPL.
This is one of the things that has led to the Linux kernel being so successful.
Re: (Score:2)
Its always been the same issue, over and over and over. If you need sources for 3rd party closed drivers, you cant update the kernel without them.
This needs to be fixed. This will fix everything, older android can be updated, linux systems like phones and tablets can be updated, forever.
You don't need the sources if a kernel module to load the binary driver is provided (like how the nVidia linux drivers work) or if the kernel provides a stable ABI (like the way Windows works). It's nice to say "well every manufacturer of hardware should just release all their driver code as open source" but it's just not realistic, and anyway somebody has to then maintain that driver code and there is a cost to doing that.
Re: (Score:1)
neither Linus nor Greg are Theos.
Only Theo de Raadt had the balls to say NO to intel's incompetence in creating a secure product. He didn't bother cleaning up someone else's shit, he decided to disable those features, e.g. HyperThreading(tm).
If Linus had the balls to yell at intel, or even flip the middle finger, like he did with novidia, he would've blocked all those patches that not only messed up with the kernel's internals, but caused regressions and the fucking patch that intel sent, disabled features
Re: (Score:3)
I'd submit that, if OpenBSD had any market presence, Theo de Raadt and the core OpenBSD kernel team would have handled this differently. Since their market share is so very small with so few commercial customers, it seems unworth their effort to attempt to integrate a subtle kernel patch written by a vendor to fix a kernel optimization feature not critical to their niche marketplace.
For NVidia cards, I cannot find anyone who uses OpenBSD for high performance graphics. This is especially since almost no game
Re: (Score:2)
it seems unworth their effort to attempt to integrate a subtle kernel patch written by a vendor to fix a kernel optimization feature not critical to their niche marketplace.
servers are a niche marketplace? Since when?
Also, I don't think that Theo checked the size of his slice in the operating system usage pie chart, in order to form his opinion. As a matter of fact, his stance not only caused trouble in the small community that uses openbsd in their servers, but avoided new users installing it on their machines.
My mention about nvidia is only as a reference to the middle finger and has nothing to do with nvidia running on openbsd.
Re: (Score:2)
My mention about nvidia is only as a reference to the middle finger and has nothing to do with nvidia running on openbsd.
It's not like that middle finger from Linus influenced nvidia that much. They still use completely proprietary binary blobs in their drivers, they still have driver based firmware blobs that are a pain in the ass for alot of users and distributions, Their optimus hybrid support on linux is still pretty shitty (iirc that's the question that prompted the middle finger) and they still aren't contributing significantly to nouveau.
Re: (Score:2)
Servers are not a niche market. OenBSD hosts of any kind are a niche market. Reasonably honest audits, such as those at https://idatalabs.com/tech/ope... [idatalabs.com], report its deployed percentage as roughly 1/10 of 1 percent of operating systems. If their market were larger, there would be more customers to complain about losing a few percent of performance by disabling the threading behavior.
Outside Phone vendors? (Score:5, Funny)
Saul Goodman?
Re: (Score:3)
One would think that at least one of those shows' writers would've had read Illuminatus! [wikia.com] at some point, but I guess not.
Software should be free from hardware (Score:3)
Android as hypervisor (Score:3)
Maybe that's what Android needs, a hypervisor, and what we know now as Android the operating system could just run as a VM. All the physical device drivers could be abstracted as virtual devices and supported in the OS with open source virtual device drivers.
This would at least make the OS itself easier to update. The hypervisor would probably need updating as well, but I'd wager less often than the actual OS and without the burden of physical device drivers to worry about it could happen more often.
Not all phones are vulnerable (Score:2)
Back when the fit hit the shan with this issue, I found a reliable resource which stated which phones were vulnerable and which were not. I have a Samsung Galaxy something-or-other and its processor turns out not to be affected. The kernel is from early 2017 and I'm not particularly happy with that but this particular problem is a non-issue for a massive number of users.
Will never change, will never happen (Score:4)
There's no income from updating android on a phone already sold. It's actually negative income because a new one doesn't get sold.
Google may make some profit on the ads, but nothing of that reaches the vendor.
Apple has Music, iCloud, the AppStore. When they provide an update to iOS on a five year old phone, people continue to use it and buy apps, in-app purchases , iCloud storage for it (and maybe an AppleMusic subscription). That, combined with a nice profit on the hardware itself, is apparently enough for them to backport all the fixes and all the performance-improvements five years down the hardware memory-lane.
cornfused (Score:2)
The OP (and this is quoted directly from the linked-to article, which is no more enlightening):
"...aside from the Google Pixel, most Android phones don't include the additional hardening features, meaning all those phones are vulnerable...I went out and bought all the top of the line phones based on kernel 4.4 to see which one actually updated. I found only one company that updated their kernel..."
Color me confused. Is he saying that only Google (Pixel) updated their kernel? Or that one unnamed company (n
RHEL still at Linux kernel 3.10 (Score:2)