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.
Do they even still exist? It's impossible to find anything on these modules beyond FCC filings; some pixelated datasheets show the modules with "www.parrot.com" printed on them but going as far back as 2017 in the WWW archive, that site belongs to some drone startup.
Marvel fixed the bug in their firmware and apparently Tesla shipped some sort of update, I don't see anything that necessarily requires Parrot, the obscure maker of these modules, to do anything.
Oh! You misunderstood my question: I meant to ask whether Tesla's latest software update continues to ship a 2.6.36 kernel on Parrot, or a newer kernel instead, as they do for their other modules.
(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.
I think the root of the confusion here is that you think Parrot is just a Tesla nickname. But Parrot is the name of the manufacturer of the fully-integrated WiFi+Bluetooth module so Tesla likely have nothing to do with the firmware that runs on that module with the ancient kernel.
Oh, I didn't get that impression. Keen's previous Black Hat paper made it sound like Tesla is dual-maintaining 2.6.36 and 4.x kernels, because they're unable/unwilling to upgrade from 2.6.36 on the Parrot board but are still issuing kernel fixes for it.
Looking at the datasheet some more, it does seem like the intention is for Tesla (or some other customer) to develop userland software and integrate that with Parrots SDK into a final firmware image for the module. But in that case, their situation is much the same as it is with the nVidia Tegra entertainment board: you are totally dependent on nVidia and Parrot to provide the basic infrastructure from bootloader to a Linux kernel with drivers to interface all the functionality they are selling you (a BSP). None of their hardware has any part upstreamed.
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.
This is fine, but not an answer to the actual question of whether Tesla is still shipping 2.6.36 on a Model S's Parrot system today. Parrot-the-company could have given an updated kernel in the year or so since the vulnerability was reported, or like you say Tesla could have taken on the mammoth task of maintaining an out of tree arch port themselves. It would be useful to know whether this happened, since if it's still running 2.6.36 it would be reasonable to consider the devices as extremely vulnerable in the wild today.
> 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..
> 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.
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:
- 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.
> why the fuck and how can Android phone and other embedded device makers get away with not publishing anything?
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.
It's important to remember that the GPL does not require that the modified source be publicly accessible, only available to those who you've distributed the modified program to. How that's verified and distributed is unspecified.
> only available to those who you've distributed the modified program to
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
There's two issues with that. First, that's only one of three available options (two for commercial entities) that satisfy the license. The other is to include a copy of the source code with the software distribution. However, separately, this does not require that the source code be posted in a public place for anyone to access. You only must give with the distribution a written offer. That offer is valid to anyone, but it doesn't need to be posted in public and the source code does not need to be posted in public.
(Note that this article is only talking about the dashboard entertainment machine, which probably isn't the one the wifi chip's connected to. Perhaps that one got slower updates.)
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.