5 ms·

From the looks of it, they used the OSes the chipmakers provide in their reference packages. The stlinux stuff seems ripped pretty much verbatim from stlinux 2.

From the looks of it, they used the OSes the chipmakers provide in their reference packages. The stlinux stuff seems ripped pretty much verbatim from stlinux 2.4 [0] and the rest seems to be from Freescale/NXP's reference linux for their i.MX series [1]. Automakers, like a lot of other entities, rarely make their own distros themselves, but rather tend to use the reference OS provided by the chipmakers. [0] ftp://ftp.stlinux.com/pub/stlinux/2.4/ [1] http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-processors/i.mx53-processors/embedded-linux-for-i.mx-applications-processors:IMXLINUX?code=IMXLINUX&nodeId=0150522FC8ZrDR988D&fpsp=1&tab=Design_Tools_Tab http://www.nxp.com/products/microcontrollers-and-processors/...

suzeanne 11y ago
Excellent reply. Indeed, quite true. Though none of this excuses any negligence, no matter if it is the vendor of the manufacturer.
cmurf 11y ago
With software this old, there certainly are vulnerabilities, probably full on exploits available, that have also long since been patched. The attack surface of new products using old software is much higher than it ought to be. And consider not is it in need of updating before it's being driven off the lot, it's likely to have service updates for a time frame shorter than its useful service life. We're doing this wrong.
- xyzzy_plugh 11y ago
  You'd be surprised at the amount of effort to apply upstream patches or fixes to older vendor software. Many vendors also maintain older forks indefinitely. I've spent an inhumane amount of time applying/porting modern security fixes to ancient codebases. The root of the problem is: you buy a part, and to use the part you need some software to talk to it. The vendor, along with the part, supplies you with some sample code, which uses some ancient kernel and ancient GPLv2 utilities. If you use their code, then you perpetuate the problem. If you choose not to, then they won't help you when you have issues. Why do vendors use such ancient software? Vendors care deeply about their IP, and to some extent tivoization does happen with individual products, but more usually through obfuscation. Not a whole lot of open firmware for wireless chipsets, is there? Customer demand can change things, but vendors are afraid of their customers stealing their technology, and taking it to a cheaper competitor, or building it themselves. This stuff happens all the time. So they give you some code that talks some foreign language to their part or give it a seemingly black box blob of code to run and suddenly it's a black box to you too. Patents (for hardware), and China's lack of concern for IP theft are the root of all of this.
  - adrianratnapala 11y ago
    I think there is something more primal going on too. Vendors might at some time chose to say "freeze" and now we will just deliver this same binary blob, or at best generate new binary blobs from an ancient source stack we have under version control. Making changes means, at best, going through an expensive testing procedure. At worst, there is no such procedure and all change is an anethema. So they only make changes when they have to, and as the cost of staying obsolete increases, so does the cost of becoming up to date.
    - xyzzy_plugh 11y ago
      I tend to agree, but remember that for many vendors providing code that doesn't run/isn't tested on some LTS kernel means no one will use it. Or, you'll incorporate the vendor delivering support as part of the deal. Many times I've spent late nights babysitting an employee from $VENDOR debugging/fixing/rewriting their driver to play nice with our stack.
- belorn 11y ago
  I would guess that they have a package filter to prevent those vulnerabilities to be exploited. It seems a rather standard practice in places where updating is not a easy option, either because it breaks things or because of bureaucratic verification process, but where filter rules can easily be kept updated.
- coldpie 11y ago
  This is why you never connect anything that isn't running a supported and update-able operating system to the internet. That includes your car, your TV, your washing machine, your printer, your fridge, and your old Windows XP box.

suzeanne 11y ago

Excellent reply. Indeed, quite true. Though none of this excuses any negligence, no matter if it is the vendor of the manufacturer.

cmurf 11y ago

With software this old, there certainly are vulnerabilities, probably full on exploits available, that have also long since been patched. The attack surface of new products using old software is much higher than it ought to be. And consider not is it in need of updating before it's being driven off the lot, it's likely to have service updates for a time frame shorter than its useful service life. We're doing this wrong.

xyzzy_plugh 11y ago
You'd be surprised at the amount of effort to apply upstream patches or fixes to older vendor software. Many vendors also maintain older forks indefinitely. I've spent an inhumane amount of time applying/porting modern security fixes to ancient codebases. The root of the problem is: you buy a part, and to use the part you need some software to talk to it. The vendor, along with the part, supplies you with some sample code, which uses some ancient kernel and ancient GPLv2 utilities. If you use their code, then you perpetuate the problem. If you choose not to, then they won't help you when you have issues. Why do vendors use such ancient software? Vendors care deeply about their IP, and to some extent tivoization does happen with individual products, but more usually through obfuscation. Not a whole lot of open firmware for wireless chipsets, is there? Customer demand can change things, but vendors are afraid of their customers stealing their technology, and taking it to a cheaper competitor, or building it themselves. This stuff happens all the time. So they give you some code that talks some foreign language to their part or give it a seemingly black box blob of code to run and suddenly it's a black box to you too. Patents (for hardware), and China's lack of concern for IP theft are the root of all of this.
- adrianratnapala 11y ago
  I think there is something more primal going on too. Vendors might at some time chose to say "freeze" and now we will just deliver this same binary blob, or at best generate new binary blobs from an ancient source stack we have under version control. Making changes means, at best, going through an expensive testing procedure. At worst, there is no such procedure and all change is an anethema. So they only make changes when they have to, and as the cost of staying obsolete increases, so does the cost of becoming up to date.
  - xyzzy_plugh 11y ago
    I tend to agree, but remember that for many vendors providing code that doesn't run/isn't tested on some LTS kernel means no one will use it. Or, you'll incorporate the vendor delivering support as part of the deal. Many times I've spent late nights babysitting an employee from $VENDOR debugging/fixing/rewriting their driver to play nice with our stack.
belorn 11y ago
I would guess that they have a package filter to prevent those vulnerabilities to be exploited. It seems a rather standard practice in places where updating is not a easy option, either because it breaks things or because of bureaucratic verification process, but where filter rules can easily be kept updated.
coldpie 11y ago
This is why you never connect anything that isn't running a supported and update-able operating system to the internet. That includes your car, your TV, your washing machine, your printer, your fridge, and your old Windows XP box.