Proceedings of the Linux Symposium Volume One July 23rd–26th, 2008 Ottawa, Ontario Canada Contents x86 Network Booting: Integrating gPXE and PXELINUX 9 H. Peter Anvin Keeping the Linux Kernel Honest 19 Kamalesh Babulal & Balbir Singh Korset: Automated, Zero False-Alarm Intrusion Detection for Linux 31 Ohad Ben-Cohen & Avishai Wool Suspend-to-RAM in Linux 39 Len Brown & Rafael J. Wysocki Systems Monitoring Shootout 53 K. Buytaert, T. De Cooman, F. Descamps, & B. Verwilst Virtualization of Linux servers 63 F.L. Camargos, G. Girard, & B. des Ligneris MondoRescue: a GPL Disaster Recovery Solution 77 Bruno Cornec The Corosync Cluster Engine 85 Steven C. Dake LTTng: Tracing across execution layers, from the Hypervisor to user-space 101 Mathieu Desnoyers Getting the Bits Out: Fedora MirrorManager 107 Matt Domsch Applying Green Computing to clusters and the data center 113 Andre Kerstens & Steven A. DuChene Introduction to Web Application Security Flaws 123 Jake Edge Around the Linux File System World in 45 minutes 129 Steve French Peace, Love, and Rockets! 135 Bdale Garbee Secondary Arches, enabling Fedora to run everywhere 137 Dennis Gilmore Application Testing under Realtime Linux 143 Luis Claudio R. Gonçalves & Arnaldo Carvalho de Melo IO Containment 151 Naveen Gupta Linux Capabilities: making them work 163 Serge E. Hallyn & Andrew G. Morgan Issues in Linux Mirroring: Or, BitTorrent Considered Harmful 173 John Hawley Linux, Open Source, and System Bring-up Tools 183 Tim Hockin Audio streaming over Bluetooth 193 Marcel Holtmann Cloud Computing: Coming out of the fog 197 Gerrit Huizenga Introducing the Advanced XIP File System 211 Jared Hulbert Low Power MPEG4 Player 219 J.-Y. Hwang, J.-H. Kim, & J.-H. Kim VESPER (Virtual Embraced Space ProbER) 229 S. Kim, S. Moriya, & S. Oshima Camcorder multimedia framework with Linux and GStreamer 239 W. Lee, E. Kim, J. Lee, S. Kim & S. Park On submitting kernel patches 253 Andi Kleen Ext4 block and inode allocator improvements 263 A. Kumar, M. Cao, J. Santos, & A. Dilger Bazillions of Pages 275 Christoph Lameter Conference Organizers Andrew J. Hutton, Steamballoon, Inc., Linux Symposium, Thin Lines Mountaineering C. Craig Ross, Linux Symposium Review Committee Andrew J. Hutton, Steamballoon, Inc., Linux Symposium, Thin Lines Mountaineering Dirk Hohndel, Intel Gerrit Huizenga, IBM Dave Jones, Red Hat, Inc. Matthew Wilson, rPath C. Craig Ross, Linux Symposium Proceedings Formatting Team John W. Lockhart, Red Hat, Inc. Gurhan Ozen, Red Hat, Inc. Eugene Teo, Red Hat, Inc. Kyle McMartin, Red Hat, Inc. Jake Edge, LWN.net Robyn Bergeron Dave Boutcher, IBM Mats Wichmann, Intel Authors retain copyright to all submitted papers, but have granted unlimited redistribution rights to all as a condition of submission. x86 Network Booting: Integrating gPXE and PXELINUX H. Peter Anvin Marty Connor rPath, Inc. Etherboot Project <[email protected]> <[email protected]> Abstract 2 The PC Platform: Ancient History On the x86 PC platform, network booting is most com- Network booting has been implemented in various monly done using software that follows the Preboot Ex- forms for many years. To appreciate how it evolved it ecution Environment (PXE) specification. PXELINUX is instructive to examine the early days of PC comput- from the SYSLINUX Project and gPXE from the Ether- ing when standards were few, and achieving consensus boot Project are popular Open Source implementations between vendors on any technical innovation was even of key PXE components. more difficult than it is today. In this presentation, we will describe how these two The x86 PC platform has a direct lineage to the origi- projects were able to jointly develop an integrated PXE- nal IBM PC 5150 released in 1981. This machine, an compatible product that provides additional network open platform, and its successors, the 1983 IBM XT booting capabilities that go well beyond the PXE spec- and the 1984 IBM AT, were widely copied by a num- ification. We will also discuss some of the organiza- ber of manufacturers. The PC industry largely followed tional challenges encountered during this collaboration IBM’s technical lead until the disastrous 1987 attempt between two Open Source projects with different prior- at reclaiming their initial monopoly position with the ities, design goals, and development strategies. closed platform PS/2 line erased their technical and mar- ketplace leadership positions in the industry. 1 Motivation As a result, for the first half of the 1990s there was no Open Source software development by definition allows clear path for new standards to become accepted on the and encourages code sharing and collaboration between PC platform, and PCs were becoming little more than projects. There are, however, costs associated with these massively sped-up versions of the IBM AT. Thus, even endeavors, and these costs must be weighed against po- as new media such as networking and CD-ROMs be- tential benefits associated with using code developed by came available to the platform, there was little support another project. for booting from anything other than the initially sup- ported floppy and hard disk, although PCs could option- In the case of improving integration between gPXE and ally use an expansion card carrying proprietary booting PXELINUX, developers from SYSLINUX and the Ether- firmware. boot Project were motivated to collaborate because they believed there might be significant benefits to leverag- TCP/IP networking, as something other than a niche ing work already done by the other project. Although product, came late to the x86 PC platform. For many the process of creating better interoperability between years, memory limitations when running MS-DOS and products required significant communication and effort, its derivatives meant that simpler, proprietary network it was a useful and rewarding exercise for both develop- stacks were used; the primary ones being NetBIOS from ment teams. IBM and Microsoft, and IPX from Novell. To understand how these two Open Source projects The response of early network card manufacturers, to reached this point of collaboration we will examine the the extent they supported booting from networks at all, history of network booting on the x86 PC platform, as was simply to provide a socket into which a ROM (usu- well as the development journey each project took prior ally an EPROM) could be inserted by the end user. This to this collaborative effort. ROM had to be preprogrammed with firmware specific • 9 • 10 • x86 Network Booting: Integrating gPXE and PXELINUX both to the network card and the network protocol used; Open Source world at specifying an OS-independent as a result, these ROMs were frequently expensive, and method for network booting on the PC platform. few PCs were ever so equipped. To further complicate the situation, the size of ROMs varied widely depend- To keep NBI loader code uncomplicated, a utility called ing on the card. Some cards supported as little as 8K of mknbi was used to convert OS specific files such as ker- ROM space, greatly limiting the amount and complexity nels and initrds into NBI format for loading into mem- of boot software that could be supplied. ory. This simplified loader code because it only needed to load a single, uncomplicated image format. It did, In the early 1990s, as the use of TCP/IP became more however, require an extra step to convert OS images to prevalent, some manufacturers provided TCP/IP-based NBI format prior to booting. booting solutions using the then-standard BOOTP and TFTP protocols, often based on downloading a floppy NBI was never used in the closed-source OS world. image to high memory (above the 1 MB point address- Instead, vendors continued to offer incompatible solu- able by DOS.) These solutions generally did not pro- tions, usually based on their respective proprietary net- vide any form of post-download access to the firmware; work stacks. the downloaded floppy image was expected to contain a software driver for a specific network card and to access In 1997, Intel et al. published the Wired for Manage- the hardware directly. ment Specification (WfM) [5]. It included as an ap- pendix a specification for the Preboot Execution En- By the mid 1990s, the PC industry, including IBM, was vironment (PXE), a TCP/IP-based, vendor-neutral net- seriously suffering from having outgrown IBM AT stan- work booting protocol for PCs, which included an appli- dards. In January 1995, Phoenix and IBM published the cation programming interface (API) for post-download “El Torito” standard [3] for booting PCs from CD-ROM access to the firmware driver. The specification, as well media. Support for this standard was initially poor, and as its current successor [6], both have numerous techni- for the rest of the decade most operating systems that cal shortcomings, but it finally made it possible for NIC were distributed on CD-ROM media generally shipped and motherboard vendors to ship generic network boot- with install floppies for booting PCs that lacked func- ing firmware. Higher-end NICs began to have onboard tional CD-ROM booting support. flash memory preprogrammed with PXE from the fac- tory instead of providing a socket for a user-installable 3 NBI and PXE: Network Booting Strategies ROM. Motherboards began to have PXE firmware inte- grated into their BIOSes. As the cost of network interface cards (NICs) dropped The PXE specification defines a set of software com- dramatically in the early 1990s, the cost of a network ponents (Figure 1) including a PXE Base Code (BC) boot ROM could be a substantial fraction of the cost of stack, a Universal Network Driver Interface (UNDI) the NIC itself. The use of OS-dependent, user-installed driver—both in ROM—and a Network Boot Program ROMs as the only method for network booting had be- (NBP), which loads from a server.