LWN.net Weekly Edition for April 7, 2016

The Internet of bricks

One of the promises of the "Internet of things" is that it gives us greater control over our homes, gadgets, and more. Free software also offers that sort of promise, along with the idea that, if necessary, we can support our own gadgetry when the manufacturer moves on to some new shiny object. The currently unfolding story of the Revolv hub shows that, in many cases, these promises are empty. The devices we depend on and think we own can, in fact, be turned into useless bricks at the manufacturer's whim.

The Revolv "M1" home-automation hub was one of many products designed to bring home control to the Internet. It is able to control lights, heating, and more, all driven by smartphone-based applications. The product was sufficiently successful to catch the eye of the business-development folks at Nest, who acquired the company; Nest was acquired in turn by Google, and is now a separate company under the "Alphabet" umbrella.

The acquisition of Revolv seemed to be driven primarily as a shopping expedition for engineering talent. Revolv's engineers were quickly moved over to Nest products, with little of interest happening with their own product line. But, as can be seen on the cheery note on the revolv.com front page, the distraction of Revolv's engineers goes beyond neglect of their older products:

Purchasers of Revolv hubs, who might have been under the mistaken impression that they owned their devices, may be less than incredibly excited to learn that, in just over one month, they will be left with inactive electronic waste. They may have deployed these devices in distant homes that will be difficult to get to in time, or they may have just had the devices to play around with. Either way, it is understandable that they would feel like they have been unfairly dealt with.

One might be tempted to point out that abruptly shutting down programs and services is becoming a standard Google technique. The "MyTracks" Android app was once allegedly open source; Google has pulled the source off the net and pronounced that, as of April 30, it will simply cease to work. It is one thing to decide to stop providing a free network service; it's another to vandalize an app (or a device) that should be fully capable of running on its own. But, in any case, this problem goes beyond Google (or, more correctly, Alphabet).

Much of the Revolv system is built on free software; the company's (still available) open-source licenses page suggests that the whole thing is based on Ångström Linux. If Revolv customers actually owned their devices, they would be able to keep that base system running themselves, even if the (presumably) proprietary higher-level software was remotely disabled. But, on a locked-down system, the freedom that comes from using free software has been taken away. Customers are in possession of a box that runs Linux and has home-automation capabilities, but those capabilities are no longer available to them. Free software has not prevented the bricking of this device. Similarly, the release of MyTracks as free software has not kept it from being remotely disabled.

The real problem with both Revolv and MyTracks is arguably the network-service component. But neither should need that component to be able to perform most of its functions. The Revolv hub should be able to carry out its basic functions without recourse to any sort of Internet service at all; how else is it going to work if the network connection is down? About the only thing that might be at all challenging is remote control from an app that is not on the local network. On a free device, there would be a way to replace that service, but that is not the situation here.

The situation with MyTracks is similar; there is no need for a network service to collect location data. Displaying it uses the same mapping APIs many other apps use. There is no reason why it had to be remotely shut down. Truly free software would not support that sort of antifeature, but, when one runs proprietary software, that level of control is lost. The surprise, perhaps, was that MyTracks, as found in the "Google Play Store," was still a proprietary product, even if it was allegedly free software.

What can we learn from this experience? We didn't really need reminders that proprietary software can act against the interests of its users, but we have one here anyway. Maybe, someday, there will have been enough cases of bad behavior in proprietary software to create a market for consumer devices that are fully open, but that day does not appear to be coming soon. Until then, people with the necessary skills can often create their own systems, but that is not an option for the bulk of people who do not have the skills, the time, or the interest to do that.

Given that devices running proprietary software can so easily go dark (or turn actively malicious), it would seem that a great deal of caution toward "Internet of things" gadgetry is warranted. Toys are fun, but perhaps one's cookware or toothbrush do not need to be connected to the net at this time. For any such device, one should ponder what would happen if it abruptly ceased functioning, or all data that it is able to report were to end up in hostile hands. Do not assume that the presence of free software makes a device more free, trustworthy, or supportable.

It would not be surprising if Alphabet/Nest were to back down, temporarily at least, on the Revolv shutdown; this is the kind of thing that attracts class-action lawsuit lawyers in the US. But this action is a clear example of what it means to lack control over devices that you have purchased; when that control lies elsewhere, others will inevitably abuse it. We know what is needed to build a network full of devices that we can at least hope to trust — openness and freedom — but we have not yet succeeded in making that point outside of a narrow technical community. Unfortunately, it may take a number of high-profile incidents before the world understands.

Comments (51 posted)

Why Zephyr?

When the Zephyr project was announced in February, many members of the Linux community seemed to find it puzzling. Although Zephyr is hosted by the Linux Foundation, it is an entirely separate operating system that incorporates no Linux code. It also targets small hardware devices—from Arduinos to ARM system-on-chips (SoCs)—even though there are several other open-source OS projects (including Linux for many ARM SoCs) that also address that device class. At the 2016 Embedded Linux Conference in San Diego, the Zephyr team was on hand to make the case for why the new project is necessary and, hopefully, interesting to developers.

OSes of Things

Intel's Anas Nashif presented an overview of Zephyr in his talk, describing both its background within Intel and its capabilities. The bottom-line goal of the project is to provide an open-source, realtime operating system (RTOS) for "sub-Linux devices." Beyond that, however, Intel looked at the existing RTOS offerings on the market and found them lacking in several respects. First, many of them focus only on one architecture, which limits their appeal.

Second, many of them are "roll your own" projects developed for research or maintained by a single person. That seems to correlate with a lack of security work, which is a serious drawback. In addition, some of these smaller RTOS projects use peculiar software licenses, which also inhibits their adoption within the open-source community. Finally, many of the existing projects are too limited in functionality to serve as a general-purpose OS for Internet of Things (IoT) devices, which Intel sees as the primary use case for Zephyr.

Put all of those factors together, and one has the Zephyr product brief: an open-source RTOS that supports multiple architectures, has a broad contributor base, and offers "more than just a scheduler"—specifically, good networking support and a real security framework. Intel happened to acquire the rights to Wind River's microcontroller RTOS, decided it could be developed into a good fit, and set about to clean up the code and prepare it for release. That RTOS is now the open-source Zephyr, although it also serves as the core of Wind River's "Rocket" RTOS product. Intel is currently leading the development effort.

By building on the existing Wind River code base, Nashif said, Zephyr can start with a battle-tested code base used for more than a decade in real-world conditions. Expanding the original code involved several key steps. First, it was restructured to be more modular. At compile time, developers can include or exclude whichever subsystems they need in order to fit the hardware. The hardware in question includes what he called "the very lowest end of the sub-Linux device spectrum", "where the cost of the silicon is minimal." He showed a slide listing the initial hardware products on which Zephyr runs, which includes the Arduino 101 and Intel Quark D2000 at the low end, and goes all the way up to the second-generation Intel Galileo at the high end. But, he added, the Galileo is a development platform only; it is fully capable of running Linux, so he expected no one would use it for a real Zephyr deployment.

Second, the Zephyr team added networking. It wrote a Bluetooth Low Energy (BLE) implementation from scratch, and ported the IP stack from the open-source Contiki RTOS. IPv6 is supported, include the low-energy 6LoWPAN. The project is still looking at other network stacks; Near-Field Communication (NFC) is likely; ZigBee and WiFi are also possibilities if there is demand.

The third addition to the code base was a cryptographic library based on TinyCrypt. In a separate session, security developer Constanza Heath described TinyCrypt's set of random-number generation (RNG), cipher, and key-exchange primitives, as well as Zephyr's general approach to security. A Zephyr image runs only a single application, which is statically linked in at compile time. There is a single address space and no loadable kernel modules are supported, which reduces the attack surface considerably. In brief, she said, with a single, statically linked process running, if there is malicious code running on your Zephyr hardware, then it was there at compile time. The project thus skips some other security features that larger OSes include to protect against security exploits, though she said the team is still looking into adding some protections like address-space randomization. For most security features, the question at hand is the security-versus-size trade-off.

Features

When it comes to size, Zephyr can run comfortably in 8KB of RAM, and can even run in a minimum of 2KB of RAM, although Nashif said that at that size it provides nothing but a "Hello World" demo. The Zephyr kernel can be configured in either one of two modes. The smallest is "nanokernel" mode, which provides a basic multi-threaded execution environment, inter-thread synchronization services (including semaphores and mutexes), message queues, and interrupt services. Nanokernel mode is expected to be used for the smallest and cheapest devices, he said, such as environmental sensors, which need to do little processing beyond gathering and sending data.

A step up from nanokernel mode is microkernel mode, which offers a superset of nanokernel mode's features, including more sophisticated message queuing, additional memory allocation services, preemptive tasks, and round-robin time slicing. This mode is expected to be used on slightly larger IoT nodes, such as sensor hubs that may need to process and format data collected from sensors before forwarding it on to a remote server. Nashif pointed out that networking was available in both nanokernel and microkernel mode, although configuring a nanokernel build for the full IP networking stack could potentially make it hard to fit Zephyr into a sub-10KB RAM device.

Nashif noted Zephyr also makes use of some tooling from Linux. Configuration is done using the Linux kernel's kconfig, and Zephyr builds are done using kbuild. But the similarities stop with those tools, he said—a Zephyr image is configured and built for a single application. "We're just trying to learn from Linux, not to be Linux." The project offers a software development kit (SDK) that supports five compilers and provides tools for flashing images onto devices and for debugging. In addition to running on Linux, Windows, and Mac OS X, the SDK can run in Docker containers.

Intel sees Zephyr as a strategic investment, Nashif said. It saw gaps in the RTOS market, particularly where IoT devices are concerned, and took the opportunity to try building a project to fill the gap. It hopes to win over the community, and hopes to work with other open-source projects wherever possible. Nashif added that he knows the IoT space is a crowded one; he has seen two new IoT OSes announced since Zephyr was released, and does not expect that trend to slow down.

Whoever establishes dominance in the IoT market will have to overcome quite a bit of competition, both proprietary and open source. It is quite early in Zephyr's lifespan, even though the code base has a longer history through its days at Wind River. Wherever it goes from here, it will be interesting to watch.

[The author would like to thank the Linux Foundation for travel assistance to attend ELC 2016.]

Comments (28 posted)

Redox: a Rust-based microkernel

Creating a new operating system from scratch is a daunting task—witness the slow progress of GNU Hurd, for example. But it would be hard to argue that the existing systems are the be-all and end-all of how we interact with computer hardware. At least some of the deficiencies in today's offerings can arguably be traced to the language used to implement them; C, for all its power, has some fairly serious flaws that lead to bugs and security holes of various sorts. So it is interesting to see a new entrant that uses the Rust language, which is focused on memory safety. The result is Redox, which is still far from ready for everyday use, but may provide an interesting counterpoint to Linux, the BSDs, OS X, Windows, and others.

As laid out in the Redox book (which is also a work in progress), Rust was chosen for its memory and type safety. Some of those features were described in an LWN article back in 2013. The Redox developers see these safety features as a critical part of a modern operating system, even one that is based on the much-older Unix model:

So the goal is to eliminate whole classes of problems that plague C programs, but the focus on security doesn't stop there. Unlike Linux, Redox has a microkernel design, where much of the code that resides in a monolithic kernel like Linux is moved to user space. A microkernel simply provides resource management, interprocess communication (IPC), process/thread management and scheduling, system calls, and little else. The result is a much smaller kernel (16,000 lines of code for Redox and plans to reduce that further) with a concomitant reduction in the attack surface, as well as a much smaller amount of critical kernel code to audit.

In Redox, as in MINIX that it is partly patterned after, drivers live in user space so they can do far less damage when they fail. In monolithic kernels, a bad driver can crash the whole system because it runs in the kernel's address space and with its privilege level. So, for Redox, filesystems, device drivers, networking, and so on are all implemented in user space.

Beyond that, Redox has taken the Unix "everything is a file" philosophy (which was further expanded by Plan 9) and taken it a step further. In Redox, everything is a URL (or, really, a URI), which means that the API is based on using URLs to access local and remote resources: files, networking protocols and sites, devices, and so forth.

The "scheme" portion of a URI (e.g. the "http:" in a web URL) is used to identify the type of the resource being accessed. These are implemented as Redox schemes, which can be implemented in user space or the kernel, though user space is preferred. Schemes are effectively virtual filesystems with a set of operations made available that are appropriate to the type. As the book notes: "'Everything is a scheme, identified by an URL' is more accurate, but not very catchy."

The Redox wiki goes into a bit more detail of how URLs and schemes are used. For example, tcp://10.11.12.13:80 would be used for a remote TCP connection, while file:/apps/terminal/example.txt refers to a local file. In the networking wiki page, there is mention of using a URL like tcp:///80 for a web server or ethernet://12:34:56:78:9A:BC/800 to receive or send IPv4 (type 800) packets for the specified MAC address.

Underneath the schemes are resources, which come in two flavors: file-like (i.e. blocking and buffered) and socket-like (i.e. non-blocking and stream-like). Resources are closely related to schemes, as the book notes:

While the kernel is the main focus of the project currently, there are some side projects of interest as well. To start with, ZFS is planned as the filesystem of choice for Redox, which means writing a compatible implementation in Rust or adapting the existing open-source version (OpenZFS). There is a minimal graphics server, orbital, that is based on the Wayland protocol. There is also a vi-like editor (Sodium), games, and more.

The code is available on GitHub and has been released under the MIT license. The explanation for choosing the MIT license has been somewhat controversial among some GPL advocates, but the developers clearly want Redox to spread far and wide—proprietary forks and extensions are explicitly condoned. ISO images for various targets are available, though they are yet another work in progress. The book also has some instructions (starting here) for those who want to build Redox for themselves.

A Discourse forum is provided to discuss Redox and its development. There are contribution guidelines and ideas, a best practices page, and the inevitable issues list as well. Those interested can keep up with the project by checking out the "This Week in Redox" newsletters, though they are rather more sporadic than the name would imply. The Code of Conduct is fairly extensive and clearly shows an intent to foster an inclusive community. In short, there is quite a bit of information available about Redox, though it is somewhat scattered.

One question that many will ask is "why a new operating system?" The Redox developers have an answer that boils down to dissatisfaction with Linux, the BSDs, and, even, MINIX (which is "the most in line with Redox's philosophy"). There is an admitted "Not Invented Here" sentiment within the project. But one thing that is explicitly not a goal for the project is replacing Linux. A one-word answer ("No") to the "will Redox replace Linux?" question is contained in the book.

That's probably a good thing for a number of reasons. For one thing, hardware support is a huge task that is unlikely to be surmounted without an enormous effort from lots of companies—something that the MIT license might make difficult. Like it or not, the reciprocal nature of the GPL certainly seems to be a driving force for the corporate involvement in Linux. It is also an area where more permissively licensed alternatives (the BSDs and MINIX) have run aground to some extent.

But there are other hurdles as well. Redox has deliberately chosen to implement a minimal subset of the Linux (and POSIX) system calls. That will make it more difficult to port existing applications to Redox. That is partly by design, however, as a Rust-based user-space ecosystem is envisioned, but the huge number of existing freely licensed applications, which may be difficult to port, could be a big impediment to Redox adoption. Longstanding issues with the performance of microkernels (which require many more context switches than monolithic kernels do) may also make Redox a hard sell for the more lucrative server segment—though performance for desktops may turn out to be reasonable, especially if the security gains are substantial.

It is clearly an ambitious project—perhaps even overly ambitious; only time will tell. It does bear watching, though, as an experiment in several dimensions. The microkernel design and Rust-based implementation will provide answers (or at least evidence in one direction or another) to some questions that have been floating around for some time. We clearly don't have all the operating system answers for the future, so more data is called for. Redox might just provide some of that data.

Comments (6 posted)