8 ms·

Complex Car Software Becomes the Weak Spot Under the Hood

85 points by rectang 11y ago

joesmo 11y ago
Obviously open sourcing the software is the only solution and everyone here knows that. Software security isn't a new problem, it's a many decades old problem with simple, effective procedures that can lead to proper solutions. Implementing those procedures and solutions isn't enough, as the most important part of security is trust and there can be no trust without transparency. Period. Software should be required to be open source if the authorities that be can't police it (and they can't). Let the people do for themselves what the government can't. I can't think of a single, logical reason why it shouldn't be open source (profit is not a logical reason when lives are at stake). Until more people die, of course there will be no significant changes in this industry. In fact, according to history, until enough people die to reach the threshold for anger in the public at large, there will be no changes in this industry.
- aleh 11y ago
  Opensourcing is not a replacement for QA practices. If it was, open source applications would never have critical bugs or security vulnerabilities. It may mitigate some issues in a long run (e.g. intentional backdors) but in a short run it will create havoc as access to source code will make it easier to create exploits. And suddenly you have whole new problem of making sure that everyone keeps their ECU software up to date or they risk fatal crash.
  - joesmo 11y ago
    "Opensourcing is not a replacement for QA practices." I'm not suggesting it is, simply that public oversight (open source) is the only way to ensure trust of a secure system. The system itself still has to be secure and requires QA like any other.
    - kaftoy 11y ago
      The only people who will understand that code (assuming is not just generated code) will be people from competitors... maybe. People outside the business will have no clue. It will be a continuous source of false alarms. Will be really hard to filter out the crap. Other people already talked about exploits. Every day you'll live the fear of "do I run up to date SW on my car???". This is not a phone. First you need to know the system, then you can understand what the code should do then you can have a fare chance of doing a code inspection. I think people parallelize too much to web development or other environments a lot more exposed to public development. People think that if you can read someone else's C code for voice communication, they will also be able to understand the C code behind a diesel injection system, air intake path, exhaust gas treatment, fuel mass setpoints calculation. If you have never been exposed to stuff like that, you cannot fully judge if the code is wrong. You may find something obvious here and there (like a loop that may go beyond the limit in theory but never in the field). And believe it or not, there is still competition for IP. Technical strategies of doing something in certain ways giving supplier X clear advantage in some field. Why would X share his knowledge just like that? We are talking about huge money. Never seen Google share the source of all they do.
ihsw 11y ago
ECUs have been notoriously badly programmed for years, they're usually contracted out rather than built in-house. Across wide swaths of Fortune 500 companies, they abhor the idea of having tech people on staff (for reasons I will not go into here) and just now it's starting to bite them in the ass hard. Proper discipline and established standards are, well, not established, so we get companies serving up product experiences to hundreds of millions of individuals where they are held together by duct tape and super glue (with varying degrees of quality but generally leaning towards overengineered+badly implemented). That said, there are some standards in place for these devices, but regulation is lax and punitive action rarely taken (it's an honor system). Compensatory and reactive costs are going to continue to rise as the steady flow of bad code borne from incompetence continues to accrue at exponential rates as more and more companies need tech built but aren't willing to expend the resources for it to be built properly. Thankfully, as mentioned in the article, some auto companies are starting to embrace the idea of maintaining a healthy staff of developers in-house. Tesla, notably, has over-the-air updates pushed to vehicles directly rather than requiring owners to bring their cars to the dealer.
- pjc50 11y ago
  abhor the idea of having tech people on staff (for reasons I will not go into here) Ah, go on. I'm guessing it's partly a Two Cultures problem (not wanting to give tech people status) and partly a cost problem?
  - nmrm2 11y ago
    That doesn't make sense to me because car companies hire huge numbers of automotive engineers (I think?) I always thought this was an engineering culture war thing -- software engineers aren't really engineers and software is sort of this silly thing that you use to glue together "real" engineering products. Hopefully the author of your parent post will elaborate some :-) (edit: I assumed you meant business-engineering culture war, not engineering-software. Might've been mistaken upon rereading)
    - structural 11y ago
stillsut 11y ago
The old car saying goes: Fast, Cheap, Reliable. Pick two, you can't get the third. Requirement creep seems to be the real problem here: Now we want aggressive fuel-efficiency targets, crash safety, and a host of other "nice to have" modern features. And it's in the computing unit which ends up trying to mediate these necessarily competing demands.
devingoldfish 11y ago
From the article: "New high-end cars are among the most sophisticated machines on the planet, containing 100 million or more lines of code." Does anyone know where this number comes from and if its realistic? It's hard for me to imagine unless you're counting all the LOC from Microsoft Windows: Car Edition or something.
- JamesSwift 11y ago
  I heard the same number quoted in an NPR story over the weekend and had the same reaction. I really can't imagine how they are getting to that number.
- spatulon 11y ago
  We're not just talking about one computer here -- it's not unusual for a modern car to have ~70 ECUs. Of course, many of those will be quite small, simple devices.
- radiorental 11y ago
  Can't answer where they came up with that number but it does seem rather larger. The only comparable machine where we do know the number is the Mars Curiosity Rover running somewhere around 2.5 Million LoC. Now, given that there are upwards of 200 micro controllers in a luxury car, I can see that number growing exponentially, but 100 Million???
  - pjc50 11y ago
    Embedded Windows in the UI (if present) would probably account for a large fraction of those.
    - nmrm2 11y ago
      Yes, that has always been my assumption -- they're probably counting operating system, libraries, etc. in those mlocs. It's X MLOCs in the car, not X MLOCs written by the car manufacturer.
  - TeMPOraL 11y ago
radiorental 11y ago
"One option for making auto software safer is to open it to public scrutiny. While this might sound counterintuitive, some experts say that if automakers were forced to open up their source code, many interested people — including coding experts and academics — could search for bugs and vulnerabilities. " This is simply not going to happen. Firstly, the majority of automotive control systems on an ECU are running generated code from toolschains such as CATIA Systems, Dymola, MapleSim, OpenModelica, SCICOS, SimulationX, Vertex etc etc etc. To validate against vulnerabilities requires in-depth knowledge of a particular manufacturer's modeling practices & standards. The code is not readable, the model is. Which relates to the second reason, the IP in these models is very closely guarded. Competitive advantage and product differentiations are pretty much all software now. Even suppliers and manufacturers share black box models & systems back and forth for fear of leaking IP. In a world where say BMW hands Bosch a set of requirement, Bosch supplies BMW HW and BMW validates in simulation and analysis with neither getting insight in to the other's design. You're telling that needs to now be done in the open?
- Zigurd 11y ago
  There are a lot of bad reasons for "closely guarded" IP: 1. The government told you to put spyware in e.g. your mobile baseband processor 2. Your GPU violates a lot of patents 3. You ECU implements dark patterns w.r.t. emissions testing Make regulations requiring publishing the code, and require making the toolchain available to code can be verified vs. the shipped image. Proprietary software isn't a valid excuse when the stakes are to poison the environment.
- nmrm2 11y ago
  I agree with you -- the push for opening up code to public scrutiny is politically and economically unfeasible. But that doesn't mean nothing can be done -- a more palatable regulatory regime might require oversight a la the aerospace industry, but emphasizing the use of formal methods over expensive and arbitrary process hoop-jumping.
  - radiorental 11y ago
    Agreed, here's what aerospace arrived at (organically too) https://en.wikipedia.org/wiki/DO-178B https://en.wikipedia.org/wiki/DO-178B

85 points by rectang 11y ago

Obviously open sourcing the software is the only solution and everyone here knows that. Software security isn't a new problem, it's a many decades old problem with simple, effective procedures that can lead to proper solutions. Implementing those procedures and solutions isn't enough, as the most important part of security is trust and there can be no trust without transparency. Period. Software should be required to be open source if the authorities that be can't police it (and they can't). Let the people do for themselves what the government can't. I can't think of a single, logical reason why it shouldn't be open source (profit is not a logical reason when lives are at stake). Until more people die, of course there will be no significant changes in this industry. In fact, according to history, until enough people die to reach the threshold for anger in the public at large, there will be no changes in this industry.

aleh 11y ago
Opensourcing is not a replacement for QA practices. If it was, open source applications would never have critical bugs or security vulnerabilities. It may mitigate some issues in a long run (e.g. intentional backdors) but in a short run it will create havoc as access to source code will make it easier to create exploits. And suddenly you have whole new problem of making sure that everyone keeps their ECU software up to date or they risk fatal crash.
- joesmo 11y ago
  "Opensourcing is not a replacement for QA practices." I'm not suggesting it is, simply that public oversight (open source) is the only way to ensure trust of a secure system. The system itself still has to be secure and requires QA like any other.
  - kaftoy 11y ago
    The only people who will understand that code (assuming is not just generated code) will be people from competitors... maybe. People outside the business will have no clue. It will be a continuous source of false alarms. Will be really hard to filter out the crap. Other people already talked about exploits. Every day you'll live the fear of "do I run up to date SW on my car???". This is not a phone. First you need to know the system, then you can understand what the code should do then you can have a fare chance of doing a code inspection. I think people parallelize too much to web development or other environments a lot more exposed to public development. People think that if you can read someone else's C code for voice communication, they will also be able to understand the C code behind a diesel injection system, air intake path, exhaust gas treatment, fuel mass setpoints calculation. If you have never been exposed to stuff like that, you cannot fully judge if the code is wrong. You may find something obvious here and there (like a loop that may go beyond the limit in theory but never in the field). And believe it or not, there is still competition for IP. Technical strategies of doing something in certain ways giving supplier X clear advantage in some field. Why would X share his knowledge just like that? We are talking about huge money. Never seen Google share the source of all they do.

ihsw 11y ago

ECUs have been notoriously badly programmed for years, they're usually contracted out rather than built in-house. Across wide swaths of Fortune 500 companies, they abhor the idea of having tech people on staff (for reasons I will not go into here) and just now it's starting to bite them in the ass hard. Proper discipline and established standards are, well, not established, so we get companies serving up product experiences to hundreds of millions of individuals where they are held together by duct tape and super glue (with varying degrees of quality but generally leaning towards overengineered+badly implemented). That said, there are some standards in place for these devices, but regulation is lax and punitive action rarely taken (it's an honor system). Compensatory and reactive costs are going to continue to rise as the steady flow of bad code borne from incompetence continues to accrue at exponential rates as more and more companies need tech built but aren't willing to expend the resources for it to be built properly. Thankfully, as mentioned in the article, some auto companies are starting to embrace the idea of maintaining a healthy staff of developers in-house. Tesla, notably, has over-the-air updates pushed to vehicles directly rather than requiring owners to bring their cars to the dealer.

pjc50 11y ago
abhor the idea of having tech people on staff (for reasons I will not go into here) Ah, go on. I'm guessing it's partly a Two Cultures problem (not wanting to give tech people status) and partly a cost problem?
- nmrm2 11y ago
  That doesn't make sense to me because car companies hire huge numbers of automotive engineers (I think?) I always thought this was an engineering culture war thing -- software engineers aren't really engineers and software is sort of this silly thing that you use to glue together "real" engineering products. Hopefully the author of your parent post will elaborate some :-) (edit: I assumed you meant business-engineering culture war, not engineering-software. Might've been mistaken upon rereading)
  - structural 11y ago

stillsut 11y ago

The old car saying goes: Fast, Cheap, Reliable. Pick two, you can't get the third. Requirement creep seems to be the real problem here: Now we want aggressive fuel-efficiency targets, crash safety, and a host of other "nice to have" modern features. And it's in the computing unit which ends up trying to mediate these necessarily competing demands.

devingoldfish 11y ago

From the article: "New high-end cars are among the most sophisticated machines on the planet, containing 100 million or more lines of code." Does anyone know where this number comes from and if its realistic? It's hard for me to imagine unless you're counting all the LOC from Microsoft Windows: Car Edition or something.

JamesSwift 11y ago
I heard the same number quoted in an NPR story over the weekend and had the same reaction. I really can't imagine how they are getting to that number.
spatulon 11y ago
We're not just talking about one computer here -- it's not unusual for a modern car to have ~70 ECUs. Of course, many of those will be quite small, simple devices.
radiorental 11y ago
Can't answer where they came up with that number but it does seem rather larger. The only comparable machine where we do know the number is the Mars Curiosity Rover running somewhere around 2.5 Million LoC. Now, given that there are upwards of 200 micro controllers in a luxury car, I can see that number growing exponentially, but 100 Million???
- pjc50 11y ago
  Embedded Windows in the UI (if present) would probably account for a large fraction of those.
  - nmrm2 11y ago
    Yes, that has always been my assumption -- they're probably counting operating system, libraries, etc. in those mlocs. It's X MLOCs in the car, not X MLOCs written by the car manufacturer.
- TeMPOraL 11y ago

radiorental 11y ago

"One option for making auto software safer is to open it to public scrutiny. While this might sound counterintuitive, some experts say that if automakers were forced to open up their source code, many interested people — including coding experts and academics — could search for bugs and vulnerabilities. " This is simply not going to happen. Firstly, the majority of automotive control systems on an ECU are running generated code from toolschains such as CATIA Systems, Dymola, MapleSim, OpenModelica, SCICOS, SimulationX, Vertex etc etc etc. To validate against vulnerabilities requires in-depth knowledge of a particular manufacturer's modeling practices & standards. The code is not readable, the model is. Which relates to the second reason, the IP in these models is very closely guarded. Competitive advantage and product differentiations are pretty much all software now. Even suppliers and manufacturers share black box models & systems back and forth for fear of leaking IP. In a world where say BMW hands Bosch a set of requirement, Bosch supplies BMW HW and BMW validates in simulation and analysis with neither getting insight in to the other's design. You're telling that needs to now be done in the open?

Zigurd 11y ago
There are a lot of bad reasons for "closely guarded" IP: 1. The government told you to put spyware in e.g. your mobile baseband processor 2. Your GPU violates a lot of patents 3. You ECU implements dark patterns w.r.t. emissions testing Make regulations requiring publishing the code, and require making the toolchain available to code can be verified vs. the shipped image. Proprietary software isn't a valid excuse when the stakes are to poison the environment.
nmrm2 11y ago
I agree with you -- the push for opening up code to public scrutiny is politically and economically unfeasible. But that doesn't mean nothing can be done -- a more palatable regulatory regime might require oversight a la the aerospace industry, but emphasizing the use of formal methods over expensive and arbitrary process hoop-jumping.
- radiorental 11y ago
  Agreed, here's what aerospace arrived at (organically too) https://en.wikipedia.org/wiki/DO-178B https://en.wikipedia.org/wiki/DO-178B