I've seen these issues before professionally, and they typically originate from lack of internal storage APIs and management buy-in for all teams to use them and only them.
I'm purely speculating here but imagine if every team (Calendar, Spotify Integration, Netflix Integration, WiFi, etc) was writing their own storage code; the MCU is a glorified Ubuntu distro so different teams decide to scatter files all all over the place or re-use existing Linux services (e.g. WiFi credential storage). Particularly if they're doing the smart thing and giving each app/components its own Linux user/UID.
Then the inevitable question becomes: How do you wrangle it all for a reset? That's where a storage API comes into play, or you just "nuke the entire thing from orbit" and overwrite the running partition using some stored image using a pre-boot environment but even then the data might not be removed from the physical storage chips.
Chrome OS ran into this problem, and solved it by directing writes to an encrypted stateful partition. To reset, you then "simply" securely erase the encryption key, which is much faster than full-disk-overwrites of yore. (There are additional details, like "how do you do updates?")
But in an embedded context, I would speculate that a single unencrypted filesystem is nice for debugging and the like.
Given the anecdotes of "in the early days we had to parallel ssh into individual cars to apply patches", I could imagine this just fell by the wayside in the name of "ship faster".
The best way to do this is to use a standard physical interface for the storage. Then to do a factory reset you remove the storage device, plug it into any PC, nuke whatever is there and replace it with the latest clean image from the manufacturer's website.
This also makes the vehicle almost impossible to brick through damage to system data (worst case: remove drive and reimage) and allows the new owner to do the same thing to be assured that the vehicle is not harboring malware.
With modern hardware, I think you have to give up on overwriting everything. Bad blocks get mapped out, wear leveling interferes, so “all logical blocks” never is “all physical blocks”. The hardware might Have a “overwrite all physical blocks”, but it might not even be able to overwrite bad blocks (they can be bad in any number of ways), where adversaries with enough perseverance can read them.
Also, why trust the hardware when you don’t need to? Encrypt the volume from the get go, throw away the key when you want to keep the store, but destroy the data, and you make sure the key didn’t get leaked elsewhere.
Thinking of that: it would be useful to have a static code analyzer that could tell you, for example, whether the result of “getEncryptionKey” might end up in a call to “println”, “log”, or “write”. Do these exist?
Last time I was trying to sell my Tesla, I used factory reset, entered credentials, the car rebooted, data still fully here. Tried again multiple times. Nothing happened. I don’t think that functionality is tested properly even for the basic erasure that you can visually confirm, let alone properly wiping the storage. If someone is reading this at Tesla, you should encrypt storage and destroy the key on reset.
I have a Model 3, and bought the FSD upgrade for $2K when it was on sale for a couple weeks. I've been wanting to schedule the upgrade of the autopilot computer from hardware 2.5 to hardware 3, but now I'm scared. I always considered a Tesla to be like an iPhone - you factory reset/wipe it before you sell it to someone, but if the manufacturer swaps out your computer and doesn't have good hygiene, yikes!
TLDR: I'm going to wait until I hear they have good data hygiene before I let them swap out my computer.
I'm surprised nobody has taken them to Small Claims to recuperate the obnoxious $1k fee for relinquishing your old, defunct part. Seems like an easy win.
Core charges are permitted under statute requiring the return of replaced parts.
The problem is the lack of consistency. The core charge communicated can vary wildly between locations and staff performing the work, and some owners are told the part is restricted and no return is possible. In these cases, legal complaints with your state’s Attorney General might improvise Tesla’s consistency across the org. With other issues, I’ve had good luck with certified letters to Tesla’s legal service address, YMMV.
[+] [-] Someone1234|5 years ago|reply
I'm purely speculating here but imagine if every team (Calendar, Spotify Integration, Netflix Integration, WiFi, etc) was writing their own storage code; the MCU is a glorified Ubuntu distro so different teams decide to scatter files all all over the place or re-use existing Linux services (e.g. WiFi credential storage). Particularly if they're doing the smart thing and giving each app/components its own Linux user/UID.
Then the inevitable question becomes: How do you wrangle it all for a reset? That's where a storage API comes into play, or you just "nuke the entire thing from orbit" and overwrite the running partition using some stored image using a pre-boot environment but even then the data might not be removed from the physical storage chips.
[+] [-] cbhl|5 years ago|reply
But in an embedded context, I would speculate that a single unencrypted filesystem is nice for debugging and the like.
Given the anecdotes of "in the early days we had to parallel ssh into individual cars to apply patches", I could imagine this just fell by the wayside in the name of "ship faster".
[+] [-] zrm|5 years ago|reply
This also makes the vehicle almost impossible to brick through damage to system data (worst case: remove drive and reimage) and allows the new owner to do the same thing to be assured that the vehicle is not harboring malware.
[+] [-] Someone|5 years ago|reply
Also, why trust the hardware when you don’t need to? Encrypt the volume from the get go, throw away the key when you want to keep the store, but destroy the data, and you make sure the key didn’t get leaked elsewhere.
Thinking of that: it would be useful to have a static code analyzer that could tell you, for example, whether the result of “getEncryptionKey” might end up in a call to “println”, “log”, or “write”. Do these exist?
[+] [-] sandworm101|5 years ago|reply
[+] [-] mehrdada|5 years ago|reply
[+] [-] mixmastamyk|5 years ago|reply
[+] [-] illumin8|5 years ago|reply
TLDR: I'm going to wait until I hear they have good data hygiene before I let them swap out my computer.
[+] [-] rkagerer|5 years ago|reply
[+] [-] toomuchtodo|5 years ago|reply
The problem is the lack of consistency. The core charge communicated can vary wildly between locations and staff performing the work, and some owners are told the part is restricted and no return is possible. In these cases, legal complaints with your state’s Attorney General might improvise Tesla’s consistency across the org. With other issues, I’ve had good luck with certified letters to Tesla’s legal service address, YMMV.
[+] [-] sschueller|5 years ago|reply
[+] [-] paulcole|5 years ago|reply
[+] [-] dang|5 years ago|reply