Get news? 2011 | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 | 2001 | 2000 | 1999 | 1998 | 1997 | About | Contact Want to help?

Linux-Kongress 2002
9th International Linux System Technology Conference
September 4-6, 2002 in Cologne, Germany

Home | Events | Program | Abstracts | Tutorials | BoFs | Fees | Exhibition | Location | Accommodations | Keysigning Party | Sponsors | Supporters | Reports and Photos | Papers and Slides | Call for Papers

Papers

The following papers will be presented at the Linux-Kongress on Thursday, September 5 and Friday, September 6. All talks are in English. (The original Call for Papers.)

Linux and Security by Olaf Kirch Thursday 11:30

Dealing with security in an open source environment is very different from what you do in a closed source project. Using examples of security vulnerabilities and enhancements of the past couple of years, this talk will discuss the advantages and disadvantages of open source when it comes to implementing and enforcing security, and dealing with vulnerabilities.

Of course, the central focus will be on successes (and failures) of various projects and applications used on Linux, but I will also cover a few examples of closed source projects I encountered.

Finally, I will also discuss some strategies for dealing with security vulnerabilities, managing the publicity resulting from them, and the politics sometimes involved in this.

About the author:

The author got hooked on Linux around the time 0.96c was released, despite having to sell his Atari and buy a huge shoe-box shaped thing containing an Intel processor, an ISA bus, and several cards that would act strangely when inserted into the wrong ISA slot. He never looked back, though.

He's the author of the Linux Network Administrator's Guide, and wrote large parts of the Linux NFS implementation. Olaf got involved in Linux security in 1995, and has been ever since. He was Security Officer while working for LST and Caldera for 5 1/2 years, and recently joined SuSE, where he is involved in the security team.

WINE - The Windows Emulator by Marcus Meissner Thursday 11:30

WINE is one of the older software projects in the Linux world. Started in 1993 it is still going strong and, unfortunately, still not finished.

Started as a Windows 3.1 Emulation at that time it evolved over time into a full blown replacement of a 16 and 32 bit windows system environment, be it Windows 95, 98, NT 3.51, NT 4, 2000, ME, or even XP.

WINE itself is not a full emulator like the name suggests, but an emulation and reimplementation of the Windows core libraries (DLLs). It also provides a runtime environment, with registry, filesystem emulation and .INI file handling.

Standard Windows binaries and libraries are loaded into the UNIX address space, relocations and imports applied and the machine code directly executed.

While the latter does makes windows applications run at the same speed as under Windows, the emulation of the underlying libraries makes for some loss of speed.

The graphics driver do not directly interface with the graphicscard but are implemented on top of the X11 libraries. While this might lead to a small reduction in speed it allows full integration into the normal UNIX desktop, be it KDE or GNOME.

On the filesystem side, you do not need a Windows partition nor a harddisk image, WINE operates using the UNIX filesystem API, with the drives being specified by a configfile.

While WINE can use Windows native DLLs, the goal of the developers is to provide a MicroSoft free emulation by reimplementing all the required DLLs.

In the last few years companies have used WINE to port applications and are even basing their whole business on WINE. This lead to acceleration but also to rather long license flamewars and several license changes over the time.

The talk will give an introduction (both technical and historical) into the WINE project and also give a brief view into the license debate.

Marcus Meissner

About the author:

Marcus Meissner has started working with Linux in 1992, and begun involving himself with the WINE project in 1994. He studied computer science at the university of Erlangen and finished it with diploma in 1997. After doing his civil duty he worked for Caldera Systems in Erlangen as a senior developer between 1999 and 2002 and is now working for the SuSE Linux AG in Nuernberg.

In his spare time he still works too much with computers, but also likes doing inline skating and long walks across his hometown.

Related links:

Adding Multipathing Capabilities to LVM by Stefan Bader Thursday 12:15

When integrating Linux hosts into Storage Area Networks (SANs), the multipathing challenge, which has been rather academic in SCSI, becomes real. On the one hand due to network and host adapter failover reasons multiple SAN ports exist on the host side, and on the other hand modern SAN capable storage devices connect to the SAN via multiple device ports, which additionally results in improved bandwidth.

Various approaches exist to implement a solution in Linux, e.g. patches to MD, or the SCSI mid-level code, concurring with approaches deploying the volume management system EVMS. We have chosen to enhance LVM's grouping and dispatching services to be capable of managing device path groups beyond device groups and present a solution that brings failover and load balancing capabilities to the SCSI (and o ther attachment) stacks, only being based on LVM infrastructure.

About the author:

Stefan Bader received a Diploma in Computer Science in 1994. He joined IBM as a consultant for AIX Systems Management and since 2001 is working on the mainframe port of Linux in the Boeblingen Development Labs with a focus on Storage Networking Solutions.

Open Clustering Framework by Lars Marowsky-Brée Thursday 14:30

The Open Clustering Framework is a standarization effort to unify the current projects underway with regard to clustering on the Linux platform with a common component model, common APIs and at least one Open Source implementation. The initial focus is on High Availability Clustering and Linux, but this is not a long-term or inherent limitation.

The talk will outline the rationale behind this project and the urgent need for such a standard, the current status -- affiliation with the Free Standards Group, current drafts under discussion -- and of course also provide a glance into the future.

Integrating Sound and Multi-Media with X by Leon Shiman Thursday 12:15

The goal of this talk is to demonstrate and discuss a new solution to the long-standing problem of integrating sound and multi-media with the X Window System, under a common standard, in a common code release, and under the same "X" license. The project we will describe is known under the acronym "MAS", and is open to public view at www.MediaApplicationServer.net. "MAS" has been developed with the collaboration and support of the Audio Task Force of X.Org, the X Window System Standards Group, as a new standard technology to be publicly released as official, integrated, basic, X Technology. The first public integrated release is targetted for late 2002 or early 2003.

The paper will include topics from the following:

  • Performance data
  • MAS Scheduler Algorithms
  • MAS MasterClock interface to platform time and timing
  • Synchronizing Keyboard, Display, and Sound using the X MAS-Extension
  • XProtocol messaging using the MAS X-Device
  • Dynamic network latency management
  • Using the RTP Standard to support MAS Protocol for WAN and LAN
  • MAS wrappers for clients and plug-in devices
  • Using "ANX", the Audio Nexus
  • The MAS Media Controller
  • Accessibility tools

About the author:

PhD, MIT, Department of Mathematics.Strong interest in formal modelling. Formerly at MIT, the Freie Universitaet Berlin, and Whitehead Institute for Biomedical Research at MIT, as Director of Computing. Board of Directors, X.Org. Founder of Shiman Associates Inc (SAI), group consultancy for software architecture and development, specializing in X-based applications on Unix and Linux; Developers of "X"-licensed Media Application Server, "MAS"(TM) for X.Org, and a Web-based data and document manager "The Alexandrian Authority"(TM). Committed to strong, stable, standards-based, open-source software

Related links:

Load-Balancing HA Clusters with No Single Point of Failure by Fábio Olivé Leite Thursday 15:15

This paper will present the work of the author towards obtaining a fully distributed, load balancing, high availability cluster with no single point of failure. High availability, load balancing clusters are a very active area of Linux development, and there are several efforts worldwide that aim to achieve such goals. Most of these efforts involve the concept of a redirector machine, that receives the client's connections and distributes them among the working nodes (a server farm) using several different distribution policies, and that sometimes also route the server's answers. This redirector is a single point of failure that can render the whole cluster useless if it fails.

This work presents a new model for load balancing clusters that completely eliminates the need for a redirector, where all nodes are equal and each decides, using a distributed heuristic, whether it is the one that should accept a new connection. The key aspects here are: making sure all connections can reach all servers, and that exactly one server decides it should take an incoming connection.

There are at least two other known attempts at achieving this goal, but both are based on slicing the connection space based on the client addresses and distributing different slices to different servers. This not only does not ensure proper load balancing, but also leads to entire network address ranges being unserved should a server fail and the slice not be taken by another server. These attempts also cause the servers to loose their network identity, as they should all assume the same physical and network address, which makes remote administration impossible.

The author has developed a model for such type of clustering in which servers do not loose their network identity (remote administration is possible), the servers in the farm can be directly connected to the backbone (no redirection), load balancing can be done effectively and crashed servers affect only their own established connections. It involves some ARP magic, unicast and multicast confusion and weird modules for IP Tables. The author has a working prototype missing only one module from complete reference implementation. The paper will present the model, its goals, the techniques involved, the modules to achieve the goals and some practical tests. This paper is being presented to the community in search of validation and criticism, as the author has failed to find any gotchas in the approach taken.

This research is being conducted in the development laboratories of Conectiva S.A., in Curitiba, Brazil.

Fabio Olive Leite

About the author:

Fábio Olivé Leite is finishing his MSc in Fault Tolerance, has a BSc [olive] degree in Computer Science and a Technician degree in Industrial Electronics. He has experience as a software developer in Linux High Availability projects, as a University Professor in subjects such as Computer Architecture, Operating Systems and Parallel Processing, as a Network Administrator and lately some experience in embedded applications. His areas of expertise include operating systems development, distributed systems and reliable communication. He has programming skills in C, Python, Perl, Bourne/Korn shell scripting and Assembly Language. Fábio coordinates the Linux Users Group of his home city; his latest lectures were given at the "8th International Linux Kongress" and at "Unix en High Availability (Voorjaarsconferentie)" in the Netherlands, and also at the "2nd Testing and Fault Tolerance Workshop" in Curitiba, Brazil.

The Linux DVB API by Marcus and Ralph Metzler Thursday 14:30

The paper will cover the latest development in the DVB API for linux which started as a joint project of Nokia and Convergence for a Linux kernel API that provides a convenient interface to DVB PCI cards in particular and DVB hardware in general.

We will start with a short introduction to the DVB standard concentrating on the technical details that are most relevant for the construction of a useful API. This includes details about the tuning and demuxing process of DVB-S, DVB-T and DVB-C signals, information about the incoming transport streams (TS) and a short introduction to other relevant parts of the MPEG standard.

After this excursion we will know enough to understand what is needed in a kernel driver in order to provide the application programmer with the necessary functions to develop a DVB application that can handle all the tasks that are required by the user to watch television and use the other services provided by the broadcasters. Including for example such things as EPG, MHP and internet via satellite. Leading us to next part of the presentation which will go into the details of the kernel driver and the implementation as well as the definition of the API. With the goal that the audience will have an understanding of what is necessary to write a driver for a DVB hardware, we will explain the various parts of a driver implementation. This will include tuner, demuxer, section filters, MPEG decoder and network interface. Depending on the infrastructure it may also be possible to give a demonstration of the working API, if not of actual DVB reception than of some of the playback and demuxing interfaces.

Ralph Metzler Marcus Metzler

About the authors:

Marcus and Ralph Metzler both got their Ph.D. in physics from the University of Cologne. As a hobby they started to write drivers for the Linux kernel for TV capture cards (bttv) and other hardware. After university first Ralph and than Marcus started working for Convergence developing Linux drivers for DVB, MPEG encoder and decoder cards. There they started their work on the Linux DVB API. Now they are working as freelance driver developers still participating on the DVB API work and developing Linux drivers for various hardware components with emphasis on TV and multimedia.

DRBD - Distributed Replicated Block Device by Philipp Reisner Thursday 16:30

Introduction

High availability is a hot topic for service companies which offer their services via electronic networks. As Linux is in a position to gain a market share in newly build systems, there is a lot of interest in HA solutions for Linux based systems.

Quite a number of conventional HA solutions are brought to Linux these days and most of them are based on a shared storage device.

DRBD, however, is a more Linux-like approach to the field. As Linux brought PC hardware into the server market, DRBD brings HA clustering to the PC hardware. High availability in storage is realized by replicating the storage via off-the-shelf networking equipment to a second machine.

Since prices for gigabit ethernet hardware have declined and since 10 GB ethernet has become the standard, currently available off-the-shelf hardware offers the required performance.

Basic problems and algorithms

In this abstract only the areas of interest are mentioned, the complete algorithms are described in the final paper:

In order to achieve shared-disk like semantics over a networking protocol, DRBD has to guarantee not to violate write-ordering constraints imposed by upper software layers like journaling-file-systems.

In the event of a cluster restart, the nodes have to find the node with the up-to-date data (or the fact that all nodes are up-to-date).

Background resynchronization in case of a node joining a degraded cluster.

New requirements in DRBD 0.7

Quicker resynchronization. If no bitmap of out-of-date blocks is available, use hash values of blocks to speed up resynchronization.

In embedded applications and unmonitored installations, the remaining node must be able to continue to offer the service if a node is permanently damaged.

Decoupling of resynchronization from the node's role-assignment. Real-world use shows that this is often required and eases the interaction between DRBD and the cluster manager. This of course requires that DRBD offers a consistent view of the data even if the node's backing storage is the target of a resynchronization process.

Shared disk mode for use with openGFS. Although the block operation will support active/active configuration, it will turn out if it is usable without a common view of the cluster membership.

Conclusion

DRBD 0.6 proved its applicability for a number of purposes, mainly deployments in data-centers. Its replication performance was sufficient, but resynchronization was too slow. DRBD 0.7 will be applicable in embedded environments as well and will increase the possible storage size by speeding up resynchronization.

Philipp Reisner

About the author:

Graduation from the Vienna University of Technology in computer science in 2000.

Since November 2001 MD at LINBIT, a provider of professional Linux services with a focus on high availability clustering.

Apart from DRBD, author of mergemem (a modification of Linux's memory management system)

Related links:

The OpenMosix Cluster by Moshe Bar Thursday 17:15

The openMosix Linux kernel extension turns networked computers into a SSI cluster. The openMosix Project is both Open Source and Open Project. The open nature of our project brings good ideas and contributions from our users. We share our plans, accept code contributions, and value outside suggestions. This openness accelerates the project development. Our port to IA-64 Linux has begun and will create a native High Performance Computing (HPC) platform for the IA-64.

openMosix is installed on each participating node of a LAN. Since all openMosix extensions are inside the kernel, applications automatically and transparently benefit from this distributed computing concept. There is no need to program those applications specifically for openMosix. The cluster behaves much as does a Symmetric Multi-Processor (SMP), but this solution scales to well over a thousand nodes which can each be SMPs. Once installed and booted, the openMosix nodes see each other in the cluster and start exchanging information about their load level and resource usage. Processes originating from any one node, if that node is too busy compared to others, can migrate to any other node, repeatedly, during their lives. openMosix continuously attempts to optimize the resource allocation.

The remainder of this paper discusses how this is done, what applications benefit the most and least, and what enhancements are planned to increase the number and type of applications that benefit.

About the author:

Moshe Bar is an operating systems kernel programmer, writer of Byte Magazine column Serving With Linux, author of numerous Linux books and university teacher. Next to that he is also the Chief Technical Officer of Qlusters, Inc., and is the Project Manager for openMosix.

Linux Traffic Control - Next Generation by Werner Almesberger Friday 09:30

Traffic control in the Linux kernel offers a large set of functions for classifying and scheduling network traffic. Unfortunately, properly configuring traffic control is complicated not only by sometimes obscure underlying theoretical concepts, but it is also made difficult by the rather scary "tc" configuration language used for this.

tcng aims to improve this situation. It defines a new, much more human-friendly configuration language, and provides a compiler that translates that to a set of lower-level languages, among them C and "tc". tcng also comes with a simulator that uses the actual kernel code to simulate the traffic control subsystem.

Werner Almesberger

About the author:

Werner Almesberger got hooked on Linux in the days of the 0.12 kernel, when studing computer science at ETH Zurich, and he has been hacking the kernel and related infrastructure components ever since, both as a recreational activity, and as part of his work, first while doing a PhD in communications at EPF Lausanne, and later also in industry. Being a true Linux devout, he moved closer to the home of the penguins in 2002, and now lives in Buenos Aires, Argentina.

Contributions to Linux include the LILO boot loader, the initial RAM disk (initrd), the MS-DOS file system, some of the Linux port to the Psion S5 PDA, and much of the ATM code.

Related links:

Voxilla Phone by Michael Finkenzeller and Andreas Kirstädter Friday 09:30

Pushed by flat-rate Internet access and PSTN gateways IP Telephony (VoIP) becomes a more appealing alternative to "normal" telephony. Nevertheless easy-to-use stand-alone and affordable devices which provide the look and feel of common telephones are still rare.

To gain more experiences with the protocols involved and their interworking with IP quality of service and routing we decided to set up a flexible platform for VoIP experiments: As the first step a prototype of a stand-alone IP phone called "Voxilla-Internet-Phone" (VIP) with Ethernet and wireless-LAN interfaces was designed and integrated during a diploma thesis. The underlying hardware consists of a single-board PC (80468, 133 MHz, 32 MB RAM) with a PCMCIA module supporting the network interface card and a flash memory card serving as the "hard disk" of the system (all together fitting nicely into the case of a plain old telefone).

We didn't regret the decision to use Linux (in the form of "tomsrtbt", a very small distribution that fits on a single floppy) as the operating system: After some initial problems with the sound system and the boot process from the flash card the system integration went smoothly. For the VoIP application the software from the OpenH323 project was extended with some middleware. A user interface to meet the needs of a stand-alone phone with a four line LCD and a 12 button keyboard was added. By definition, the stack of the OpenH323 project conforms to the ITU recommendation H.323. To communicate with clients that use IETF's Session-Initiation-Protocol (SIP) it is possible to switch between H.323's signaling protocol H.245 and SIP.

One of our next steps will be to use VIP in larger wireless-LAN scenarios to study roaming and hand- over processes between different cells and the resulting implications on the achievable quality of the VoIP communications. Our presentation not only describes the system architecture but also discusses the lessons learned during system set up and integration.

Michael Finkenzeller Andreas Kirstaedter

About the authors:

Michael Finkenzeller received his Dipl.-Ing. Univ. degree in Electrical Engineering and Information Technology at the Technische Universität München (TUM), Germany, in 2000.

Since then he is working as Research Scientist for Siemens Corporate Technology in the field Networks and Multimedia Communication. In a first project he was involved in component development and setup of a testbed for Policy-Based-Networking and Quality-of-Service. At present his interests are on the area of Peer-To-Peer and ad hoc networking and the practical evaluation of these concepts in a testbed.

Andreas Kirstädter received the Dipl.-Ing., Dipl.-Wirtsch.-Ing., and Dr.-Ing degrees in Electrical Engineering and Economics from Munich University of Technology (TUM), Germany, in 1990, 1992, and 1997, respectively. From 1991 to 1997 he was with the Institute for Communication Networks at Munich University of Technology, where he worked on research topics in the area of high-speed networking, WDM networks, simulation, analytical modelling and high-speed hardware design. In 1997 he joined the "Networks and Multimedia Communications" department at Siemens Corporate Technology in Munich where he is responsible for the "High-Speed IP Networks" team. His current research interests include the hardware implementation of communication protocols, Internet quality of service concepts, MPLS networks, IP resilience, and mobility and multimedia concepts for the Internet. Since summer 2000 he gives a lecture on "Simulation of Communication Networks" in the framework of the Master of Science in Communication Engineering Program at Munich University of Technology.

RSVP-TE daemon for DiffServ over MPLS under Linux by Pim Van Heuven Friday 10:15

This project supports the important Internet Engineering Task Force (IETF) standards for the set-up of MultiProtocol Label Switching (MPLS, RFC3031) tunnels with DiffServ support (DS, RFC2475) under Linux by using the ReSource reserVation Protocol (RSVP, RFC2205). These tunnels support scalable Quality of Service (QoS) in IP networks. While the project might be very specialized for the typical Linux user, it is used by ISPs, network operators and research institutes all over the world. For some of them this project is a "killer application" making them look at Linux for the first time.

The project reuses the code of a few existing projects (some of them abandoned) and created a useable RSVP MPLS daemon for Linux. The project deliberately uses an open, bazaar model with frequent releases to leverage on the ever-growing user base.

The talk will address briefly the theoretical basis of MPLS, RSVP and DiffServ. It will elaborate on the architecture and used components both in user and kernel space (netfilter, netlink, scheduling and queueing, MPLS). It will address the trade-off between adding functionality to the kernel and working around existing limitations of the Linux kernel with respect to the project. It will also mention the relationship and experience with other projects and the user base.

The talk concludes by investigating the pros and cons of open sourcing a research project like this that is traditionally developed in house or in a closed group. The comparison is based on a use case: the public demonstration of MPLS technology as proof-of-concept. We compare the close model used in the Ithaci project with the open source project code that was used in the Tequila demo. The author was responsible for the MPLS signaling software in both demos.

Pim van Heuven Steven Van den Berghe Jan Coppens Piet Demeester

About the authors:

Pim Van Heuven graduated in Computer Science at the Ghent University in 1998. In July 1998, he joined the INTEC Broadband Communications Networks (IBCN) Group where he is preparing a Ph.D. His research interests include mainly the area of Quality of Service, Traffic Engineering and Rerouting in IP. He is currently active in the IST Tequila project, before he worked on the ACTS Ithaci project. He has been a Linux enthusiast since 1996. In 2001 he open-sourced the DiffServ over MPLS for Linux project he had been working on. He published several papers on MPLS and rerouting techniques in IP and WDM networks.

Steven Van den Berghe joined IBCN in July 1999. He is focusing on measurement-based Traffic Engineering in a DiffServ/MPLS/MultiPath environment. He is also active in the IST Tequila project. He knows his way around in the Linux MPLS kernel stack and published, next to several papers, an Internet Draft on the requirements for measurement architectures for use in Traffic Engineered IP Networks.

Jan Coppens joined the IBCN group in 2001. He specializes in (Linux) Traffic Control mechanisms and is responsible for the Linux part of a generic adaptation layer (GAL), an abstraction layer for different router platforms, in the Tequila project.

Piet Demeester has been active in the research on broadband communication net works since 1992. He published over 400 papers and has been member of numerous technical program committees. His current interests include optical circuit and packet switching, network resilience, Quality of Service in IP based networks, IP based mobile and wireless networks, peer-to-peer and active networking, grid computing, network and service management.

Related links:

ISDN4Linux, CAPI4Linux, CAPI4Hisax and other cute acronyms by Kai Germaschewski Friday 10:15

During the 2.5 development cycle, the ISDN subsystem in the Linux kernel will undergo major changes. This paper gives an outline of the layers of the legacy ISDN code, called ISDN4Linux. The core part of that code, called the ISDN link layer, is a multi/demultiplexing layer which coordinates data exchange between hardware drivers on one side and applications using ISDN service on the other side.

We will show how replacing this layer with a CAPI based solution, called CAPI4Linux, benefits both hardware drivers and applications. CAPI is an open standard ("Common ISDN Application Programming Interface"), which provides a standard interface to using ISDN communication services independently of the actual hardware and drivers used. In contrast to the old ad-hoc interface which was extended bit by bit to match growing requirements, CAPI is a well known and documented interface. Porting user space applications from and to other OS's is simplified a lot using a common API. On the driver side, an obvious advantage is accomplished for so-called active ISDN cards, which implement the CAPI interface in firmware. They can now be interfaced directly to the kernel CAPI layer without being translated back and forth from the old ISDN link layer API.

However, an overwhelming market share is owned by so-called passive ISDN adapters. They do not come with a processor of their own but expect the host processor to handle the ISDN protocols, call control and the like. Linux has a driver which handles almost all existing passive cards and implements the necessary protocol layers. Currently this driver ("hisax") interfaces to the old ISDN4Linux API, rendering it unusable with the CAPI4Linux subsystem. We describe the conversion of this driver to a open source CAPI compliant driver (the project goes by "CAPI4HiSax"), which is an essential building block on the way towards the new CAPI based ISDN layer.

Kai Germaschewski

About the author:

Kai Germaschewski obtained his Ph.D in plasma physics from the University of Duesseldorf in 2001. After a year of research at the Ruhr-University Bochum, he is currently working on massively parallel numerical simulations as a postdoctoral scholar at the University of Iowa, USA.

His first serious contact with Linux happened during his time as a research assistent at the Institute for Theoretical Physics, Duesseldorf, where Linux workstations were taking over tasks of typical UNIX workstations. Not much later, he got an ISDN line at home, which lead him to investigate the status of the Linux ISDN subsystem. Fascinated by the opportunity to see how an actual ISDN stack works and even the possibility to change and adapt it (thanks, open source) he quickly became familiar with the world of ISDN. One of his early projects was a small extension which allows to setup call diversion by means of running a small program on your computer. Actually initially driven by the lack of a suitable interface for that kind of extension, he started developing a CAPI interface for the hisax driver, which is now being merged in the 2.5 kernel.

With time passing, he became aware of the difficulties in communication between the ISDN developers and Linus Torvalds and started syncing pieces with Linus' official kernels and eventually became maintainer for the ISDN subsystem.

Apart from his interest in ISDN, the author sometimes gets distracted into other areas of the Linux kernel, for example currently into improving the 2.5 developer kernel's build system.

Related links:

Bridgewalling - Using netfilter in bridge mode by Ralf Spenneberg Friday 11:30

Firewalling using packet filters is usually done in router mode. The packet filtering software decides wether the packet will be forwarded/routed or not.

Installing a firewall in an existing network architecture often requires the modification of networks and ip addresses. If the firewall device functions as a bridge no change is needed. The firewall is just placed in between the machines to be firewalled. Additionally the firewall is invisible on IP-layer.

Unfortunately not very much documentation exists covering the setup of a bridging firewall on Linux although Linux offers a very advanced stateful packet filtering machinery (netfilter).

This talk will start with a comparison of routing and bridging. I will explain the different approaches to decide wether a packet will be forwarded.

Then an introduction to bridging code will be given. I will cover the ideas behind the Linux bridging code and its interaction with the netfilter code. The usage of the different netfilter tables and chains regarding the bridging code will be covered. Once the technical aspects of bridging are covered a bridging firewall will be configured and demonstrated. This will include the demonstration of the application of the bridging patch and the usage of the bridge utility.

The talk will conclude giving some examples of future uses of bridge firewalls.

The level is intermediate. The audience is expected to know netfilter/iptables basics.

Ralf Spenneberg

About the author:

The Author has used Linux for the last 8 years. Since 1996 he worked as a scientific assistant at the Center for Molecular Biology of Inflammation at the University of Münster. There he worked on several bio-informatics projects and was the head of the network administration and security group. The last 3.5 years he worked as a freelancer in the Linux/UNIX field. Most of the time he provides Linux/UNIX training. His specialty is network administration and security (firewalling, VPNs, intrusion detection). He has developed several training classes used by Red Hat and GfN.

Bluetooth Enabled Embedded Linux by Yang Xiaoyong (David) Friday 11:30

With the advent of an astronomical growth in the mobile communications industry, the mobile voice-centric, data-centric and general mobile computing markets will converge to create an all-in-one wireless, hand-held device that will offer the consumer access to vast global information repositories with unparalleled connectivity and mobility.

In order to be a key viable player in this new technology sector, it is imperative for companies to develop a product, which couples the state-of-the-art hardware together with a stable, low-cost operating system. With the above focus, this project investigates the feasibility of using a version of embedded Linux (ARM Linux) on an Intel 206MHz StrongARM based system, the Assabet evaluation board. Important aspects of the project involved the setting up of a windowing system on the embedded device by cross-compiling Microwindows running using the ARM Linux kernel, the configuration of FLNX to function on top of Microwindows which would allow numerous FLTK based programs to function in the future, the configuration of the file system on the Ramdisk residing in the Assabet evaluation board and the modification of the touchscreen driver to ensure proper functionality of the input process. A web browser and support for Ethernet were also included.

The multitude of advantages of using embedded Linux as an operating system, such as its open source nature, zero licensing cost, robust and stable architecture and flexible networking capabilities, make it a highly viable alternative to competing products such as Microsoft PocketPC and Palm OS. How ever, as embedded Linux is generally a new area, the lack of documentation and incompatibilities between different versions of files/drivers were some of the barriers that exacerbated the difficulty of the project.

The current scope of the project provides the main foundation for future developments that may involve the development of a full-fledged graphical user interface, audio and video streaming and the Personal Information Management applications. In the later stage of the project the enabling wireless technologies like bluetooth and wireless LAN on Linux platform are also explored. Some in depth analysis on the current Linux based Bluetooth stack including BlueZ and Openbt also presented.

David Yang

About the author:

Linux lover, developer of embedded Linux and Bluetooth protocol stack on Linux, and promoter for the open sourced software/hardware.

The Future of Linux Packet Filtering by Harald Welte Friday 12:15

The Linux 2.4.x provided a complete rewrite of the firewalling subsystem, called netfilter/iptables. It was a major improvement about the previous ipchains subsystem. The major advantages are it's modularity and flexibility.

However, as wity any project, as soon as you are sort-of finished, you become aware of potential improvements and extensions.

The firewalling subsystem within the Linux kernel will undergo some fundamental design changes during the 2.5.x development kernel series.

Some of the changes from 2.4.x which are currently being developed:

  • Have an independent pkt_tables subsystem, as a layer3 independent replacement for iptables, ip6tables and arptables. This will allow adding support for other layer 3 protocols very easily
  • Move all kernel/userspace communication to netlink sockets. There will be a generic nfnetlink layer, with pkttnetlink (for managing pkt_tables) and ctnetlink (for manipulating the connection tracking database from userspace).
  • Change the internal data structure of an ip_table to a linked list of chains, which in turn are a linked lists out of rules, which are linked lists out of matches + targets. This way it is way more performant in the case of dynamic firewalling rulesets.
  • Provide a generic high-level API to userspace applications for manipulation of packet filtering rules. This will enable generic GUI's, which need no changes in case new matches or targets are added.

Optionally, the netfilter core team is planning to have support for connection tracking state replication - something necessarry for failover of stateful firewalls.

The talk assumes prior knowledge about the netfilter/iptables architecture.

About the author:

Harald Welte is one of the five netfilter core team members, and the current Linux 2.4.x firewalling maintainer.

His main interest in computing has always been networking. In the few time left besides netfilter/iptables related work, he's writing obscure documents like the UUCP over SSL HOWTO. Other kernel-related projects he has been contributing to are user mode linux and the international (crypto) kernel patch.

In the past he has been working as an independent IT Consultant working on closed-source projects for various companies ranging from banks to manufacturers of networking gear. During the year 2001 he was living in Curitiba (Brazil), where he got sponsored for his Linux related work by Conectiva Inc.

Starting with February 2002, Harald has been contracted part-time by Astaro AG, who are sponsoring him for parts of his current netfilter/iptables work.

Harald is living in Erlangen, Germany.

Related links:

Implementing a User Mode Linux with Minimal Changes from Original Kernel by Hans-Jörg Höxer, Kerstin Buchacker and Volkmar Sieh Friday 12:15

Our team is implementing a User-Mode-Linux with two main targets in mind. The first one is, that the changes needed to port an original Linux kernel to our User-Mode environment should be minimal. The second is, that it should be possible to make the virtual hardware the User-Mode-Linux is running on fail at will. We plan to use this capability to test how well fault-tolerant systems such as the Linux Virtual Server described at www.linuxvirtualserver.org, can handle failures of hardware components.

The first goal, minimal changes from original kernel, is the main topic of this paper. The advantages are clear. The fewer lines of code we touch, the fewer errors we can introduce into the kernel and the less effort is needed to port the kernel to UMLinux. This speeds up adapting UMLinux to new kernel releases.

The parts of kernel code that need to be changed, are those directly interacting with the hardware. Basically these are all lines containing inline assembler instructions. Inline assembler is used in three main areas in the kernel: for interrupt and exception handling, to access functions of the memory management unit and for communication with devices via inb/outb-instructions. Our approach is to replace these lines of assembler code with functions, which have the same effect as the original assembler instructions.

In UMLinux, signals replace interrupts/exceptions. Consequently, signal handler functions replace interrupt/exception handlers. The signal handler functions in UMLinux do not actually contain code to handle the interrupt. The signal handler function modifies the stack so the original kernel's interrupt handler can work with it and then calls that handler. Upon return of the handler, the modifications are undone by a function implementing the iret assembler instruction and execution of the User-Mode-Kernel continues.

Assembler instructions concerning the memory management unit are those, for example, which modify the page-directory base register or segment registers. We have implemented functions based on mmap/munmap to replace these instructions and simulate the memory management unit.

Communication with devices is mainly done via interrupts and inb/outb assembler instructions. In UMLinux we have implemented functions to replace the inb/outb instructions. These functions implement the UMLinux virtual hardware devices, such as real time clock, APIC, IDE-controller, keyboard-controller and VESA-graphics-controller. These virtual devices communicate with the UMLinux kernel just like real devices would communicate with the real kernel. Consequently we can use the device drivers of the original kernel in UMLinux, too. It is not our goal, to create a complete hardware simulation like Plex86. We just want to simulate enough of the hardware, to be able to use the original Linux device drivers.

Volkmar Sieh Hans-Joerg Hoexer Kerstin Buchacker

About the authors:

This paper was written by Hans-Jörg Höxer, Kerstin Buchacker and Volkmar Sieh. All have graduated in computer science from the University of Erlangen. K. Buchacker and V. Sieh also hold a PhD in computer science. All authors are part of the team working on the UMLinux project.

Related links:

Linux USB - Past, Present and Future by Brad Hards Friday 14:00

The major focus for many Linux developers has been in those parts of the kernel that support server type applications. However a rapidly expanding area of Linux development has been in the desktop applications area. A key aspect of this has been in the use of USB peripherals - especially keyboards, mice and mass storage devices. The hot-plug nature of USB devices has caused some of the underlying assumptions about Unix type devices to be re-assessed, and new or modified approaches to be adopted.

Linux USB development started in 1997, and has had a somewhat tortured history, with splintered development and several re-writes. It captures many of the issues associated with open source development - difficulty in obtaining device programming information, differences in opinion between developers concerning architecture, devices that are "almost but not quite" compliant to published specifications, and the difficulty in finding enough time to get all that coding, testing and documentation done.

The introduction of USB 2.0, with significantly higher speeds, has required some new drivers, but has also identified speed and efficiency problems with some of the existing drivers. Future enhancements to include new drivers, and improve existing ones, seem likely. As Linux emerges to become an important part of the desktop market, more manufacturer support is expected.

This talk will provide a brief overview of how Linux USB support got to where it is today, what the current capabilities of Linux USB are, and likely directions for future support. The talk will also cover how key elements of Linux USB work, with some digression into the Linux Input layer subsystem, since most users experience USB through USB keyboards, mice and joysticks, which are jointly supported by USB and Input subsystems. Likely changes to the way in which user space applications (such as the X Windowing System and games) are managed will also be overviewed.

The talk will also cover how Linux Hotplug works, and how it can be used to implement "policy" decisions for individual systems, without needing to implement changes to the kernel.

Brad Hards

About the author:

Brad Hards is the technical director of Sigma Bravo Pty Limited, a small engineering services company based in Canberra, Australia.

He has been a Linux user since 1993, when he download Slackware, one floppy disk at a time, over a modem link.

Brad Hards is a current kernel maintainer (USB CDC Ethernet class driver) and has written documentation for several open source activities, including the Linux USB guide. He ran a BoF at linux.conf.au 2001, and presented a paper on Linux USB at linux.conf.au 2002.

Related links:

Partitioning a Server with NSA SE Linux by Russell Coker Friday 14:00

The requirement to purchase multiple machines is often driven by the need to have multiple administrators with root access who do not trust each other.

Having large numbers of expensive under-utilised servers with the associated management costs is not ideal.

I will describe my solution to this problem using SE Linux to partition a server such that the "root" users can't access each other's files, kill each other's processes, change passwords for each other's users, etc.

DOS attacks will still be possible by excessive use of memory and CPU time, but apart from that all the benefits of separate hardware will be provided.

About the author:

I have been a Debian developer for several years.

My paid work is usually running ISPs although I am currently working on Linux appliances for Internet use.

In the past I have worked as a C/C++ programmer.

I used to spend a lot of time writing benchmark programs, but now that Linux is reliable enough that I can't kill it, and hardware is cheap and fast enough that I don't usually have to wait excessively I have been less interested in that area.

Now I believe that security is an area where improvement is needed.

Last year at OLS I spent some time talking to Peter A. Loscocco, and became convinced of the value of SE Linux. Now I plan to install it on my servers as soon as I get it packaged for Debian...

Buried alive in patches. 6 months of picking up the pieces of the Linux 2.5 kernel by Dave Jones Friday 14:45

This talk covers the current state of the 2.5 Linux kernel, what has happened in the last year, and what is likely to happen next. Topics covered include experiences with forward porting fixes from 2.4, and introduces several tools that make life easier whilst syncing patches between multiple trees. Another topic covered will be the ease/difficulty in feeding patches back into Linus Torvalds main 2.5 branch, including some brief discussion of the advantages and disadvantages of Linus' usage of bitkeeper.

Due to the 'up to the minute' nature of this talk, further details will unfold over the coming months.

Dave Jones

About the author:

After nearly a decade of various computing jobs from data entry clerk to Amiga games programmer at a failed startup, and facing much pressure to "get a real job", I went to university to find out what to do with the rest of my life. I never really figured it out, but discovered Linux somewhere along the way, and have been contributing to a diverse range of projects since, from oprofile to helping out the x86-64 kernel port.

Building LSB Compliant Applications by Christopher Yeoh Friday 14:45

The goal of the Linux Standard Base (LSB) is to develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant Linux system. In July the 1.2 version of the Linux Standard Base specification is to be released and the the certification program associated with it will begin. This program will initially cover the certification of runtime environments and applications designed to be run on LSB compliant runtimes.

This talk will cover what is involved in building an LSB compliant application. It will start by covering the specifications referred to by the LSB specification, which developers should be aware of.

To make it easier to build a compliant application, LSB build environments are in development. There are currently two tools, lsbcc and lsbdev available. They take different approaches to building an application and the best one to use depends on the existing build infrastructure and the complexity of the application.

Test suites have been developed to test conformance of applications to the specification. The talk will cover what developers can expect the test programs to detect, and what is not covered. The Linux Standard Base organisation has also been developing sample implementations of the specification. The sample implementations attempt to provide a runtime environment which fulfills all the requirements of the specification with a minimum of extra functionality. In addition to acting as an example to people developing LSB runtimes the sample implementation is also useful as a testing ground for application developers. It can be used to help verify that they are not dependent on features outside of the specification.

The talk will also briefly describe what is required to obtain and maintain formal LSB certification for an application.

Christopher Yeoh

About the author:

Christopher Yeoh is an employee of the IBM Linux Technology Center, working at OzLabs in Canberra, Australia. For the last couple of years he has be en working on various aspects of the Linux Standard Base ranging from specification writing to test suite development. He is the technical lead for the LSB build environment.

Related links:


Comments or Questions? Mail to contact@linux-kongress.org Last change: 2005-09-17