My 2 cents about that is we run that same risk on everything today. Compilers change all time, libs do not get updated, and go by,by, or do not get updated to keep up with the compiler revs. Companies come and go. It’s the risk we all take, and the reason we have to stay vigilant in order to keep on top of things. For myself, the one thing that has always impressed me about embedded Linux was the fact that I am less dependent on a one board manufacture. A few years ago i started dabbling in embedded Linux, granted never put both feet and the water and learned it whole heartedly. But years ago I wrote a C program to test the CPU using threading (-pthread). There were 6 threads running independently. Each thread just did a bunch of math over and over again, and the 6’th task printed to the console how fast each task was running. I have bought over 25 Linux dev kits over these years. Some sucked and some ok. But the one this was consistent was regardless of what board, or flavor of Linux they were running, or updates it had my program ran the same on them all with absolutely zero changes to the code what so ever. The only thing that did change was the speed in which it ran.
I look at this as awesome. Because no where else are you going to be able to do that. If you made your system using a board that had an Atmel processor on it (like Teensy), and one day they go by-by and now you want to switch to a ST platform, there is no way your not going to have to change your code, learn the new compiler, buy new tools and so on.
Embedded Linux is what gives you the freedom to end this curse.
I have to agree. Linux systems may come and go, but properly written Linux code is extraordinarily portable between Linux platforms and distros. You have real defense against obsolescence and bit rot and a huge, mature and diverse ecosystem of vendors, platforms and communities.
On top of that, you have full .net through mono; the ability to code C/C++ in VS with VS for Linux; easy driver extensibility through device trees; and rich OS support for things like scheduled task and containerization for IFU.
Yes, but the flip side to that curse is well “Hackers Remotely Kill a Jeep on the Highway—With Me in It | WIRED”
With the IoT of things, if its a wash machine, who cares, but if it involves any thing of significance, sometimes its worth the pain to develop something non-standard… Makes a person wonder why there is such a reluctance to move away from Fortran on banking servers…
Any wireless device standard or non-standard that does anything of significance or not is hackable. It’s up to the hardware and software developers to go the extra mile and add as much penetration protection as they can. Unfortunately, in this fast paced world we live in where the norm is “make the money as fast as possible” most companies don’t invest the time to add those extra layers to keep things safe.
Not picking on anyone here, but let me give you a view.
I’m a Linux noob, happy to admit it, and as you all know I work for Microsoft (in enterprise support, nothing to do with this field). I have a couple of devices that are perfect candidates for a Linux build - RPi and RPi2 to name just two. I choose to install a variant (doesn’t matter what one, does it?) I don’t know enough to do anything intelligent besides setting up the device from a blog/website that I find online. Can I be comfortable that in that out of box state I’m “secure”? Admittedly things on my network are pretty well known to me and the Pi’s are not likely to venture outside my network, but what about when my father-in-law comes over with his malware-encrusted PC and connects to the wifi, am I a target then by not having known enough about protecting myself? When I compare that to a Windows device that I can trust to get itself to a known update state, and in a good initial security stance, without thinking about it, I worry about going and buying that next embedded Linux device and connecting it to the network - and I have to hope my TV manufacturer did a good enough job of reducing the attack surface, as that’s probably the next thing I’ll knowingly buy that has something like this.
The real scary thing is that there’s lots of people out there who don’t know they have these devices in their home, and as you rightly point out the vendors are mainly about turning a profit on this year’s model TV, not in heavily investing in defenses. OK maybe TVs aren’t a good example to use since many of those manufacturers intend to be around for a while so are more likely to do the right thing, but the network cameras or the nanny-cam or the PVR or the sprinkler controller, are going to be less worried about their potential for damage.
But back to my scenario for a bit - how do I know? I’m sure a smart person could address some of that - but not me. That means I have some dust collectors (ok again, probably not the only reason they’re collecting dust but I choose to use that one at the moment )
I am far from being a Linux expert. I hear ya on your points, some of them I am in the same boat with. But I will say that I would be far more trustworthy on slapping a RPIx or the like on my network than any windows PC. If anyone ever looked at all the ports open, and data being sent back and forth on so many ports on a windows PC will make your head spin. Even on a brand new install. Yet on the flip side you do the same on a RPI, and last time i looked there was only 1, and you know what they are for where MS are cryptic and you have no idea. In Linux you can even turn them off with no impact at all on the system. You cannot do that on a windows PC.
Now I am not picking on Windows at all, in fact I love win10.
As far as embedded devices go, I will admit I am starting to get a bit more and more paranoid of all the things I am putting in my home that is on the network.
But there is something to be said that the majority of servers out in the world run Linux.
Saying that a lack of os diversity causes security weakness is an appeal to ‘security through obscurity’. Security on any platform comes from good security in depth. Not from obscurity of your platform. A lack of diversity can aid propogation, but it isn’t a defense against the initial penetration.
@ mcalsyn - Security thru obscurity isn’t what I meant by that… Yes, I understand that even still I need security, (still waiting on SSL for NETMF, as using SSL tunnels is only a interm patch), but what I was trying to get at, is if the functionality doesn’t exist to be exploited, it can’t be. This is similar to connecting a Ethernet port to a G400, with no TCP/IP code, and saying that it could be hacked. I still don’t think there is something that isn’t hackable, but being in control of what is happening is a lot easier when you have designed it, vs using an out of the box solution.
)