Ask HN: Why is BSD becoming more popular in embedded devices?
I have noticed a steady rise in embedded systems using BSD based operating systems and i was just wondering why its being chosen over linux for example. Both Sony and Nintendo are using BSD based guts in their consoles and im also seeing it used fairly regularly in EPOS systems and a fair few other things.
65 comments
[ 4.4 ms ] story [ 172 ms ] threadThere 4 main families of BSD, each with a different focus. All are highly secure and some are portable across most CPUs. The Wikipedia articles provide a lot of good information.
I would choose BSD over Linux because it is more compact, far more secure and easier to implement drivers. The tools and utilities for both Linux and BSD are GNU - so only the kernel is different.
There's a fairly substantial BSD userland. E.g. BSD make vs GNU make.
But it's still based on BSD, which is a descendent of the original AT&T Unix.
[0] https://arstechnica.com/apple/2007/08/mac-os-x-leopard-recei...
Linux's NIH syndrome, however unfortunate it is, has not expanded into its unix roots. (yet?)
I've recently taken to calling it 'GNU plus Windows'.
Absolutely not. Linux is just a kernel whereas the BSDs represent entire operating systems, and different ones at that.
Not really, those systems get much less attention from sec folk than the Linux kernel (apps aside). Finding a priv escalation in the Linux kernel takes time (most of low hanging fruits have been already found by fuzzing or by code review), while finding it in *BSD kernels requires writing a simple syscall fuzzer and running it for a couple of minutes. I've seen it done live.
[1]: https://www.openssh.com/security.html
https://wiki.freebsd.org/GPLinBase
* tar exists 1979 so neither GNU nor FreeBSD had the first implementation. * pdtar, from 1987 was public domain code and actually the GNU people based of this public domain code and put their implementation under the GPL * The current FreeBSD tar implementation is from 2005
All the BSDs have their own libc, so that is a big difference. There's more to a complete system than kernel and build tools.
But as far as tools, FreeBSD is nearing completion of removal of GPL licensed software from the base system, see:
https://wiki.freebsd.org/GPLinBase
Most things use clang now, and even in ports, only a relatively small number of things which require gcc still use it. Also lld, the llvm linker, is making great progress towards replacing gnu ld.
And OpenBSD has imported LLVM, see:
https://marc.info/?l=openbsd-cvs&m=147294297501630&w=2
I can imagine that makes it a sensible choice for companies that build their own hardware (custom peripherals and so forth).
Also, as others have pointed out, the BSD License. Some companies won't touch GPL code with a ten-foot stick.
I am not talking about dev boards, I am talking about Chinese OEMs that do not give a crap about open-source.
> give nothing back
Exactly, that's the allure of BSD/MIT for these sorts of companies.
As far as I can discern, they literally do not give a crap and do the bare minimum to get a half working Linux BSP so they can run an ancient version of Android. Then it gets used for your security camera, and that is why you have 20 shitty IP cams running kernel 2.6 calling home to Hunan Province.
That BSP will rarely be released to the public, much less mainlined, and it is sure to be mixing proprietary code with GPL'ed code. *BSD doesn't even factor into the equation, since GPL compliance doesn't matter to Allwinner or Rockchip.
BSD systems have always suffered a lack of device drivers.
But if you are a huge enough company, you can do two things:
1. Choose already-supported hardware to develop on 2. Customize the OS to fit your needs
Using a BSD-licensed system feature no. 2 becomes particularly nice, as you don't have to share your changes back and you can keep your work for yourself (for both IP and security-through-obscurity).
Outside of that, its all Windows for the smaller chains, Truno and similar will not talk to them, so they get to deal with NCR who sells them a meh system based on whatever the last supported version of Windows is. Even smaller and you get into PCAmerica (Windows) or Clover (Android/Linux).
On the embedded front ($X to $XX) BSD supports fewer platforms than Windows for IoT, you can't even boot it on your average ARM board or MIPS router. Only in high end consoles ($XXX) has Sony & Nintendo chosen to use BSD, which requires a substantial amount of work, but there is significant perceived value by making locked down "consoles" that can only run their signed software.
OpenBSD currently supports:
NetBSD has "Tier I" support for... ...and "Tier II" support for nearly 50 others.even when the devices are not in violation, it costs money to litigate.
In my case (about 20 years ago) the documentation was what made me use BSD instead of Linux.
Back in 1996 there was little (reliable) documentation about Linux kernel internals and boot process. For BSD (OpenBSD) it was the opposite: well documented and reliable.
- The state of the art of Ops and information in internet makes that today anyone with some curiosity can understand and start modifying/administrating tools and systems which decades ago was only possible for specialists in the area. - Truly cross compatible source code and runtimes are widely available (not just C code that has to be compiled in the target architecture like in the old times.) - With the raise of open information now technical choices can be made contrasting the experience from other teams or companies which made similar choices in the past.
In the mid 2000s, I developed an embedded system for my employer based on Debian, cut right down and with our software started directly from inittab, set to respawn (we could have replaced init entirely with a bit more work). With stuff like systemd in the mainstream, Linux userspace is increasingly opinionated and desktop-centric. It takes time and effort to strip out stuff you don't want, particularly when it's increasingly enforced and you have to do custom builds. In comparison the BSDs are easy to build with customisations, including the ports I might need. While I no longer do embedded stuff, I do wonder what it's like with the current state of Linux.
Video game makers generally doesn't make much money with hardware, they make money selling software (a.k.a. games), thanks to licensing. To allow only licensed software to run in a modern video console, all software running on it is signed with a key that only the console maker have. However, if someone discovers a way to run unlicensed (unsigned) software in their hardware, this means that the console maker will lose money to piracy.
Generally, using BSD systems in video consoles is desired since you can simply close the source code (thanks to the BSD license) and not reveal possibly potencial kernel exploits. Kernel exploits are the key for console security since once you get a exploit running in kernel, you can leak encryption keys or simply bypass the signature checking. Kernel exploits is what allowed piracy in most last generation consoles (Nintendo 3DS, Nintendo Wii U, PS Vita, PS3). Using Linux, thanks to GPL license, would mean opening the source code of the kernel, allowing someone to study for exploits.
Actually, even if PS Vita/PS4 uses BSDs as a base, they use a heavily modified BSD, since using a vanilla kernel would make a public exploit in say, FreeBSD, easily ported to their device.
Nintendo consoles actually uses an in-house developed kernel by Nintendo, that debutted on Nintendo 3DS; the Nintendo Switch's BSD part is mostly network, however BSD network is used even on Windows because it is of high quality and portable (and BSD licensed).
Disclaimer: I am not a console expert or anything, I mostly follow the console scene so those information can be wrong.
You mean like at the recent CCC where they demonstrated using a WebKit exploit to trigger a BSD exploit via which they install a working Linux system on a PS4 and launch Steam? Link: https://www.youtube.com/watch?v=QMiubC6LdTA
It's not as simple as that because the PS4 is a custom board, so even though the CPU and GPU are standard AMD components, some hacking was required. But using exploits that have long been patched to gain access to hardware by Sony and Nintendo is nothing new.
Another observation: if PS4 used Linux, Sony would be forced to open the modified PS4's Linux kernel thanks to GPL License, and would be trivial to check for security exploits since you have the source code.
I posit a definition of "bloated" as needing more than that.
Nintendo has a habit of doing their own custom OS designed specifically for the needs of their consoles (3ds, switch and wiiu all have its own OS), but using a battle-tested and proven network stack means less problems in the long run.
Coincidence?
I think the community and quality of documentation as well as not being controlled by single entities are a big part.
It's not just the license. There are quite a few ways to get around using Linux in many use cases without caring about its license. And there is Toybox.
Perhaps it is more visible now, but BSD embedded systems have been very widely deployed for quite some time.
http://www.apnapedia.com/computer-input-devices/