Hacker News new | ask | show | jobs
by xg15 3877 days ago
It also would prevent government agencies from demanding i.e. the source code of a car's ECU to verify its safety and emissions behavior.

The only way out of this would be to declare car ECUs (or other systems) as "critical infrastructure", the definition of which I'm sure will be subject to many political tug-of-wars once this is implemented.

3 comments

Playing the devil's advocate here, but you shouldn't need access to a car's source code to measure its emissions. The test is broken, not the software.
But you can imagine an internal AI that can tell whether it's being watched by the government with arbitrarily sophisticated means. In fact, that's just an extreme example of how VW broke rules. It wasn't, as I think you might be imagining, a case where the emission measuring device was lazy and just took the car's word for it. Rather, the car's software determined that it was being tested (based, I think, on various cues from how it was being driven), and lowers emissions in those situations.
Or even simpler: if $INTERNAL_CLOCK < $PROJECTED_DATE_OF_SALE { fake_emissions; }
Many states in the US force you to test emissions when you register your car.
if(miles_driven < 10,000) { fake emissions; }
You often have to renew this every few years, or when you move to a new state. Even my 16-year-old Chevy Caprice with 200k+ miles had to run the CA gauntlet.
I mean that would be a pretty crappy defeat device
Expounding further - what government agency has the time or money to actually sift through mountains of source code?

From a pure financial standpoint, there's no possible way that it isn't cheaper to just measure real emissions than attempt some kind of software analysis for every version of every vehicle on the market.

Furthermore, an agency inspecting source code has absolutely no way to tell whether or not that the source they've been given is actually what's running on a car.

Just as a counterpoint: the Nevada Gaming Commission has plenty of time and money to sift through the source code of every gaming device that gets deployed in NV.
Compared to any car ECU and related software, gaming machine software is rather simple. Not exactly trivial, but much simpler, and the state can afford to set rather arbitrary behavioural restrictions.

Similar restrictions would severely cripple innovation in cars. Just consider Tesla's autopilot software.

If I write the software for those devices in ASM, do/can they still look through it?

Is there some kind of formal engineering practice they require manufacturers to adhere to?

How are their staff qualified to read the vast variety of languages out there?

I cite these as immediate, obvious roadblocks to verification, regulation, because they're easy and many PLs are something that the vast majority of the software industry are not used to.

Do we have specific evidence that they actually do sift through the source code? They demand its submission, but how do we know they actually do anything with it? I'm asking this as a serious question.
It doesn't really matter if they sift through every one so long as they have them on record. If there's ever an allegation of misconduct, the code can be examined in full by any large variety of experts.
If you have source code then you can tell whether a particular executable was built from said source code. Pull the executable out of the car and also build the source code yourself as instructed by the manufacturer, compare the two binaries.

If the binaries don't match, then whatever certification the device needs automatically fails and it cannot be sold.

What that means is that later on, if "Something Bad" happens, you are in a position to be certain of what code was running. This makes investigation much easier as there is no chance that the original source code cannot be found when needed later. This does get a bit more complicated with software updates, especially OTA updates.

To me, this seems like a relatively difficult feat.

- Are governments and other regulatory agents going to formally verify compilers?

- Are these agencies going to prevent software from being written that doesn't conform to their rigid standards?

- Many compilers, technologies in use today aren't perfectly deterministic. Optimizations, flags, etc. can all dramatically affect an emitted binary.

- What if I want to use a completely different architecture than a regulatory agency is used to? Am I just not allowed to?

And as you mentioned, updates.

With the ability to do OTA or any other updates, software becomes almost impossible to identify or deal with.

The point isn't for regulators to have to sift through code line by line or do something complicated like verifying compilers. I'd propose that the industry can pretty much do whatever they like in terms of technology, so long as it's inspectable and meets other regulations of course. If they can't provide repeatable instructions for building their code then they should not be working on something safety critical anyway.

I'm not familiar with exactly what software regulations exist today for the auto industry, but certifications for repeatable software processes (including build and deploy) are nothing new.

The point is that we should trust the industry to do the right thing, but also maintain our ability to double check. Until something like the VW defeat scandal happens it doesn't make sense to invest the resources needed to really dig in.

Updates and cheating can be detected by requiring service stations to pull software from randomly chosen vehicles during annual inspections. In the US we could use the standard highway funding threats to require states to enact such laws.

In a similar vein, what government agency has the time or money to actually review every single diagram for a building to be constructed?

It's actually the same problem: an extremely complex object is being constructed, a critical failure within which could leave many people nearby injured or dead.

The solution is actually somewhat ingenious: License a small group of people to go analyze such things, let them organize themselves independently, but require them to sign off on the design. It turns out that with their license and livelihood on the line, enough people aren't willing to sign off on terrible, shoddy crap that the system mostly works.

Perhaps it's time that software grew up and became something closer to a real engineering discipline?

> Perhaps it's time that software grew up and became something closer to a real engineering discipline?

Filled with red tape, inaccessibility, limitations?

No thanks. I think we've done a very decent job of self-regulation, licensure and review have fared well for most* life-threatening software systems.

You not only have to sift through the code, but compile and flash it yourself.
You want repeatable conditions for tests so that you can compare results between models, and against the norms.

When you have repeatable conditions - software in the tested product can detec that and act differently in these conditions.

That's exactly what happened in VW case.

It's nontrivial to fix the test so that it is still repeatable and hard to fool by company determined to fool it.

Randomized test with a suitable number of runs will cost-efficiently give useable results.

I agree, it's not trivial. But, it's not hard either.

You don't, you need access to great if those are the emissions when the engine is running as it normally would under regular driving conditions.

It's like weighing someone, you don't need to see their feet, but if you can't then you can't tell if they have both feet on the scale.

The test should be to validate software is correct.
The text draws a distinction between mass market software and infrastructure.

I haven't studied it closely to see how narrow those meanings are, but it seems like emissions control software might fall under infrastructure (I also guess that mass market is talking more about shrink wrap software than embedded software, you don't use an ECU in the same way that you use a word processor).

That doesn't seem unreasonable. How much do you trust arbitrary 3rd world country's transport department to keep your trade secrets really secret? Any answer other than "hardly" suggests you haven't spent much time in poorer countries...