Learn how to design and defend an embedded Linux device
embeddedbits.org
embeddedbits.org
But I think there are use-cases where this is legitimate, for example, ticket readers mounted on public transport where anyone could tamper with them out-of-hours, or a utility meter installed in my house where I might want to change the way it records consumption to get out of paying. Likewise, a payment terminal taking card payments in a restaurant - as a diner I'd quite like some assurance that someone couldn't tamper with it to record card details for example.
It's the device manufacturer.
Everyone is already dependent on some level of integrity by the device manufacturer, whether they're happy with this or not, because there is no other option.
That integrity might be checked. The manufacturer may be audited. Their processes and people may be background checked. Their hiring practices subject to a standard. Some of their devices may be selected at random, scrutinised, picked apart, checked by third parties, just to be sure. It's not done much, but perhaps it should be. Anyway, if that's done there is some higher level of justification in trusting the manufacturer's integrity, even if it remains a weak point.
If we already have to trust the device manufacturer and/or their auditors, that makes them owning the software trust root a very different proposition compared with anyone else owning it.
It might also be broken and they don't care for you and you're screwed.
Also, as was shown many a time, the manufacturer will prevent you from doing whatever you please with your own hardware, if you chose to do so. In that case, their integrity is broken by design.
That hardware is not "your own". It is deployed to facilitate and protect a transaction between you and someone else.
The certainly exists a possibility that the manufacturer of those devices doesn't care about protecting them, with the result that you the user get over-charged, have your card details stolen etc.
But it's hard to see how making it easy for "anyone" to modify the software on those kinds of devices in an unconstrained way doesn't pose strictly greater risks of the above kind to you the user (being over-charged etc).
Surely you would rather have to trust just a few entities in control of the device, who have some kind of quality control legal obligation through the usual network of contracts and liabilities, than trust the 100s of entities that have had some contact at some point with the device, any of whom could have modified the software on it?
Any ideas on how to solve this problem which don't involve trusted roots?
It'd be great if one could build on zero knowledge proofs with something like monero that could let you verify the firmware of a device. Or rather, your phone/credit card queries the device with a ZKP (or something), then uses a public blockchain to verify the devices firmware signature chain. A user could possibly then use a "adblock" like software to warn of manufacturers that have been breached, etc.
The owner of the ticket reader is the public transport authority.
>a utility meter installed in my house where I might want to change the way it records consumption to get out of paying
The owner of the utility meter is typically the company providing the utility.
In both of these cases, I would expect the owner of the device to have full control over it and not, say, only the manufacturer. If my city's government installs ticket readers in every subway station and is then perpetually beholden to a single private company to upgrade/maintain/improve them, that feels like a problem.
Note that this doesn't have to mean that someone with temporary access to the device should have full control over it! There's still a place for secure boot-style systems; it's all about who controls the keys.
>a payment terminal taking card payments in a restaurant - as a diner I'd quite like some assurance that someone couldn't tamper with it to record card details for example
This one is maybe a bit more concerning since it's a card issued by a separate authority, you don't have the ability to confirm transaction amounts on a device you trust, etc... but sure, in this case, I'd be fine with the hardware vendor or payment processor controlling the hardware.
(Though long-term I think this is a bit silly in the first place considering approximately everyone is walking around with computers in their pockets that would be perfectly capable of letting you confirm transaction amounts on a display you trust. Card payments currently are effectively handing someone your account details and saying "pretty please only take as much as you say you will.")
This is how China's new-generation payment systems work.
Furthermore, in this context, systems are often sold and setup by a third party company. End users value more the fact that they can be sure that the software run by the device has not been tampered with, than the possibility of changing the software.
Even for desktop PCs in companies, it is not uncommon that a rather rigid management policy is enforced, so in a way in this case PCs are just general-purpose and locked down embedded systems.
Certain safes irreparably break after several attempts to incorrectly or violently unlock them. Nobody — neither a thief, nor a legitimate owner, nor the manufacturer can open them. The only option to reclaim the contents is to very slowly and with a great effort to cut them using serious industrial machines.
This is a feature that customers ask for. They want to be sure that snatching their safe in an attempt to quietly brute-force the lock or the door in a garage does not make sense. It prevents such attempts, and they agree to pay for that with the risk to turn their safe into a piece of scrap if they screw up badly.
Same applies to locking bootloaders, firmware, etc. Sometimes it's better to throw away a device than to allow a risk of tampering.
Of course, the owner should voluntarily and consciously make this decision. In the case of DRM-ridden media players, or even phones, the consumer may have different preferences but not given a choice and even not made aware, which, of course, is not great.
The analogy fails if there's no way of "cutting open" a gadget/cellphone/PC to regain control of it. The bank is perfectly capable of recovering the contents of the safe, even after a destructive failsafe, they just pay someone and wait a day.
The problem is that it essentially requires an extra FPGA and few other components that provide the necessary secure key storage and attestation.
IMHO, tiviozation of devices should be banned by law. Currently, GPL3 forbids it only, so, please, use GPL3 for your new open source project.
I'm not keen on the idea of a million/billion/billion+ dollar company taking code I've written for my own enjoyment and using it to disproportionately enrich the company's shareholders or abuse its customers by denying them control over their devices.
Code that can be used in closed devices shouldn't be available for the manufacturers of closed devices to use.
That's exactly what tivoization is, so the GPLv3 already prevents that.
For something like a thrust vectoring rocket, I'd stick to a sub processor running an actual RTOS or bare metal code.
It's also common to run your code as init and avoid calling into the kernel.
A more modern treatment is to write whatever and then qualify the system thoroughly, and all things considered this will probably overtake everything else as the main development methodology.
Generally speaking, your limiting factor wrt. hard RT performance is going to be the underlying hardware, not the OS per se. This of course assumes that you avoid known sources of OS-related latency.
Go look at the Beaglebone Black/Green/Blue/AI.
The microprocessors in those run Linux but have at least two PRUs (programmable real-time unit). Those PRU units are bare-metal, hard real-time but can communicate out to the Linux system which can do the "soft" real time stuff.