Using a hypervisor to reconcile GPL and proprietary embedded code
Aug 27, 2007 — by LinuxDevices Staff — from the LinuxDevices Archive — 182 viewsForeword: This guest whitepaper explains how a hypervisor can be used to leverage GPL software while isolating it from proprietary code, in order to ensure compliance with the requirements of the GPL. It was written by a TRANGO Virtual Processors product manager, and uses that company's hypervisor as an example.
Using a hypervisor to reconcile GPL and proprietary embedded code by Bruno Zoppis
Open source software is of increasing use in embedded systems. The GNU General Public License (GPL) version 2 is one of the most popular licenses for free and open source software, including the Linux kernel. On June 29, 2007, version 3 of the GPL was published, clarifying some aspects of the v2 license, and adding clauses to deal with consumer products, web applications, and patents.
The use of GPL software in consumer products may create issues for device manufacturers who need to protect proprietary code or to guarantee their systems' behavior. In this article, we study the impact of the use of both GPL v2 and v3 in consumer products, and how using secure virtualization along with hypervisor technology can help device manufacturers comply with these GPL licenses while protecting business-critical IP (intellectual property) and system behavior.
What is a hypervisor?
Although the concept of virtualization has existed since the 1960s, the current high level of interest in the technology has led to the misuse of accurate terminology. In this article, we use the term “hypervisor” to refer to the original goal of a hypervisor: to provide a virtualization layer that strictly isolates virtual machines from each other for security and reliability purposes.
The following quotations help establish some of the key attributes of hypervisors and their relation to virtual machines (italics have been added for emphasis):
- “Hypervisors are becoming an ubiquitous virtualization layer on client and server systems. They are designed to isolate operating systems by running them in isolated run-time environments on a single hardware platform.” [Footnote 1]
- “Firstly, virtual machines must be isolated from one another: it is not acceptable for the execution of one to adversely affect the performance of another. This is particularly true when virtual machines are owned by mutually untrusting users.” [Footnote 2]
- “A virtual machine monitor (VMM) is a thin virtualization layer between hardware and 'guest' operating systems, enabling hosts to safely execute untrusted applications and guest OS's inside a VM.” [Footnote 3]
A list of hypervisor technologies appears at the conclusion of the article.
GPL v2 and end-user products
The GPL v2 states:
“The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software — to make sure the software is free for all of its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it.”
GPL v2 programs, especially Linux, are being used more and more frequently in embedded systems and in consumer products such as set-top boxes, personal video recorders, GPS navigation devices, and DSL modem/routers. Despite this fact, the end-users of these devices are usually not aware that GPL-based programs run them. Indeed, many vendors fail to provide a verbatim copy of the GPL with their product, with the appropriate copyright notice and warranty disclaimer [Footnote 6] (see GPLv2 paragraph 1, GPL v3 paragraph 4).
Device vendors are also required to provide access to the source code of the GPL programs (see PLv2 paragraph 3, GPLv3 paragraph 6), including “the scripts used to control compilation and installation of the executable” [Footnotes 4, 6]. However, the GPLv2 does not require that installed executables must work, which enables a mechanism the Free Software Foundation calls “Tivoization.”
“Tivoization,” according to LinuxInfo.org, “refers to the configuring (by the manufacturer or vendor) of a digital electronic product that uses free software, so that the product will operate only with a specific version of such software.” Technically, this means that a vendor of a product that uses GPL v2 programs could provide access to the source code, thus being compliant with the software license, but the product would be prevented from working if a modified version is installed, through the checking of the software image's signature.
The same article provides some reasons why device vendors would want to maintain complete control of the software that runs on the device:
- Digital Rights Management (DRM)
- Prevent the user from deleting “spyware” that sends data back to the vendor about the product's use
- Customer support, more difficult with an heterogeneous software base
- Legal or contractual liability
Other motivations may also be to:
- Prevent the use of a hacked device from attacking vendor infrastructure
- Keep some features or behavior of a product proprietary and unmodifiable
- Protect some proprietary software or drivers against illegal copying or reverse engineering, if not connected to the GPL-based software
GPL v3
The GPL v2 has faced various problems since 1999. One concerns terminologies regarding “distributing a program” and “derivative works,” both of which needed to be clarified.
Another area of change in the new version relates to patents, partly to make the GPL license compatible with other open source licenses, and partly to break the most aggressive patent schemes (GPLv3, paragraph 11).
But the subject that generates the most controversial discussions is the “anti-Tivoization clause” that requires that the source code “must be accompanied by the Installation Information” (GPLv3 paragraph 6) if the vendor or another third party retains the ability to install modified object code on the product” (GPLv3 paragraph 6).
According to the GPL v3:
“'Installation Information' for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.” [Footnote 5]
Linux status
As Linux is one of the most well known GPL projects, and is frequently used in embedded and consumer devices, the status of Linux regarding GPL v3 is important, and has driven numerous discussions on the Web.
The Linux kernel is currently distributed under the GPL v2 license. The early drafts of the GPL v3 were strongly criticized by Linus Torvalds, but the latest version encountered less opposition [Footnote 7]. In any case, it seems unlikely that the Linux kernel will move to GPL v3 in the short term.
Regarding non-GPL modules: Even if nearly all kernel developers preferred GPL code, the current requirement is to specify which parts of the kernel API can be used by non-GPL modules, and which parts are so tightly integrated that their use consists of a derived work of the Linux kernel. The macro, EXPORT_SYMBOL_GPL, which makes those symbols present only to modules covered under the GPL license, helps to enforce that difference. The status of GPL v3 modules is not yet defined.
But a GNU/Linux system is composed of many components, some of which will certainly migrate to GPLv3. Those components, if they execute with an appropriate privilege level, can be used by the customer to take control of a device. As an example, Samba, a SMB/CIFS server, has been governed by GPLv3 since version 3.2.0 [Footnote 9]. A vendor that uses a recent version of Samba in its product will have to provide to his customers the installation information required to install modified versions of this software. As the Samba daemon is executed with root privileges, a hacked version could help the customer to gain root access to the system.
Moreover, this means that using another operating system with a different license, such as the BSD version, is not sufficient to completely block the customers' rights on a device, as long as GPLv3 applications run on it with root privileges.
Virtualization
The purpose of a hypervisor is to provide several execution environments on a single hardware platform. On the x86 architecture, hypervisors such as KVM, VMware, or Xen allow the running of multiple operating systems, simultaneously, on the same host. In the mainframe world, IBM uses hypervisor technology to create several virtual servers on the same mainframe [Footnote 10].
Figure 1: Example of Virtualized System Architecture
A hypervisor provides a CPU-like interface to the operating systems or applications that run in each of its virtual machines (VMs). As presented in Figure 1, the hypervisor is neither integrated into the operating systems' kernels nor run as an OS application. Therefore, the hypervisor can in no way be considered as a “derivative work” of any operating system or application.
The VMs that run on the hypervisor use an interface that does not require them to be linked with the hypervisor. The use of this interface is considered to be a normal use of the hypervisor and does not turn the VMs into a derivative work of the hypervisor. Thus the development of open- or closed-source virtual machines is not an issue.
In the same way an operating system can simultaneously run multiple applications, with different licenses, the virtual machines that run on the hypervisor do not need to be of the same license. It is thus possible to run a GPL v2/v3-based operating system beside a proprietary one, such as Windows CE.
Use of a hypervisor for GPL isolation
The hypervisor can help device vendors maintain control of basic device behavior while being compliant with the GPL license, either v2 or v3. The design of such a system requires the use of different VMs to separate GPL operating systems from non-GPL components whose behavior must be guaranteed.
Figure 2 presents an example of a video broadcast client system. The Linux VM receives the encrypted video stream through the network interface. To play the video, Linux sends the data to the video application, which manages the decryption and decoding of the video and sends the output to the GUI (graphical user interface). Thus, the decrypted stream and the encryption keys are never present in Linux memory, removing Linux from the trusted data path. Furthermore, by using separate VMs to manage the different layers, it becomes possible for Linux to manage a GUI without having access to the video layer, while a DRM-protected video is displayed.
Figure 2: Example of a video broadcast system utilizing hypervisor technology
In this application, video data arrives from the network and is placed into memory shared by the Linux VM and the video display VM. The second VM manages the video stream decryption, decoding and display. The keys and the decrypted data are never accessible to the Linux applications or kernel.
The bootstrap sequence checks the integrity of the hypervisor, but not the GPL VM code, before starting the hypervisor. The GPL operating system remains freely modifiable by the customer. The strong isolation provided by the hypervisor, coupled with the fact that access to the system's peripherals is restricted on a VM-by-VM basis, ensures that a hacked Linux operating system can not be granted greater rights than it had when it was delivered by the device manufacturer. Therefore it enables decrypted content, encryption/decryption keys, and sensitive devices to be protected from illegal attacks.
More generally, the hypervisor can be used to add Linux to a device alongside a legacy operating system or application, partitioning the peripherals and other resources so as to be accessible to both of them. It is important to note that to ensure protection of the legacy part from modification, the hypervisor itself must not be under GPL v3 or a license with similar restrictions regarding installation of modified versions.
Conclusion
The use of a hypervisor can assist device vendors with GPL license compliance, both v2 and v3. It also allows vendors to maintain strong control over their other software components, and ensure that a modified version of GPL software cannot be used to gain access to their sensitive devices or data, or to modify the fundamental behavior of the system.
| References |
|---|
List of hypervisor technologies
Note: As XEN is GPL-based, it is not compatible with GPL isolation requirements. Footnotes
|
About the author: Bruno Zoppis Product Manager at TRANGO Virtual Processors, and previously held the position of software engineer at Sun Microsystems.
Copyright (c) 2007, TRANGO Virtual Processors. All rights reserved. Reproduced by LinuxDevices.com with permission.
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.