I think the problem is as often not about careing, and being unaware of anything outside their little subsystem.

You used to have what was essentially airgapped and self contained.

But then feature x needed an ongoing net connection, and it happens to run on the same soc as feature y that talk to the can bus, and boom.

Neither of the teams responsible for the features considers that something can jump from x to y, almost like an illness jumps between species.

Damn it, the other day HN linked to an article on how VMs sharing hardware could talk to each other using the CPU cache.

> VMs sharing hardware could talk to each other using the CPU cache

That sounds similar to a paper I read ~20 years ago that described a way to move data from a high privilege process, bypassing mandatory access control (>= TCSEC B), using page faults as a covert channel.

> it happens to run on the same soc as feature y that talk to the can bus

I wonder how many people will have to die to teach car manufacturers the lesson that there shouldn't be any electrical connection at all from the internet to the breaks.

Yep. The TCSEC had covert channel analysis as a requirement. Actually, two of the products (GEMSOS, STOP OS) certified at A1 can still be OEM licensed today in some form with a third (SNS Server) only sold to defense sector. They have plenty of competition, too, in MILS space. Solutions exist.

> But then feature x needed an ongoing net connection, and it happens to run on the same soc as feature y that talk to the can bus, and boom.

So then the question becomes: How are we going to educate engineers about this class of problems?

I think the first step is integrating secure design practices into curriculum. I was surprised to see how little emphasis was put in in both Traditional CS and Engineering courses at the universities I work with.

It's not the engineers, it's our managers.