Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Software quality and security (out of Market Action)

This site may earn commission on affiliate links.

Fact Checking

Well-Known Member
Aug 3, 2018
7,517
120,784
Vienna
Asking those of you with better programing/system chops, do this guys criticisms seem to have merit?

So Tesla's code quality is probably messier than that of "pure" high-tech companies like Google or Apple, but it's still much, much better than typical automotive software. Security design at Tesla seems to be robust. Note that code quality problems very likely do not affect Andrej Karpathy's AI group or the AI chip, which are probably Tesla's most important software/hardware projects.

Tesla's road-map so far has been to put out one fire after another and probably cutting code quality corners, and I'd expect that with time this will all improve: SpaceX has high software standards and I suspect Elon is going to match Tesla's software practices to that of SpaceX's.

Takes time and the ease of mind of profitability.
 
Asking those of you with better programing/system chops, do this guys criticisms seem to have merit? Also, do we have insight into the general level of satisfaction of current IT team?

I don't have insights into Tesla's current IT team. My impression, as an owner, investor, and someone that reads as much as I can find about Tesla, is that their software development process does need work, especially in QA. They have the feel of a startup that rushes code out the door without thorough testing.

As for this guy's criticisms.... I think some of them are justified but I think he's exaggerating to push his point of view. No company has perfect software. In fact, technical debt is a real thing everywhere. As others have said, "don't look at how your sausage is made". It feels great when you can release clean code to production. However, the most important thing is always to get it to work and get the job done. It doesn't make the company money to have developers spend an extra month refactoring working code to make it cleaner, even if that is our preference in software development.

As someone else mentioned on Reddit, and I agree with, this guy's comments give the impression that he's one of those people with an ego larger than his skills. Not that he doesn't know a fair bit, but he comes off as someone that tries to make everything sound more technical and more complex than necessary (when explaining to someone else) so you think he's smarter and think he knows everything he is saying. I've created and hired multiple development teams in my career. I was a developer for about ten years and then I've been in management for another ten. It's always a relief to see people like this guy leave the company. Nobody else's work is ever good enough to them and they have a complaint / concern for every solution.

Consider that many banks are still running with COBOL written in the 1960s. No one is perfect and you can improve just about any code base you find.

All of that said, I do think Tesla needs to improve their software dev process.
 
Why? Obviously remote connection with fees immediately charged to credit cards. Idle fees charged to cars. They have always kept records of who is charging. Salvage cars not allowed. I wonder if police will get around to requesting records as part of investigations

There's a difference between having a thin-bandwidth remote *communications protocol* and allowing for a complete remote *software update*.

I may be a bit old-fashioned, but I have computers which can communicate with the Internet, but cannot have their software updated over the Internet. The communications is limited (sandboxed).
 
I believe all of this. Tesla's code is quite obviously a complete mess.

What surprised me is that Superchargers can have their firmware remotely updated (!!!)

Unfortunately, it sounds to me like almost every major commercial software project ever.

Or, as XKCD put it (particularly the comment from the girl at the bottom of the bottom left panel):

voting_software.png
 
Asking those of you with better programing/system chops, do this guys criticisms seem to have merit?
Yes. For perspective, anything related to Microsoft Windows is substantially worse. Most IT is a mess. It's a pleasure to occasionally work on a really tight, cleanly coded module -- in other words, it's rare.

Let this disabuse anyone of the notion that Tesla has "the most advanced software". They've got somewhat-below-average software running on the most advanced *hardware*.

That said, it looks like the modules for driving were given a lot more attention than the other modules and probably have higher coding standards. And you'll note that *the ex-employee indicates this*: he or she says there was a very strong culture of extreme care around physical safety (excepting Autopilot/Summon) but no care about information security.

Nearly everything this person said confirmed my hunches based on what I've seen for the last 5 years.

Also, do we have insight into the general level of satisfaction of current IT team?
No.
 
So Tesla's code quality is probably messier than that of "pure" high-tech companies like Google or Apple, but it's still much, much better than typical automotive software. Security design at Tesla seems to be robust. Note that code quality problems very likely do not affect Andrej Karpathy's AI group or the AI chip, which are probably Tesla's most important software/hardware projects.

Tesla's road-map so far has been to put out one fire after another and probably cutting code quality corners, and I'd expect that with time this will all improve: SpaceX has high software standards and I suspect Elon is going to match Tesla's software practices to that of SpaceX's.

Takes time and the ease of mind of profitability.

I read over all those messages and you could replace Tesla with almost every tech company on Earth. I find it hilarious the commentary of "Afraid to touch systems in case something breaks." Now that is extremely prevalent. Engineers, project managers, directors, C-Levels - plenty of people on a chain that would veto revamping an in place production system.

The speculation of how Model 3 was handled is what I would expect how one would handle solving the dilemma above. Build a new system from ground up to run side by side with the existing system. Have Model 3 utilize the new system. Model Y will use the new system, and S/X migrates over.
 
While I'm very intellectually curious about everything he posted, I'm also upset. He's basically posted a blueprint for anyone (rogue individual, nation state) who wants to try to find a way to attack Tesla's infrastructure.

The other thing he hasn't considered is that posting that information publicly is a good way to make future job searches much more difficult. What company wants to hire someone that, years later, will do that to a former employer?
 
So Tesla's code quality is probably messier than that of "pure" high-tech companies like Google or Apple,
Actually, a lot of Google and Apple code is pretty messy too. I have heard that Amazon code is unusually clean, perhaps due to the extreme stress testing it gets (practically everyone is trying to overload it, hack it, or bring it down all the time).

but it's still much, much better than typical automotive software. Security design at Tesla seems to be robust.
No, Tesla's security design is not robust (not like, say, the software recommended by Edward Snowden for secure communications; not like OpenBSD).

But it's still more robust than other automotive software, which is essentially totally insecure.

The thing most people don't realize is just how low code quality standards are in *general*. If you're running Microsoft Windows -- any version -- you have a lot of code which is worse than anything Tesla is using. If you have *any* embedded device *at all*, you probably have code which is worse than anything Tesla is using (though likely better than Windows).

I would *rather* Tesla had old-school IBM commercial-grade standards, or the sort of standards used for acceptance of patches into the Linux kernel or GCC mainline, but slapdash and sloppy has been the way of things in commercial IT since the early 1990s.

Note that code quality problems very likely do not affect Andrej Karpathy's AI group or the AI chip, which are probably Tesla's most important software/hardware projects.

Tesla's road-map so far has been to put out one fire after another and probably cutting code quality corners, and I'd expect that with time this will all improve: SpaceX has high software standards and I suspect Elon is going to match Tesla's software practices to that of SpaceX's.
I wish. :)

Takes time and the ease of mind of profitability.
Large portions will have to be rewritten from scratch, probably including module interfaces. That is unfortunately normal too.
 
Last edited:
  • Informative
Reactions: Cobos and bhtooefr
Let this disabuse anyone of the notion that Tesla has "the most advanced software". They've got somewhat-below-average software running on the most advanced *hardware*.

I think we should really qualify that by Tesla software project:
  • Tesla's corporate IT, accounting and legal is probably using Microsoft and is probably the usual mess
  • Tesla's factory automation ("Factory OS") is probably using a robust frameworks, is probably top-notch, with the occasional per robot station mess
  • Tesla's in-car control software probably has a robust core which is probably top-notch, but interfaces with a colorful set of industry standard hardware components which can be a mess
  • Tesla's in-car GUI went through a number of framework transitions and was probably a mess at certain stages. The Model 3 one is probably better, and more fun to work on.
  • Tesla Energy/Storage is probably using robust frameworks and code
  • Tesla's AI project is using open source components and robust design principles, is probably top notch
  • Tesla's AI-Chip project is using cutting edge principles and is probably top notch
And I think it's safe to say that Tesla has the "most advanced software" in all of automotive, which is what matters most in this context.

Tesla is not at Google or Amazon levels of code quality - Tesla will need a couple of years of profitability and a few cycles of internal standardization to reach that stage I think.
 
While I'm very intellectually curious about everything he posted, I'm also upset. He's basically posted a blueprint for anyone (rogue individual, nation state) who wants to try to find a way to attack Tesla's infrastructure.
You don't work in IT, or haven't done so for long, have you?

"Security by obscurity" is completely discredited in the IT business. Best security practice is to publish blueprints. Any determined attacker, and even a *casual* attacker, already had all this information. It's trivial to get; I probably could have gotten it with automated scripts (like the "Canadian kid" who he references). So there's no need to be upset. This guy didn't actually reveal anything which would increase Tesla's risk profile.
 
The other thing he hasn't considered is that posting that information publicly is a good way to make future job searches much more difficult. What company wants to hire someone that, years later, will do that to a former employer?
Pfft. This is no different than the stories I've heard about Amazon, Google, Apple, Microsoft, Samsung, Sperry, Burroughs, DEC... sharing old war stories about programming isn't going to affect his or her employment.

Ever read _The Soul of A New Machine_, by Tracy Kidder?
 
There's a difference between having a thin-bandwidth remote *communications protocol* and allowing for a complete remote *software update*.

I may be a bit old-fashioned, but I have computers which can communicate with the Internet, but cannot have their software updated over the Internet. The communications is limited (sandboxed).
The cynical among us software developers would say that if it's connected to the internet, it can have its software remotely updated by lots of people.
 
You don't work in IT, or haven't done so for long, have you?

"Security by obscurity" is completely discredited in the IT business. Best security practice is to publish blueprints. Any determined attacker, and even a *casual* attacker, already had all this information. It's trivial to get; I probably could have gotten it with automated scripts (like the "Canadian kid" who he references). So there's no need to be upset. This guy didn't actually reveal anything which would increase Tesla's risk profile.

Your assumptions are wrong about me**, and there's a huge difference between "security only through obscurity" and "security including obscurity". If you disagree, go tell your webadmin to turn on the printing of server error messages to end users rather than an Error 5xx and see what he or she says. The very process of attacking someone's infrastructure involves trying to figure out how it's set up - what they're running, what talks to what, etc, etc. Found an SQL injection exploit, for example? Great, but now what columns in what tables are you needing to alter? These are the bottlenecks in escalating an attack. Of course the most effective attacks these days are spearfishing, but even there, internal information is key to that.

** I'm actually the winner of one of the Underhanded C coding competitions. Wish they'd run another one, I've got an awesomely evil attack in mind, incl. a tested demo framework ;)
 
Last edited:
So there's no need to be upset. This guy didn't actually reveal anything which would increase Tesla's risk profile.

So I've now gone through and read the whole twitter exchange, and got this impression:
  • The guy clearly worked on Tesla's security code, and most of the everyday problems he listed ring true.
  • He points out that he hasn't worked on Tesla software for 3+ years and that he hasn't worked on the Model 3, and he has a few good things to say about Model 3 software.
  • His "fvck you Bosch" shows the difficult environment Tesla firmware developers have to work in: lots of external components come with decades of interface baggage, and Bosch as the R&D center of German automotive probably isn't ... exactly forthcoming to troubleshoot Tesla problems. It's comparably easy for Amazon or Google to write clean code, they get to work in a mostly standard environment with built-to-order servers ... Tesla had to make do with what automotive had been using for decades.
  • He sure has a big axe to grind! He (ab-)uses any credibility he gains by correctly characterizing Tesla's software environment to launch ad hominem attacks against Tesla managers and Elon. The 'see panel gaps with a telescope' comment was a dead giveaway of bias. He hasn't worked at Tesla for 3+ years so why did he expect Elon to have been involved at the factory: Elon only took over last year, when the Model 3 ramp-up mess surfaced. When this guy was employed Elon was spending 80%+ of his time on SpaceX.
So I didn't see anything particularly worrisome in these tweets, but I do hope Tesla internal IT reads those and double checks the deployment security assumptions of their deployment data-center. (They might have done that in the last 3 years, after a couple of high profile security incidents.)

I base my good opinion of Tesla Model 3 security partly on the examination of the Bluetooth unlock app that was performed recently by someone (no link, sorry) - and he found robust cryptography.
 
Pfft. This is no different than the stories I've heard about Amazon, Google, Apple, Microsoft, Samsung, Sperry, Burroughs, DEC... sharing old war stories about programming isn't going to affect his or her employment.

Ever read _The Soul of A New Machine_, by Tracy Kidder?

I haven't, and this isn't the first time it's been recommended, so I need to add it to my list.

When I moved into management and starting hiring, one of the surprises was just how much recruiters and HR staff look for a reason to not consider an applicant. It's made me much more cautious about my online posting.
 
So I've now gone through and read the whole twitter exchange, and got this impression:
  • The guy clearly worked on Tesla's security code, and most of the everyday problems he listed ring true.
  • He points out that he hasn't worked on Tesla software for 3+ years and that he hasn't worked on the Model 3, and he has a few good things to say about Model 3 software.
  • His "fvck you Bosch" shows the difficult environment Tesla firmware developers have to work in: lots of external components come with decades of interface baggage, and Bosch as the R&D center of German automotive probably isn't ... exactly forthcoming to troubleshoot Tesla problems. It's comparably easy for Amazon or Google to write clean code, they get to work in a mostly standard environment with built-to-order servers ... Tesla had to make do with what automotive had been using for decades.
  • He sure has a big axe to grind! He (ab-)uses any credibility he gains by correctly characterizing Tesla's software environment to launch ad hominem attacks against Tesla managers and Elon. The 'see panel gaps with a telescope' comment was a dead giveaway of bias. He hasn't worked at Tesla for 3+ years so why did he expect Elon to have been involved at the factory: Elon only took over last year, when the Model 3 ramp-up mess surfaced. When this guy was employed Elon was spending 80%+ of his time on SpaceX.
So I didn't see anything particularly worrisome in these tweets, but I do hope Tesla internal IT reads those and double checks the deployment security assumptions of their deployment data-center. (They might have done that in the last 3 years, after a couple of high profile security incidents.)

I base my good opinion of Tesla Model 3 security partly on the examination of the Bluetooth unlock app that was performed recently by someone (no link, sorry) - and he found robust cryptography.

On your last bullet, you’re wrong. In the early days Elon’s desk was in the middle of the factory floor and there were publicly recorded periods of time Elon said he was sleeping on the factory floor (long before M3). So the tweeter in question would have known/experienced Elon right in the middle of things when he worked there.
 
The cynical among us software developers would say that if it's connected to the internet, it can have its software remotely updated by lots of people.

That's too cynical, and essentially provably false. There are "narrow servers" with narrow data protocols which have been immune to any form of remote attack other than a Denial of Service. (Denial of Service is always possible.)

Code/data separation is a thing. It is a *choice* to allow execution of code from a remote source, and it is a *choice* to trust data from a remote source for more than hexdumping it!

As you know, arbitrary remote execution on a modern Linux, Mac, or other UNIX-based box requires a series of privilege escalations, one after another: you have to manage to get your crafted data past data validation, you have to find a buffer overflow or scripting engine coding error to turn the data into instructions for executible code (and bypass the nonexecutable data page / nonwritable code page hardware restrictions), then you have to find an error in a setuid system library or kernel call to escalate to root privileges before you can "remotely update" the software. It's actually not straightfoward at all. And that's if you don't have any additional firewalls or privilege restrictions.

(The irritating thing is that most web browswers now have scripting engines which are far too powerful. Turing-completeness is bad!)

Android and iPhone are based on the same design, but some people thought it would be a good idea to always have a program running as root which automatically downloaded (and, given the right settings, automatically installed) programs from an arbitrary remote server. And to not give root privileges to the owner of the phone.

*Sigh*.

That's not how servers or workstations are operated.
 
Last edited:
  • Love
Reactions: Lessmog
The cynical among us software developers would say that if it's connected to the internet, it can have its software remotely updated by lots of people.
Precisely. I was aghast when hospitals I was developing for replaced 3270s with Windows PCs running a terminal emulator with Internet access. If you want to protect something don't let people access the Internet. Though there are ways to lesson the ability to break in, is there any way short of cutting off Internet access to make a system truly secure? I know there are a few businesses that still use DOS applications on OS/2 systems because they are too terrified of being hacked, and IBM abandoned support for OS/2 20 years ago. But finding hardware to run those on is becoming more and more difficult, though there is at least one company that is still making money supporting these systems. Talk about niche...

All that said I don't want to give up OTA updates and as bad as the Tesla audio system is light years better than the multichanger CD/radio in my previous Toyota. Sounds great and the touch screen interface is amazing, just wish they could remember whether I had the audio on or off when I last left my X.
 
  • Love
Reactions: neroden