Why does it need continuous, perpetual support? Most devices like this get built, software installed, and never updated again. When is the last time you updated the ECU software in your car? I built a small arcade cabinet using an old raspberry pi 2b. Once I built it I've never needed to upgrade anything on it. It works fine and plays all the old games. I have backups of the SD card in case anything craps out.
Few years ago, you built your arcade cabinet, and decided to put some nice launcher like RetroPie. It works fine for a few years, and then your friends tell you about Pico8 support.. nice, it is supported by RetroPie release! not nice: retropie requires ubuntu 18.04 or later.. let's hope your device supports it.
Few years ago, you built a weather station. Sadly, the weather backend you had was discontinued. You found a great new one, and it even comes with SDK and sample code! Sadly, the SDK requires python 3.8 or later. Does your device support it?
Few years ago, you built the home automation server. But recently, you got the set of remotely-controllable disco balls for each room which use FOOBAR protocol. Good news: Linux kernel supports FOOBAR protocol since 5.14. Bad news: your device kernel is much older.
Few years ago, you built the smart controller. You don't want to manage your infra, so you decided to go with AWS IOT, it is super each if you only have a few devices. But AWS announced they are dropping AWS IOT.. does your OS support newer system?
There are definitely cases when you set up the device once and never have to touch it again, but there are also a lot of networked things out there, and you often want to control them..
If there's a vulnerability in any of the software or firmware that connects and interfaces with anything over a network, there's the possibility of something worming it's way in or out of it.
For something intermittently used like a game box that might not matter. For IoT-focused hardware that is connected to the internet continuously by design where, say, a malformed TCP packet could cause a buffer overflow in the network stack that wiggles it's way into root code execution by chaining through a bunch of unpatched vulnerabilities on a "never updated again" system? That's a problem.
No matter how elegant you seem to be, you'll always be running like half a dozen versions in the wild.
For any large deployment that kind of work will be on your shoulders anyways. Stuffing in security updates or whatever to that isn't crazy
Unless you're saying you want multichannel overlapping upgrade schedules where you have some NxM cadence matrix to test and support (as in ssh x+/-{1,2,3} AND your software x+/-{1,2,3} etc).
I've had to make and manage automated test rigs for those types of deployment as well.
That's an entire room full of whatever machines your deploying and a full time job.
Anyways, this stuff is hard for the out in the wild devices. Putting security updates in a monolithic release package is really the easier way to go and at that point it's on you.
In most cases, yes, in all cases, no. There's a lot of variants of "enumerate all devices on a private network if you visit a malicious webpage" exploits.
Connections are only part of the danger. Browsers need to access the internet and they can have security bugs. Also, people download files and the programs that process them have bugs. People download programs and those can be dangerous.
For the kernel, it is important that it protect against dangerous programs running on the system to keep them isolated.
Because as an industry, we are bad at our jobs. The network facing software has critical security vulnerabilities. Even security folks accept that as the way of the world.
At the point the software is released it has (hopefully) no known security vulnerabilities, which is a reasonably secure situation to be in.
However, eventually some of them will become known, and that is not safe.
There are plenty of reasons not to want your IOT bulb to be insecure that are unrelated to people mining crypto.
A pwned IOT lightbulb can be used to help DDOS sites. It can relay DDOS traffic, eating your own bandwidth. It can be constantly probing the other devices on your network looking for vulnerabilities, until it pwns something else and is able to slurp down your passwords and credit card numbers.
Are you seriously suggesting that having an actively malicious computing device inside your home network is no big deal?
If it has a camera, it can be used to steal your security keys if it can see the power LED on your device (or potentially even just if something connected to your device has a power LED).
But a "critical security vulnerability " depends on the use. My daily driver? Yes, I want all of the security updates. A raspberry pi for playing arcade games that I occasionally scp a ROM over to? I really don't care if someone hacks in.
We, as an industry, are bad about pushing "every device that is on the internet needs to be as up to date as possible all the time" when it reality there is a lot of unimportant stuff on the internet.
It's like locks. I wouldn't secure my house with a bike lock, but it's fine for my bike. My bike is less full of important stuff.
At best, that means you're externalizing the costs, i.e. now your device is part of a botnet and becomes a problem for other people. But of course that assumes that it doesn't become a problem for you as well; a compromised device on your network is a great launching point for local attacks and a way to send illegal traffic out through your internet connection.
Ah yeah, I need to stop working at random notice, because some CVE bros have to immediately update all my things to hedge the risk of organized crime targeting my $0 value data like I'm that casino.
Meanwhile in reality, no one gives a f about the rPi you use for your Guinea pig feeder.
The "security" industry is unfortunately full of corpo-authoritarians. Once they realised a lot of the population can be forced to do anything if they can be convinced it's for "security", they've been doubling down on that.
Well, a common thing with open computing resources these days is cryptominers. Sure, you don't care about updates, until someone puts a miner on it and you have to go in and try to fix it. It wouldn't matter that your single device doesn't have enough processing power when there are tens of thousands of similarly vulnerable devices to hijack.
Because that is the nature of these SBCs. They aren't some generic queryable platform running UEFI. Instead you have a bespoke OS fork for each individual board. This means that vendors need to give a lot of attention to the software because there isn't a foundation or company taking care of all SBCs at once. The device becomes obsolete very quickly if you can't install recent software. SBC performance hasn't increased much. There are still plenty of boards with A53 cores that have been used for more than a decade.
First, this advertises this as a PC which have longer lifetime and higher security requirements than embedded.
Second, embedded systems have reliability requirements. Something will not work and will need support and updating to fix. The big advantage of normal distribution is that somebody has probably already fixed it.
Third, devices get repurposed. My five year old Raspberry Pi has had multiple jobs, and when it is done running Home Assistant, I'll find some other use. Plus, with normal distribution, I can easily install the packages I need.
All software have many dependencies (IMO for very wrong reason), if you can find a way to build a static system where nothing need to be updated good for you, but I doubt that this is the majority of use-case.
Will this device be able to load any web page in one or two decades? It would likely be slow, but the impossibility would be a pure software limitation.
