Does the Model S really run 2.6.36, first released ten years ago? I'm sure they're using a stable branch and keeping up with security patches in general [1], but that's still shocking to me.
[1]: although not 100% of security patches are going to end up in the stable@ queue or have their effect on 2.6.36 considered.
https://electrek.co/2017/06/30/tesla-new-linux-kernel-update...
EDIT: See nils2014's comments below. The WiFi chip is connected to the entertainment system which received an updated kernel, but it is seems like the kernel on the WiFi chip itself may not have been updated.
The Wi-Fi stack is running on a separate module (the Parrot module, as mentioned in the article), which runs its own obsolete linux version.
(Tesla uses the name Parrot to refer to this system in the car.)
A reason for them not to still be on 2.6.36 is that it's deeply exploitable.
As far as I can tell, Parrot-the-module-maker split from Parrot-the-drone-company and is now http://parrot-faurecia-automotive.com
In Teslas position, as the ultimate vendor that is shipping this stuff on thousands of cars, you might decide that your supplier isn't forthcoming with security updates and decide to backport some isolated fixes to the kernel, but an upgrade from 2.6 to say even 4.4 is entirely out of the question; there are thousands of lines of hacked-together proprietary vendor code in those kernels where just going up a minor version will break the build. For a 2.6 based system in particular, you would essentially need to convert the entire board support to a device tree based system.
> but an upgrade from 2.6 to say even 4.4 is entirely out of the question
We did this kind of transition at OLPC ten or so years ago, helping Marvell upstream enough of their arch support code for a new ARM SoC to move us from their private 2.6 branch to latest public upstream (including the move to device tree), and with only a few kernel engineers working on it. Tesla surely has many times more resources; it's not entirely out of the question, but it's true that it's probably not economical for a minor support chip. Although, it's the minor support chip that's connected to the outside world..
What I don't get with these cases at all: by the GPL manufacturers are forced to provide the full (!) Linux kernel source code, same goes for u-boot. But while Tesla at least seems to provide source code (https://github.com/teslamotors), why the fuck and how can Android phone and other embedded device makers get away with not publishing anything?
Let's just take two examples of hardware that I know run Linux because I managed to root them:
- Sony A7S2 camera: the firmware is at https://www.sony.com/electronics/support/downloads/00016077, but no mention at all about contained open-source code, licenses, or build instructions
- HP Z2100 24-inch plotter: firmware is at https://support.hp.com/sg-en/drivers/selfservice/hp-designje... (you have to select Windows XP 32-bit to see the firmware download, even though the firmware can be installed via anything capable of running a browser), and again, no mention of anything regarding Linux.
In general, the answer is that Linus Torvalds especially, and kernel developers in general, are very uninterested in filing copyright lawsuits, and it's them who have standing to bring a GPL violation lawsuit, rather than you as a purchaser -- it's not your rights that have been legally infringed, it's the code author's rights.
If the device manufacturer is not a US company (like the often-Chinese Android phone manufacturers), filing that lawsuit would be especially difficult even if the authors wanted to.
In these Sony and HP cases, they aren't required to put the source code on their firmware download pages. They're required to offer and produce it in response to a written request under GPLv2, or to instead bundle it with the hardware (e.g. on companion CD). You might find they actually do one of those two, since they're large US companies with mostly competent legal departments.
Incidentally, it took a lawsuit, or at least the imminent threat of one, for Tesla to start publishing kernel source: https://sfconservancy.org/blog/2018/may/18/tesla-incomplete-... . I think the lawsuit was primarily filed on behalf of Busybox authors rather than Linux authors.
That's not true. GPLv2 text:
> Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code
(Emphasis mine.)
Surely you must be joking... The last kernel 2.6.x LTS version to be maintained is 2.6.32.71, and its maintenance ended in March 2016 [1].
No Security patches were released for 2.6.x since then.
[1] https://en.wikipedia.org/wiki/Linux_kernel_version_history#R...
[1] - https://access.redhat.com/support/policy/updates/errata
[2] - https://fedoraproject.or/wiki/Security_Features_Matrix
[ EDIT ] I was advised it is not running CentOS and that may be another system in the vehicle.
You're confusing the linux running on the information center, with the linux running on the Parrot board.
[1] https://fccid.io/RKXFC6050W/Users-Manual/user-manual-1707044
If Parrot's still running 2.6.36, that's a really really bad sign for its security. You would have to predict more remote vulns on the way.
I am probably thinking of the system that controls the driving, which I am 99% sure is CentOS 6. Reaching out to someone I know there.
It looks like their open source disclosure of the kernel source is a 4.4 kernel, so something weird is going on there. Maybe they got off 2.6 since the time the vulnerability was discovered?
I see something saying they moved to 4.4 in the 8.1 update in June 2017, which is confusing because it suggests the vulnerability was never live.
But I also see they have multiple CPUs running Linux and don't update the kernel on all of them at the same time, so perhaps the CPU running the 8686 driver wasn't updated?
It does not seem like software is much of a priority for them.
Think Banks and Windows XP. Except without Microsoft drawing a line in the sand and saying that they're no longer offering even paid support for it.
If the change doesn't bring in value for the shareholders (or business) there will be no change.
I find myself conflicted since i love the technology behind the new cars, but my paranoia about the lack of security and the inability of myself to do anything about it.
If only they had cameras in the cars so while they are applying the brakes when you are on the interstate they can collect that classic picture of horror on your face....
They already do. IIRC Model 3 has about 6 external cameras and one internal one. However, the internal one is currently disabled and isn't used for anything, which is a subject to change for when they decide what to do with it and push it in an update.
If you are looking for some wtf road videos, we are bound to see more of them soon due to the most recent update Tesla pushed. It added the "save on honk" option, which (if enabled) saves some footage right before the honk, as well as about 5 seconds after the honk. With how much spicy footage the sentry mode update has provided in less than a year, I expect nothing less from the "save on honk" update.
As a sidenote, it isn't as bad as it seems in terms of privacy, because all videos (on-honk ones, or manual ones, or the sentry mode accidents) only get saved locally on your HDD/SSD/usb-drive/etc (whatever you have inserted into one of the front USB ports).