This is the summer of Docker’s ripening as it begins to mature into stable, enterprise-worthy software. The release of version 1.0 coincided with the first annual DockerCon, and finally moves Docker from an experimental state into a production-capable application. The pace of development is not slowing down after these successes, but rather appears to be ramping up as Docker adoption continues to grow and more companies get involved in the development process. The last few months have seen a major acquisition, improvements to security, and a 
multitude of bug fixes and new features.
One of the biggest moves taken by the company in recent months is the acquisition of Orchard: a company that provides hosting services for Docker containers. This is part of the company’s efforts to standardize Docker orchestration, something that has been handled differently by each distribution of Linux. The team coming from Orchard will spend part of their time developing an interface to make Docker orchestration easier.
This follows in the wake of Solomon Hykes’ announcement of Libswarm during his keynote at Dockercon. Libswarm is an orchestration application built to deploy applications made from multiple containers on infrastructures made of multiple machines by offering an API which can be accessed by any existing clustered system that includes a Libswarm back end.
Orchard also produces Fig, an open source application that allows users to build isolated development environments using Docker. The Orchard team will maintain Fig and launch a Developer Experience group aimed at making Docker a better tool for developers. This effort will include improvements to Mac and Windows support, the creation of more educational materials, and aiding with the development of Docker.
A major point of confusion with Docker and Linux containers is that “containers do not contain
On Aug. 18 at the Xen Project Developer Summit, the Xen Project unveiled an Embedded and Automotive initiative for its datacenter-focused Xen virtualization technology. The immediate goal is to help auto manufacturers “adopt open source virtualization” to “quickly and cost-effectively develop a flexible, robust, and customizable integrated cockpit — one that keeps drivers safe, while meeting consumers’ connected car expectations,” according to the Xen Project, a Linux Foundation Collaborative Project.
The first project in the initiative is a collaboration with GlobalLogic on the latter’s Nautilus [PDF] in-vehicle infotainment (IVI) and telematics platform. Nautilus uses a modified, embedded version of the open source Xen Project type 1 hypervisor to enable sandboxed implementations of multiple OSes. (See farther below for an interview with representatives from both Xen Project and GlobalLogic.)
The Nautilus stack uses its own fast-booting version of Android for IVI along with a separate container for telematics and other back-end services running Linux or QNX. Nautilus is initially designed to run on a Texas Instruments Jacinto 6, a multicore, ARM-based system-on-chip designed for automotive computers that combines two Cortex-A15 cores, with four Cortex-M4 cores, and a pair of SGX544 GPUs. Mentor Graphics is also looking at doing automotive virtualization using the Jacinto SoC to combine its GENIVI compliant Linux distribution and its Nucleus RTOS.
The Xen Project initiative is associated with the Linux Foundation’s Automotive Grade Linux (AGL) project, which is currently defining an IVI stack based on Tizen. GlobalLogic is working to add the Xen-based technology to the AGL spec, and will soon add Tizen Linux to its list of supported OSes. The Android implementation is forming the basis for an Automotive Grade Android (AGA) offshoot of the AGL spec.
The Xen Project Embedded and Automotive initiative is being led by Artem Mygaiev, associate vice president of development at GlobalLogic. The project is also associated with the GENIVI project, which recently designated Tizen as being compliant with the GENIVI 5.0 open source automotive spec. Despite the focus on Android, the project is currently not collaborating with Google on its Android Auto project.
In addition to tackling the automotive problem, the subproject plans to extend the technology to other embedded applications where multiple OSes must run side by side on multicore processors in secure virtual machines (VMs) without risk of cross-contamination. For example, a hypervisor can be used in mobile devices where both personal and professional applications need to be available on the same device, without the threat of corporate data being compromised. Other examples include avionics and drones, as well as smart TVs with parental controls.
The Embedded and Automotive initiative will also draw on previous code contributions from ARM, Citrix, DornerWorks, Galois, and Washington University. In addition to submitting its Nautilus implementation, GlobalLogic plans to contribute automotive-focused driver support for QNX and Android OSes, as well as several Linux kernel drivers for paravirtualization. It will also share technology that enables the virtualization of various GPUs, USB, and audio devices in an IVI system “without compromising performance,” according to the project.
Much of the Nautilus/AGA project is focused on turning Android into an IVI-ready platform that overcomes deficiencies in reliability, security, and boot-time. The Xen-based containerization addresses the security side, while GlobalLogic’s AGA stack has made great strides in improving boot-time. So far a version of Android 4.2 has reduced boot time to about 5-6 seconds, and reduced the time to display a rear-view camera image in 1.5 seconds, says the company.
The AGA spec also supports Bluetooth, Miracast, MirrorLink, and wireless hotspot technologies. Users can access vehicle data via the cloud, as well as control automotive features from a mobile device, or cast data from such a device to the vehicle display.
The upstream contributions should enable enhancements to the next two Xen Project releases. These include improvements to the Xen Project Hypervisor on ARM, real-time scheduling enhancements, as well as improved security, boot time, stability, and reliability. The new technology was made possible by last year’s completion of the Xen port to ARM in the 10th year of the project’s existence.
Over the last two years, several other developments were said to have set the groundwork for the initiative, including:
Prior to the announcement, I interviewed Lars Kurth, Xen Project Advisory Board chairman, as well as Alex Agizim, vice president and chief technology officer of embedded systems at GlobalLogic. Below is an edited version of that interview.
Q: It seems we’ve been talking about putting hypervisors in cars for years now. Is the delay due to the longer product cycles in the automotive business?
Agizim: Long production cycles are definitely the reason, but there are still a number of technological challenges such as performance and peripheral sharing. Only the recent SoCs like the TI J6 and Renesas R-Car M2/H2, have hardware support for virtualization. This will minimize the performance impact and provide maximum security and stability for the software running in different VMs.
Kurth: Software capabilities need to be hardened also. For example, we had a number of real-time schedulers for Xen which were initially designed for non-automotive use-cases on x86, such as ARINC653 and rt-xen, which are currently being optimized for ARM and automotive use-cases. Other areas where we made lots of progress is drivers for rich I/O as well as making it easier to create Xen PV base ports for operating systems. We could accelerate this technology if the hardware was more generally available for open source developers. Until this is fixed, it will be hard to create a diverse community that goes beyond a few vendors.
Q: Why is Xen better suited for automotive virtualization compared to other hypervisors?
Kurth: Xen Project is open source, it has ARM support, and it offers driver disaggregation and a flexible virtualization mode and architecture. The ARM implementation is only 90,000 lines of code, making it a perfect fit for embedded. We also have a multi-layered approach to security, including Driver Domains, Stub Domains, and Xen Security Modules, which can be thought of as a SELinux for virtual machines.
Q: How much of the Xen virtualization technology is easily transportable from the datacenter to automotive and embedded devices?
Kurth: Several Xen Project features are well-suited to both realms, such as security and isolation, stability and reliability, and rapid boot time. What is missing is optimization for the new ARM chipsets. We’re also starting to make use of TrustZone in the software stack. New challenges include power management and certification.
Q: Has the automotive initiative developed any innovations that could improve Xen in general?
Kurth: Some of the technology will be beneficial for the datacenter in the long run. For example real-time scheduling and virtualization is extremely interesting for NFV [network functions virtualization]. Graphics virtualization is becoming more interesting in the datacenter, too.
Q: The main focus of Nautilus appears to be Android combined with QNX under Xen virtualization. What role does embedded Linux play here? Linux is typically used on the IVI side of the equation, but your current implementation shows Linux as an alternative to QNX running on the backend.
Agizim: Linux is not a real-time system. Linux definitely can fit the place of Instrumental Cluster, but real telematics or ADAS should be driven by a real-time OS like QNX. Still, GlobalLogic aims to provide maximum flexibility, allowing IVI OEMs to pick the right OS for them.
More information
Vendors and developers interested in collaborating on the Xen Project Embedded and Automotive initiative, including non-automotive applications, are encouraged to join at the subproject website. GlobalLogic and the Linux Foundation will present a free webinarat 9 a.m. PDT, Wednesday, Aug. 27, on “Virtualization in the Automotive Industry.” The webinar will be led by GlobalLogic’s Alex Agizim, as well as Rudolf Streif, director of embedded solutions at the Linux Foundation.
More information on Nautilus can be found at GlobalLogic’s Infotainment web-page, as well as in this Embedded Computing interview with GlobalLogic’s Artem Mygaiev.
Distribution Release: PCLinuxOS 2014.08^Bill Reynolds has announced the release of PCLinuxOS 2014.08, the latest update of the project’s “KDE”, “FullMonty”, “MiniMe”, “LXDE” and “MATE” editions. Released on 12 August, it was formally announced earlier today: “All official ISO images were updated on 2014-08-12 and are available for direct….
For a few years now we have been mandating a fairly strict authentication policy for those developers who commit directly to the git repositories housing the Linux kernel. Each is issued their own ssh private key, which then becomes the sole way for them to push code changes to the git repositories hosted at kernel.org. While using ssh keys is much more secure than just passwords, there are still a number of ways for ssh private keys to fall into malicious hands — for example if the developer’s workstation is compromised or if someone manages to access some poorly secured backups (I’m willing to bet that if you check various removable media lying around your work desk, you will discover that one of them contains a full copy of your home directory from that last time you needed to reinstall your workstation and needed to make a quick copy of your files).
Keeping that in mind, we wanted to further tighten our access requirements, but without causing undue difficulties for the kernel developers.
Two-factor authentication is a pretty old concept, and I have previously written on this subject when discussing the steps we have taken to improve workstation security for all Linux Foundation systems administrators. In very basic terms, there are three main categories, or “factors” when it comes to authenticating you to a computer:
1. something you know: a password or a numeric PIN
2. something you have: a device or a card in your possession
3. something you are: your unique biometric signature, such as your fingerprint or your retinal scan.
We’ll leave “something you are” out of scope for this article and concentrate on the “something you know” and “something you have” factors. Unfortunately, even though ssh keys are very long and are stored on the hard drive of your workstation instead of kept in your memory the way a password is, they can’t be considered true “2-factor authentication,” even when the ssh key is protected by a passphrase — as I mentioned above, the ssh private key can be stolen or leaked. If we wanted to improve access security for kernel developers, we needed to add a true 2-factor authentication mechanism.
There is an extra twist to the problem, though — kernel developers work from anywhere in the world, which makes device provisioning extra difficult. We needed a solution that would allow people to enroll their own devices remotely and do most token management on their own.
In 2-factor authentication parlance, a “hard token” is a dedicated physical device that is purpose-built to do nothing else but authentication. A “soft token,” on the other hand, designates a pure-software implementation that is running on a multi-purpose portable computing device (such as a smartphone). If you’ve ever set up “two-step verification” with your Google account or turned on the “code generator” for Facebook, you’ve used a 2-factor authentication soft token. If you’ve ever used an RSA SecurID “key fob” or a Yubikey, you’ve had firsthand experience with “hard tokens.”
Both hard and soft tokens have their advantages and disadvantages. The upside of soft tokens is their convenience. After all, most of us already carry in our pockets a powerful computing device that is more than capable of calculating and displaying 6-digit codes. The downside, though, is that smartphones are consumer-grade, globally networked devices that may or may not be receiving timely security patches. Should we really make them an integral part of our authentication scheme?
Hard tokens don’t have this problem, as they are either entirely self-contained or have a very limited way of interacting with other computers. On the other hand, unless all your users are within the same physical location, provisioning hard tokens — and especially replacing them when they get lost — becomes a major problem. With hard tokens, shipping costs and productivity lost due to wait times become major obstacles.
At the Linux Foundation, we wanted to make both options available and leave the decision of whether to use a soft token or a hard token in the hands of kernel developers themselves. After all, 2-factor authentication with a soft token is still dramatically more secure than no 2-factor authentication at all. That being said, we wanted to encourage the use of more secure hardware tokens, which is why we contacted Yubico, the makers of Yubikeys, in the hopes that they would be willing to offer a discount to Linux kernel developers. To our amazement and gratitude, Yubico went well above and beyond a simple discount and offered to donate a hundred yubikeys to all Linux kernel developers who currently hold accounts at kernel.org.
A yubikey is a cute little device that incorporates a chip capable of storing the pre-shared secret and calculating a one-time token. When you plug it into your computer’s USB port, the OS recognizes it as a keyboard, which means that this device works with pretty much all operating systems without a need for drivers or configuration. There is only one button on the device, which, when pressed, generates the one-time token and sends it to the computer as a sequence of keystrokes, as if the user had typed them on the keyboard. The user then submits the authentication form and sends both their password and their one-time token to the validation server.
When the validation server receives the one-time token, it performs the same computation with its own copy of the user’s pre-shared secret. If the values match, it is a good indication that the user has the device in their possession and should be allowed to log in.
In addition to Yubico’s own 2-factor implementation, yubikeys also support OATH’s HOTP standard, which is what we opted to use for our kernel.org needs. Doing so allows us to use both soft-tokens and hard tokens interchangeably (TOTP standard is an extension of the HOTP standard).
Having the technology available is one thing, but how to incorporate it into the kernel development process — in a way that doesn’t make developers’ lives painful and unbearable? When we asked them, it became abundantly clear that nobody wanted to type in 6-digit codes every time they needed to do a git remote operation. Where do you draw the line between security and usability in this case?
We looked at the options available in gitolite, the git repository management solution used at kernel.org, and found a way that allowed us to trigger additional checks only when someone performed a write operation, such as “git push.” Since we already knew the username and the remote IP address of the developer attempting to perform a write operation, we put together a verification tool that allowed developers to temporarily whitelist their IP addresses using their 2-factor authentication token.
Here is what a developer would get if they attempted to git push from an IP address that hadn’t been 2-factor validated:
remote: IP address "x.x.x.x" has not been validated.
remote: FATAL: W VREF/2fa: testing mricon DENIED by VREF/2fa
remote: 2-factor verification failed
remote:
remote: Please get your 2-factor authentication token and run:
remote: ssh This e-mail address is being protected from spambots. You need JavaScript enabled to view it 2fa val [token]
remote:
remote: If you need more help, please see the following link:
remote: https://korg.wiki.kernel.org/userdoc:gitolite_2fa
remote:
remote: error: hook declined to update refs/heads/master
The developer would then run the following command to validate their current IP address for the next 24 hours (putting their 6-digit one-time token where it says “[token]”):
$ ssh This e-mail address is being protected from spambots. You need JavaScript enabled to view it 2fa val [token]
Valid TOTP token used
Adding IP address x.x.x.x until Sat Aug 9 28 20:29:31 2014 UTC
Once this is done, all future git operations from that IP address for that particular user would succeed until the validation expires after 24 hours. Developers may optionally validate their IP address for an extended period of time — up to a max of 30 days — which is handy if someone mostly works from the same location.
At this time, both the mainline and stable Linux kernel repositories are already protected requiring 2-factor authentication before a git push is accepted. As kernel developers congregate in Chicago to attend the annual Linux Kernel Summit, we are hoping that many more of them will choose to turn on 2-factor authentication on their own repositories hosted at kernel.org, to make it that much more difficult for an attacker to sneak in a malicious commit.
One thing for sure — giving out 100 yubikeys will definitely help encourage them. Thanks again, Yubico!
The Linux Foundation’s largest event of the year takes place this week in Chicago, starting with the co-located Linux Security Summit, Linux Kernel Summit and Xen Developer Summit today and tomorrow.
Then on Wednesday LinuxCon and CloudOpen North America start in full force with Executive Director Jim Zemlin’s “State of Linux” keynote at 9 a.m. Central, to be followed by a panel discussion of Linux kernel developers that includes Linux Creator Linus Torvalds.
All keynotes will be streamed live (live video available here with login) and will be available on the Linux Foundation YouTube channel later that day. You’ll also find live updates on Linux Foundation Twitter, Facebook and Google+ channels and at the #LinuxCon and #CloudOpen hash tags, as well as more in-depth keynote coverage here on Linux.com. Preview Q&As with most of the keynote speakers are also available at the links in the schedule, below.
Hope to see you there, in person or online!
Wednesday, Aug. 20, LinuxCon and CloudOpen keynotes include:
9 a.m. State of Linux, Jim Zemlin, Executive Director, The Linux Foundation
9:30 a.m. Linux Kernel Panel – Linus Torvalds; Andrew Morton, Google; Shuah Khan, Samsung; Andy Lutomirski, AMA Capital Management; Greg Kroah-Hartman, The Linux Foundation (Moderator)
UPDATE, Live from LinuxCon: Top 10 Quotes from the Linux Kernel Panel
4:50 p.m. Reinventing Education Through Massive Open Online Courses – Anant Agarwal, CEO at edX
5:10 p.m. How Open Collaboration is Fostering a New Era in Vehicle Development – Jay Rogers, CEO & Co-Founder of Local Motors
5:30 p.m. The New Open Source Professional – Eileen Evans, HP Vice President and Deputy General Counsel of Cloud Computing and Open Source
Thursday, Aug. 21
9 a.m. From Cloud to Fog Computing and the Internet of Things – Michael Enescu, CTO of Open Source Initiatives, Cisco
9:20 a.m. Containers: Changing The Landscape – Solomon Hykes, Founder of Docker
9:40 a.m. Linux in the New Connected World – Imad Sousou, Vice President and General Manager, Intel Open Source Technology Center
Friday, Aug. 22
9 a.m. Innovation in a 3D Printing Community – Anthony Moschella – Vice President of Product, MakerBot
9:20 a.m. Innovations in Prosthetics With Open Source – Jonathan Kuniholm, President, Open Prosthetics Project
9:40 a.m. Revolutionize the Way IT is Created and Consumed – Douglas Balog, General Manager, Power Systems, IBM Systems and Technology Group
