DOCSLIB.ORG

Proceedings of the Linux Symposium

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Proceedings of the Linux Symposium 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.
Load more

Recommended publications
  • Create an Email with Subject Title “Embedded Software Engineer”, Email a Copy of Your Resume to [email protected]
    To Apply for This Position: Create an email with subject title “Embedded Software Engineer”, email a copy of your resume to [email protected] Location Address: ALLEN PARK, MI,48101 Position Description: TITLE: Embedded Software Engineer ‐ Hypervisor OS technologies This position is responsible to develop QNX and Android operating system images for Ford infotainment products. This includes creating and integrating code for: bootloader, kernel, drivers, type 1 hypervisor, and build environment. Skills Required: • Lead the design, bring‐up and support of QNX and Android operating system images • Create virt‐io drivers for QNX or Android guest operating systems • Participate in root cause analysis of hardware quality problems and software defects • Participate in system design, documentation, and testing to deliver a best‐in‐class infotainment system Experience Required: • 5+ years operating system experience involving Linux or QNX • 5+ years C/C++ software development experience on embedded, mobile, or consumer electronic platforms Experience Preferred: • Experience with Type 1 hypervisors • Experience creating virt‐io drivers • Mastery of C/C++ language, GNU tool chain, and Unix (QNX, Linux, or equivalent) • Experience with embedded build systems including QNX system builder, buildroot, yocto, or equivalent • Knowledge of in‐vehicle signaling and communication mechanisms such as CAN • Proficiency with revision control including Git, Subversion, or equivalent • Multi‐site software project team experience Education Required: • Bachelor's degree in Computer Engineering, Electrical Engineering, Computer Science, or related Education Preferred: • Master's degree in Computer Engineering, Electrical Engineering or Computer Science Additional Information: Web Based Assessment not required for this position. Visa Sponsorship and Domestic Relocation is available for this position.
    [Show full text]
  • Software in the Public Interest, Inc. 2011-2012 Annual Report
    Software in the Public Interest, Inc. 2011-2012 Annual Report 1st July 2012 To the membership, board and friends of Software in the Public Interest, Inc: As mandated by Article 8 of the SPI Bylaws, I respectfully submit this annual report on the activities of Software in the Public Interest, Inc. and extend my thanks to all of those who contributed to the mission of SPI in the past year. { Jonathan McDowell, SPI Secretary 1 Contents 1 President's Welcome3 2 Committee Reports4 2.1 Membership Committee.......................4 2.1.1 Statistics...........................4 3 Board Report5 3.1 Board Members............................5 3.2 Board Changes............................6 3.3 Elections................................6 4 Treasurer's Report7 4.1 Income Statement..........................7 4.2 Balance Sheet.............................9 5 Member Project Reports 11 5.1 New Associated Projects....................... 11 5.1.1 Drizzle............................. 11 5.1.2 Arch Linux.......................... 11 5.1.3 FreedomBox......................... 11 5.1.4 Fluxbox............................ 12 5.1.5 Haskell.org.......................... 12 5.1.6 FFmpeg............................ 12 A About SPI 13 2 Chapter 1 President's Welcome { Bdale Garbee, SPI President 3 Chapter 2 Committee Reports 2.1 Membership Committee The membership committee was extended to cover the entire board. 2.1.1 Statistics At the time of writing (July 10th) the current membership status is: NC Applicants Pending Email Approval 94 NC Members 485 Contrib Membership Applications 11 Contrib Members 489 Application Managers 9 On 1st July 2011 we had 445 contributing and 436 non-contributing members. On 1st July 2011 there were 481 contributing members and 452 non-contributing members.
    [Show full text]
  • Linux: Kernel Release Number, Part II
    Linux: Kernel Release Number, Part II Posted by jeremy on Friday, March 4, 2005 - 07:05 In the continued discussion on release numbering for the Linux kernel [story], Linux creator Linus Torvalds decided against trying to add meaning to the odd/even least significant number. Instead, the new plan is to go from the current 2.6.x numbering to a finer-grained 2.6.x.y. Linus will continue to maintain only the 2.6.x releases, and the -rc releases in between. Others will add trivial patches to create the 2.6.x.y releases. Linus cautions that the task of maintaining a 2.6.x.y tree is not going to be enjoyable: "I'll tell you what the problem is: I don't think you'll find anybody to do the parallell 'only trivial patches' tree. They'll go crazy in a couple of weeks. Why? Because it's a _damn_ hard problem. Where do you draw the line? What's an acceptable patch? And if you get it wrong, people will complain _very_ loudly, since by now you've 'promised' them a kernel that is better than the mainline. In other words: there's almost zero glory, there are no interesting problems, and there will absolutely be people who claim that you're a dick-head and worse, probably on a weekly basis." He went on to add, "that said, I think in theory it's a great idea. It might even be technically feasible if there was some hard technical criteria for each patch that gets accepted, so that you don't have the burn-out problem." His suggested criteria included limiting the patch to being 100 lines or less, and requiring that it fix an oops, a hang, or an exploitable security hole.
    [Show full text]
  • OS Selection for Dummies
    OS SELECTION HOW TO CHOOSE HOW TO CHOOSE Choosing your OS is the first step, so take the time to consider your choice fully. There are many parameters to take into account: l Is this a new project or the evolution of an existing product? l Using the same SW stack? Re-using existing code? l Is your team familiar with a particular OS? Ø Using an OS you are already comfortable with can help l What are the HW constraints of your system? Ø Some operating systems require more memory/processing power than others l Have no SW team? Not sure about the above? Ø Contact us so we can help you decide! Ø We can also introduce you to one of our many partners! 1 OS SELECTION OPEN SOURCE VS. COMMERCIAL OS Embedded OS BSP Provider $ Cost Open-Source OS Boundary Devices • Embedded Linux / Android Embedded Linux $0, included • Large pool of developers available with Board Purchase • Strong community • Royalty-free And / or partners 3rd Party - Commercial OS Partners • QNX / Win10 IoT / Green Hills $>0, depends on • Professional support requirements • Unique set of development tools 2 OS SELECTION OPEN SOURCE SELECTION OS SELECTION PROS CONS Embedded Linux Most powerful / optimized Complexity for newcomers solution, maintained by NXP • Build systems Ø Yocto / Buildroot Simpler solution, makefile- Not as flexible as Yocto Ø Everything built from scratch based, maintained by BD Desktop-like approach, Harder to customize, non- Package-based distribution easy-to-use atomic updates, no cross- • Ubuntu / Debian compilation SDK Apt install / update, millions • Packages installed from server of prebuilt packages available Android Millions of apps available, same number of developers, Resource-hungry, complex • AOSP-based (no GMS) development environment, BSP modifications (HAL) • APK applications IDE + debugging tools 3 SOFTWARE PARTNERS Boundary Devices has an industry-leading group of software partners.
    [Show full text]
  • Ivoyeur: Inotify
    COLUMNS iVoyeur inotify DAVE JOSEPHSEN Dave Josephsen is the he last time I changed jobs, the magnitude of the change didn’t really author of Building a sink in until the morning of my first day, when I took a different com- Monitoring Infrastructure bination of freeways to work. The difference was accentuated by the with Nagios (Prentice Hall T PTR, 2007) and is Senior fact that the new commute began the same as the old one, but on this morn- Systems Engineer at DBG, Inc., where he ing, at a particular interchange, I would zig where before I zagged. maintains a gaggle of geographically dispersed It was an unexpectedly emotional and profound metaphor for the change. My old place was server farms. He won LISA ‘04’s Best Paper off to the side, and down below, while my future was straight ahead, and literally under award for his co-authored work on spam construction. mitigation, and he donates his spare time to the SourceMage GNU Linux Project. The fact that it was under construction was poetic but not surprising. Most of the roads I [email protected] travel in the Dallas/Fort Worth area are under construction and have been for as long as anyone can remember. And I don’t mean a lane closed here or there. Our roads drift and wan- der like leaves in the water—here today and tomorrow over there. The exits and entrances, neither a part of this road or that, seem unable to anticipate the movements of their brethren, and are constantly forced to react.
    [Show full text]
  • Seminar HPC Trends Winter Term 2017/2018 New Operating System Concepts for High Performance Computing
    Seminar HPC Trends Winter Term 2017/2018 New Operating System Concepts for High Performance Computing Fabian Dreer Ludwig-Maximilians Universit¨atM¨unchen [email protected] January 2018 Abstract 1 The Impact of System Noise When using a traditional operating system kernel When running large-scale applications on clusters, in high performance computing applications, the the noise generated by the operating system can cache and interrupt system are under heavy load by greatly impact the overall performance. In order to e.g. system services for housekeeping tasks which is minimize overhead, new concepts for HPC OSs are also referred to as noise. The performance of the needed as a response to increasing complexity while application is notably reduced by this noise. still considering existing API compatibility. Even small delays from cache misses or interrupts can affect the overall performance of a large scale In this paper we study the design concepts of het- application. So called jitter even influences collec- erogeneous kernels using the example of mOS and tive communication regarding the synchronization, the approach of library operating systems by ex- which can either absorb or propagate the noise. ploring the architecture of Exokernel. We sum- Even though asynchronous communication has a marize architectural decisions, present a similar much higher probability to absorb the noise, it is project in each case, Interface for Heterogeneous not completely unaffected. Collective operations Kernels and Unikernels respectively, and show suffer the most from propagation of jitter especially benchmark results where possible. when implemented linearly. But it is hard to anal- yse noise and its propagation for collective oper- ations even for simple algorithms.
    [Show full text]
  • UEFI PXE and Ipxe Alternative Approaches to PXE Booting
    Installing ESXi Using PXE n gPXELINUX is a hybrid configuration that includes both PXELINUX and gPXE and supports booting from a Web server. gPXELINUX is part of the SYSLINUX package. If you use gPXELINUX to boot the ESXi installer, only the gpxelinux.0 binary file, mboot.c32, and the configuration file are transferred via TFTP. The remaining files are transferred via HTTP. HTTP is typically faster and more reliable than TFTP, especially for transferring large amounts of data on a heavily loaded network. NOTE VMware currently builds the mboot.c32 plugin to work with SYSLINUX version 3.86 and tests PXE booting only with that version. Other versions are likely to be incompatible. This is not a statement of limited support. For support of third-party agents that you use to set up your PXE booting infrastructure, contact the vendor. UEFI PXE and iPXE Most UEFI firmware natively includes PXE support that allows booting from a TFTP server. The firmware can directly load the ESXi boot loader for UEFI systems, mboot.efi. Additional software such as PXELINUX is not required. iPXE can also be useful for UEFI systems that do not include PXE in firmware and for older UEFI systems with bugs in their PXE support. For such cases you can try installing iPXE on a USB flash drive and booting from there. NOTE Apple Macintosh products do not include PXE boot support. They include support for network booting via an Apple-specific protocol instead. Alternative Approaches to PXE Booting Alternative approaches to PXE booting different software on different hosts are also possible, for example: n Configuring the DHCP server to provide different initial boot loader filenames to different hosts depending on MAC address or other criteria.
    [Show full text]
  • The Document Foundation: a Sustainable Independent Free Software Project First Thought
    The Document Foundation: a Sustainable Independent Free Software Project First Thought When you come to a fork in the road, take it Yogi Berra Some Fun to Warm Up the Atmosphere LibreOf"ce #1 it's my pleasure to announce that according to NAIF* Metrics i!reOffice is the fastest growing free software project in the world * Native American Inflated Figures +&& %ode + Wiki Contributors *'& *&& )'& )&& ('& LibreOffice Code + Wiki Contributors per Month (&& '& & Sep 10 Oct 10 Nov 10 Dec 10 Jan 11 Feb 11 Mar 11 Apr 11 May 11 Jun 11 Jul 11 Aug 11 Sep 11 Oct 11 Nov 11 Dec 11 Jan 12 Feb 12 Mar 12 Apr 12 May 12 Jun 12 Jul 12 Aug 12 %umulative Number (-&& (,&& (+&& Cumulative Number of LibreOffice Code + Wiki Contributors ()&& (&&& -&& ,&& +&& )&& & Sep 10 Oct 10 Nov 10 Dec 10 Jan 11 Feb 11 > Mar 11 1,600 Apr 11 May 11 Jun 11 Jul 11 Aug 11 Sep 11 Oct 11 Nov 11 Dec 11 Jan 12 Feb 12 Mar 12 Apr 12 May 12 Jun 12 Jul 12 Aug 12 Sep 12 LibreOf"ce is Growing 100,000 150,000 200,000 250,000 300,000 350,000 400,000 450,000 500,000 550,000 600,000 650,000 700,000 50,000 0 -rowth of Download Numbers Download of -rowth 2012-01 2012-02 2012-03 2012-04 2012-05 LibreOffice DirectWeek per Downloads LibreOffice 2012-06 2012-07 2012-08 2012-09 Downloads/Week 2012-10 2012-11 2012-12 2012-13 2012-14 2012-15 2012-16 Linear (Downloads/Week) 2012-17 2012-18 2012-27 2012-28 2012-29 2012-30 2012-31 2012-32 2012-33 2012-34 2012-35 2012-36 2012-37 2012-38 2012-39 2012-40 City of Munich lo(es LibreOf"ce After careful risk-assessment, the capital of Munich has decided to migrate from "pen"ffice to Li!re"ffice/ In favour of that decision, among others, was the greater flexi!ility of the project regarding consumption of open source licenses.
    [Show full text]
  • The Linux Device File-System
    The Linux Device File-System Richard Gooch EMC Corporation [email protected] Abstract 1 Introduction All Unix systems provide access to hardware via de- vice drivers. These drivers need to provide entry points for user-space applications and system tools to access the hardware. Following the \everything is a file” philosophy of Unix, these entry points are ex- posed in the file name-space, and are called \device The Device File-System (devfs) provides a power- special files” or \device nodes". ful new device management mechanism for Linux. Unlike other existing and proposed device manage- This paper discusses how these device nodes are cre- ment schemes, it is powerful, flexible, scalable and ated and managed in conventional Unix systems and efficient. the limitations this scheme imposes. An alternative mechanism is then presented. It is an alternative to conventional disc-based char- acter and block special devices. Kernel device drivers can register devices by name rather than de- vice numbers, and these device entries will appear in the file-system automatically. 1.1 Device numbers Devfs provides an immediate benefit to system ad- ministrators, as it implements a device naming scheme which is more convenient for large systems Conventional Unix systems have the concept of a (providing a topology-based name-space) and small \device number". Each instance of a driver and systems (via a device-class based name-space) alike. hardware component is assigned a unique device number. Within the kernel, this device number is Device driver authors can benefit from devfs by used to refer to the hardware and driver instance.
    [Show full text]
  • Project Report - Adding PXE Boot Into Palacios
    Project Report - Adding PXE Boot into Palacios Chen Jin Bharath Pattabiraman Patrick Foley EECS Department EECS Department EECS Department Northwestern University Northwestern University Northwestern University chen.jin@eecs. bharath@u. patrickfoley2011@u. northwestern.edu northwestern.edu northwestern.edu ABSTRACT PXE is a standard for booting an OS from the network. Most machines BIOSes support it. But, the BIOS used by Palacios guests did not. In our project, we tried various ways in which PXE network boot capability could be added to Palacios. We used a PXE-capable Etherboot ROM image from ROM-o-matic.net that has support for our emulated network card. We then used this small ISO image to build the guest and let it serve as a replacement PXE-boot ROM for the emulated network card. With passthrough I/O, the requests are handed over directly to the host, which are then sent to the DHCP and Boot servers to initiate the network boot process. The PXE capability will of vital importance in diskless nodes where the node is completely dependent on Figure 1: PXE system configuration the network for booting. 1. INTRODUCTION using PXE protocol and then boots the guest. PXE (Preboot eXecution Environment) allows us to boot Kitten/Palacios (and a test guest) remotely from a network server. Booting Palacios/Kitten over a network server is 2. SYSTEM already possible. In this research effort we have enabled So, as shown in Figure 1, in order to use PXE we need to Palacios to remote boot a guest OS using PXE. setup a PXE-server which can allow client systems to: PXE is defined on a foundation of Internet protocols, namely • TCP/IP, DHCP, and TFTP.
    [Show full text]
  • Demarinis Kent Williams-King Di Jin Rodrigo Fonseca Vasileios P
    sysfilter: Automated System Call Filtering for Commodity Software Nicholas DeMarinis Kent Williams-King Di Jin Rodrigo Fonseca Vasileios P. Kemerlis Department of Computer Science Brown University Abstract This constant stream of additional functionality integrated Modern OSes provide a rich set of services to applications, into modern applications, i.e., feature creep, not only has primarily accessible via the system call API, to support the dire effects in terms of security and protection [1, 71], but ever growing functionality of contemporary software. How- also necessitates a rich set of OS services: applications need ever, despite the fact that applications require access to part of to interact with the OS kernel—and, primarily, they do so the system call API (to function properly), OS kernels allow via the system call (syscall) API [52]—in order to perform full and unrestricted use of the entire system call set. This not useful tasks, such as acquiring or releasing memory, spawning only violates the principle of least privilege, but also enables and terminating additional processes and execution threads, attackers to utilize extra OS services, after seizing control communicating with other programs on the same or remote of vulnerable applications, or escalate privileges further via hosts, interacting with the filesystem, and performing I/O and exploiting vulnerabilities in less-stressed kernel interfaces. process introspection. To tackle this problem, we present sysfilter: a binary Indicatively, at the time of writing, the Linux
    [Show full text]
  • Netflix Security Requirements for Android Platforms Version 1.0 December 6, 2010
    Netflix Security Requirements for Android Platforms Version 1.0 December 6, 2010 Netflix Confidential Overall Security Philosophy • Netflix and Partners are working together to create a market for connected platforms and services • For long-term success, this requires a healthy and secure ecosystem – Based on best practices – Transparency between content, service, and platform partners – Proactive cooperation, rapid response • Our mutual success depends on it – Breaches hurt everyone Netflix Confidential Typical Studio Requirements • Platforms must meet agreed-upon robustness specifications (Netflix Robustness Rules, DRM providers’ robustness rules) • Platform partners must submit sample products and security documentation to Netflix for certification. – Netflix must review documentation and assess compliance with robustness specifications • If a platform is breached, Netflix or partner may be required to revoke individual or class of platforms. • In case of extended breach or platform non-compliance, studio has option to suspend availability of content to the Netflix service. – Such action would adversely affect all platforms and all Netflix subscribers. Netflix Confidential Android vs. Studio Requirements • Most Android platforms have been “rooted” – yields full control of system – history suggests this problem will not go away • Once rooting occurs, Linux security model is insufficient to protect content -related assets • Without modification, these platforms do not allow Netflix to meet contractual obligations to studios • We are aggressively working with partners to address this vulnerability Netflix Confidential High-Level Platform Security Concerns • Content Protection – DRM keys – Content keys – AV content • Application Security – Application keys – Access to Netflix APIs & functionality – Non-modifiability – Non-migrateability Netflix Confidential Content Protection: DRM Keys • Group key – typically provisioned in manufacturing – one key for entire class of devices (e.g.
    [Show full text]