Cryptography is not a magic bullet. The assertion of a signature is that "Private Key Bar says Hash(plaintext) = Foo." But who is the private key; who is actually computing the hash of the plaintext? Note that practically every cryptographic system in existence has been broken at one time or another, and most of those breaks are not in the mathematical primitives of cryptography but in the wider ecosystem of the procedures of how these primitives are combined into a full system.

In the threat model I describe, the attacker who controls the car's system can lie to the server about what is on its system. It also has access to anything that's distributed to the car itself (such as a per-car private key!), and presumably it has oracle knowledge in the form of what the server expects the correct hash to be. A compromised car can freely lie about the hashes of anything on its own system as necessary; it can freely sign any attestation with a per-car private key; it can parrot the expected hashes of files distributed to other cars. Even if you sent watermarked files to cars, the compromised car could remember the hashes of those watermarks to parrot them back later.

So, pray tell, where do you imagine the cryptographic signature actually adds value? As in, how can you pick the owner of the private key and the owner of the hashing process such that a near-omnipotent compromised car cannot fool the server?

The private key would need to be stored in some read only media like a smartcard or a PROM chip. A boot environment that can only be externally programmed would need to be the first thing to start up and check the integrity of the filesystem. It would hash it, timestamp it, and send it to an HSM to sign it with a secured private key, then transmit the signed hash out and hand off the rest of the startup to the main OS. Tesla gets the hash, verifies the signature so they can check whether or not the OS is compromised. Because the bootloader chip sits outside the control of the main OS, you can ensure that as long as someone doesn't rip out the ECU, the filesystem check is legit. Another step would be to allow the HSM to cycle in new keys using a KEK. The HSM would have a master private key that is only used for KEK updates and a lesser private key that it uses for signing hashes.

It's super hard to ensure something with 100% confidence, but it doesn't mean there shouldn't be at least some basic integrity checks.

How so? Telsa would most likely communicate with an API on the car and not directly running file hashes remotely.

What prevents an attacker from overriding some validateFile("path","hash") call to always return 0 ?

Because you could ask for a checksum of the firmware and if it doesn't return the right hash you know something isn't right.

You also never store the hash, so once a user has gained access to the car it's impossible to get the right hash (as you would've had to modify the firmware/filesystem/etc in some way to gain entry).

You would also need to include a timestamp/car serial in the hash so that you couldn't reuse an old hash from before your entry (that you had MITM'd) or use a hash from a different car that still had its integrity.