DOCSLIB.ORG

Linux Loadable Kernel Module HOWTO

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Linux Loadable Kernel Module HOWTO Linux Loadable Kernel Module HOWTO Bryan Henderson 2006−09−24 Revision History Revision v1.09 2006−09−24 Revised by: bjh Fix typos. Revision v1.08 2006−03−03 Revised by: bjh Add copyright information. Revision v1.07 2005−07−20 Revised by: bjh Add some 2.6 info and disclaimers. Update references to Linux Device Drivers book, Linux Kernel Module Programming Guide. Revision v1.06 2005−01−12 Revised by: bjh Cover Linux 2.6 briefly. Update hello.c and reference to Lkmpg. Add information about perils of unloading. Mention dmesg as way to see kernel messages. Revision v1.05 2004−01−05 Revised by: bjh Add information on module.h and −DMODULE. Fix tldb.org to tldp.org. Add information on kallsyms. Revision v1.04 2003−10−10 Revised by: bjh Fix typo: AHA154x should be AHA152x Add information on what module names the kernel module loader calls for. Add information on what an LKM does when you first load it. Add information on loop module. Change linuxdoc.org to tldp.org. Revision v1.03 2003−07−03 Revised by: bjh Update on kernels that don't load into vmalloc space. Add explanation of "deleted" state of an LKM. Explain GPLONLY. Revision v1.02 2002−05−21 Revised by: bjh Correct explanation of symbol versioning. Correct author of Linux Device Drivers. Add info about memory allocation penalty of LKM vs bound−in. Add LKM−to−LKM symbol matching requirement. Add open source licensing issue in LKM symbol resolution. Add SMP symbol versioning info. Revision v1.01 2001−08−18 Revised by: bjh Add material on various features created in the last few years: kernel module loader, ksymoops symbols, kernel−version−dependent LKM file location. Revision v1.00 2001−06−14 Revised by: bjh Initial release. This is the HOWTO for Linux loadable kernel modules (LKMs). It explains what they are and how to use and create them. It also includes documentation of parameters and other details of use of some particular modules. Linux Loadable Kernel Module HOWTO Table of Contents 1. Preface..............................................................................................................................................................1 2. Introduction to Linux Loadable Kernel Modules........................................................................................2 2.1. Terminology......................................................................................................................................2 2.2. History of Loadable Kernel Modules...............................................................................................2 2.3. The Case For Loadable Kernel Modules..........................................................................................3 2.4. What LKMs Can't Do.......................................................................................................................3 2.5. What LKMs Are Used For................................................................................................................3 3. Making Loadable Kernel Modules................................................................................................................5 4. LKM Utilities...................................................................................................................................................6 5. How To Insert And Remove LKMs..............................................................................................................7 5.1. Could Not Find Kernel Version........................................................................................................8 5.2. What Happens When An LKM Loads..............................................................................................9 5.3. Intelligent Loading Of LKMs − Modprobe......................................................................................9 5.4. Automatic LKM Loading and Unloading.......................................................................................10 5.4.1. Automatic Loading................................................................................................................10 5.4.2. Automatic Unloading − Autoclean.......................................................................................12 5.5. /proc/modules..................................................................................................................................12 5.6. Where Are My LKM Files On My System?...................................................................................14 6. Unresolved Symbols......................................................................................................................................15 6.1. Some LKMs Prerequire Other LKMs.............................................................................................15 6.2. An LKM Must Match The Base Kernel.........................................................................................15 6.3. If You Run Multiple Kernels..........................................................................................................16 6.4. SMP symbols..................................................................................................................................17 6.5. You Are Not Licensed To Access The Symbol..............................................................................17 6.6. An LKM Must Match Prerequisite LKMs......................................................................................18 7. How To Boot Without A Disk Device Driver.............................................................................................19 8. About Module Parameters...........................................................................................................................20 9. Persistent Data..............................................................................................................................................21 10. Technical Details.........................................................................................................................................22 10.1. How They Work...........................................................................................................................22 10.2. The .modinfo Section....................................................................................................................23 10.3. The __ksymtab And .kstrtab Sections..........................................................................................23 10.4. Ksymoops Symbols......................................................................................................................23 10.5. Other Symbols..............................................................................................................................24 10.6. Debugging Symbols......................................................................................................................25 10.7. Memory Allocation For Loading..................................................................................................25 10.8. Linux internals..............................................................................................................................26 i Linux Loadable Kernel Module HOWTO Table of Contents 11. Writing Your Own Loadable Kernel Module..........................................................................................27 11.1. Simpler hello.c..............................................................................................................................27 11.2. Using the Kernel Build System....................................................................................................28 11.3. Rubini et al: Linux Device Drivers...............................................................................................29 11.4. Module Use Counts......................................................................................................................29 12. Differences Between Versions Of Linux...................................................................................................31 12.1. Linux 2.4 − Linux 2.6...................................................................................................................31 12.1.1. Linking Done In Kernel......................................................................................................31 12.1.2. No Module Busy Function..................................................................................................32 12.1.3. CONFIG_MODULE_UNLOAD........................................................................................32 12.1.4. Reference Counting.............................................................................................................32 13. Copyright Considerations With LKMs....................................................................................................33 14. Related Documentation..............................................................................................................................36 15. Individual Modules.....................................................................................................................................37 15.1. Executable Interpreters.................................................................................................................37 15.1.1. binfmt_aout: executable interpreter for a.out format..........................................................37 15.1.2. binfmt_elf: executable interpreter for ELF format..............................................................37
Load more

Recommended publications
  • A Practical UNIX Capability System
    A Practical UNIX Capability System Adam Langley <[email protected]> 22nd June 2005 ii Abstract This report seeks to document the development of a capability security system based on a Linux kernel and to follow through the implications of such a system. After defining terms, several other capability systems are discussed and found to be excellent, but to have too high a barrier to entry. This motivates the development of the above system. The capability system decomposes traditionally monolithic applications into a number of communicating actors, each of which is a separate process. Actors may only communicate using the capabilities given to them and so the impact of a vulnerability in a given actor can be reasoned about. This design pattern is demonstrated to be advantageous in terms of security, comprehensibility and mod- ularity and with an acceptable performance penality. From this, following through a few of the further avenues which present themselves is the two hours traffic of our stage. Acknowledgments I would like to thank my supervisor, Dr Kelly, for all the time he has put into cajoling and persuading me that the rest of the world might have a trick or two worth learning. Also, I’d like to thank Bryce Wilcox-O’Hearn for introducing me to capabilities many years ago. Contents 1 Introduction 1 2 Terms 3 2.1 POSIX ‘Capabilities’ . 3 2.2 Password Capabilities . 4 3 Motivations 7 3.1 Ambient Authority . 7 3.2 Confused Deputy . 8 3.3 Pervasive Testing . 8 3.4 Clear Auditing of Vulnerabilities . 9 3.5 Easy Configurability .
    [Show full text]
  • The Linux Kernel Module Programming Guide
    The Linux Kernel Module Programming Guide Peter Jay Salzman Michael Burian Ori Pomerantz Copyright © 2001 Peter Jay Salzman 2007−05−18 ver 2.6.4 The Linux Kernel Module Programming Guide is a free book; you may reproduce and/or modify it under the terms of the Open Software License, version 1.1. You can obtain a copy of this license at http://opensource.org/licenses/osl.php. This book is distributed in the hope it will be useful, but without any warranty, without even the implied warranty of merchantability or fitness for a particular purpose. The author encourages wide distribution of this book for personal or commercial use, provided the above copyright notice remains intact and the method adheres to the provisions of the Open Software License. In summary, you may copy and distribute this book free of charge or for a profit. No explicit permission is required from the author for reproduction of this book in any medium, physical or electronic. Derivative works and translations of this document must be placed under the Open Software License, and the original copyright notice must remain intact. If you have contributed new material to this book, you must make the material and source code available for your revisions. Please make revisions and updates available directly to the document maintainer, Peter Jay Salzman <[email protected]>. This will allow for the merging of updates and provide consistent revisions to the Linux community. If you publish or distribute this book commercially, donations, royalties, and/or printed copies are greatly appreciated by the author and the Linux Documentation Project (LDP).
    [Show full text]
  • Introduction to Debugging the Freebsd Kernel
    Introduction to Debugging the FreeBSD Kernel John H. Baldwin Yahoo!, Inc. Atlanta, GA 30327 [email protected], http://people.FreeBSD.org/˜jhb Abstract used either directly by the user or indirectly via other tools such as kgdb [3]. Just like every other piece of software, the The Kernel Debugging chapter of the FreeBSD kernel has bugs. Debugging a ker- FreeBSD Developer’s Handbook [4] covers nel is a bit different from debugging a user- several details already such as entering DDB, land program as there is nothing underneath configuring a system to save kernel crash the kernel to provide debugging facilities such dumps, and invoking kgdb on a crash dump. as ptrace() or procfs. This paper will give a This paper will not cover these topics. In- brief overview of some of the tools available stead, it will demonstrate some ways to use for investigating bugs in the FreeBSD kernel. FreeBSD’s kernel debugging tools to investi- It will cover the in-kernel debugger DDB and gate bugs. the external debugger kgdb which is used to perform post-mortem analysis on kernel crash dumps. 2 Kernel Crash Messages 1 Introduction The first debugging service the FreeBSD kernel provides is the messages the kernel prints on the console when the kernel crashes. When a userland application encounters a When the kernel encounters an invalid condi- bug the operating system provides services for tion (such as an assertion failure or a memory investigating the bug. For example, a kernel protection violation) it halts execution of the may save a copy of the a process’ memory current thread and enters a “panic” state also image on disk as a core dump.
    [Show full text]
  • Procedures to Build Crypto Libraries in Minix
    Created by Jinkai Gao (Syracuse University) Seed Document How to talk to inet server Note: this docment is fully tested only on Minix3.1.2a. In this document, we introduce a method to let user level program to talk to inet server. I. Problem with system call Recall the process of system call, refering to http://www.cis.syr.edu/~wedu/seed/Labs/Documentation/Minix3/System_call_sequence.pd f We can see the real system call happens in this function call: _syscall(FS, CHMOD, &m) This function executes ‘INT 80’ to trap into kernel. Look at the parameter it passs to kernel. ‘CHMOD’ is a macro which is merely the system call number. ‘FS’ is a macro which indicates the server which handles the chmod system call, in this case ‘FS’ is 1, which is the pid of file system server process. Now your might ask ‘why can we hard code the pid of the process? Won’t it change?’ Yes, normally the pid of process is unpredictable each time the system boots up. But for fs, pm, rs, init and other processes which is loaded from system image at the very beginning of booting time, it is not true. In minix, you can dump the content of system image by pressing ‘F3’, then dump the current running process table by pressing ‘F1’. What do you find? The first 12 entries in current process table is exactly the ones in system image with the same order. So the pids of these 12 processes will not change. Inet is different. It is not in the system image, so it is not loaded into memory in the very first time.
    [Show full text]
  • Oracle® Linux 7 Monitoring and Tuning the System
    Oracle® Linux 7 Monitoring and Tuning the System F32306-03 October 2020 Oracle Legal Notices Copyright © 2020, Oracle and/or its affiliates. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract.
    [Show full text]
  • Active-Active Firewall Cluster Support in Openbsd
    Active-Active Firewall Cluster Support in OpenBSD David Gwynne School of Information Technology and Electrical Engineering, University of Queensland Submitted for the degree of Bachelor of Information Technology COMP4000 Special Topics Industry Project February 2009 to leese, who puts up with this stuff ii Acknowledgements I would like to thank Peter Sutton for allowing me the opportunity to do this work as part of my studies at the University of Queensland. A huge thanks must go to Ryan McBride for answering all my questions about pf and pfsync in general, and for the many hours working with me on this problem and helping me test and debug the code. Thanks also go to Theo de Raadt, Claudio Jeker, Henning Brauer, and everyone else at the OpenBSD network hackathons who helped me through this. iii Abstract The OpenBSD UNIX-like operating system has developed several technologies that make it useful in the role of an IP router and packet filtering firewall. These technologies include support for several standard routing protocols such as BGP and OSPF, a high performance stateful IP packet filter called pf, shared IP address and fail-over support with CARP (Common Address Redundancy Protocol), and a protocol called pfsync for synchronisation of the firewalls state with firewalls over a network link. These technologies together allow the deployment of two or more computers to provide redundant and highly available routers on a network. However, when performing stateful filtering of the TCP protocol with pf, the routers must be configured in an active-passive configuration due to the current semantics of pfsync.
    [Show full text]
  • BSD UNIX Toolbox: 1000+ Commands for Freebsd, Openbsd and Netbsd Christopher Negus, Francois Caen
    To purchase this product, please visit https://www.wiley.com/en-bo/9780470387252 BSD UNIX Toolbox: 1000+ Commands for FreeBSD, OpenBSD and NetBSD Christopher Negus, Francois Caen E-Book 978-0-470-38725-2 April 2008 $16.99 DESCRIPTION Learn how to use BSD UNIX systems from the command line with BSD UNIX Toolbox: 1000+ Commands for FreeBSD, OpenBSD and NetBSD. Learn to use BSD operation systems the way the experts do, by trying more than 1,000 commands to find and obtain software, monitor system health and security, and access network resources. Apply your newly developed skills to use and administer servers and desktops running FreeBSD, OpenBSD, NetBSD, or any other BSD variety. Become more proficient at creating file systems, troubleshooting networks, and locking down security. ABOUT THE AUTHOR Christopher Negus served for eight years on development teams for the UNIX operating system at the AT&T labs, where UNIX was created and developed. He also worked with Novell on UNIX and UnixWare development. Chris is the author of the bestselling Fedora and Red Hat Linux Bible series, Linux Toys II, Linux Troubleshooting Bible, and Linux Bible 2008 Edition. Francois Caen hosts and manages business application infrastructures through his company Turbosphere LLC. As an open- source advocate, he has lectured on OSS network management and Internet services, and served as president of the Tacoma Linux User Group. He is a Red Hat Certified Engineer (RHCE). To purchase this product, please visit https://www.wiley.com/en-bo/9780470387252.
    [Show full text]
  • Redhawk Linux User's Guide
    Linux® User’s Guide 0898004-520 May 2007 Copyright 2007 by Concurrent Computer Corporation. All rights reserved. This publication or any part thereof is intended for use with Concurrent products by Concurrent personnel, customers, and end–users. It may not be reproduced in any form without the written permission of the publisher. The information contained in this document is believed to be correct at the time of publication. It is subject to change without notice. Concurrent makes no warranties, expressed or implied, concerning the information contained in this document. To report an error or comment on a specific portion of the manual, photocopy the page in question and mark the correction or comment on the copy. Mail the copy (and any additional comments) to Concurrent Computer Corporation, 2881 Gateway Drive, Pompano Beach, Florida, 33069. Mark the envelope “Attention: Publications Department.” This publication may not be reproduced for any other reason in any form without written permission of the publisher. Concurrent Computer Corporation and its logo are registered trademarks of Concurrent Computer Corporation. All other Concurrent product names are trademarks of Concurrent while all other product names are trademarks or registered trademarks of their respective owners. Linux® is used pursuant to a sublicense from the Linux Mark Institute. Printed in U. S. A. Revision History: Date Level Effective With August 2002 000 RedHawk Linux Release 1.1 September 2002 100 RedHawk Linux Release 1.1 December 2002 200 RedHawk Linux Release 1.2 April 2003 300 RedHawk Linux Release 1.3, 1.4 December 2003 400 RedHawk Linux Release 2.0 March 2004 410 RedHawk Linux Release 2.1 July 2004 420 RedHawk Linux Release 2.2 May 2005 430 RedHawk Linux Release 2.3 March 2006 500 RedHawk Linux Release 4.1 May 2006 510 RedHawk Linux Release 4.1 May 2007 520 RedHawk Linux Release 4.2 Preface Scope of Manual This manual consists of three parts.
    [Show full text]
  • Chapter 3. Booting Operating Systems
    Chapter 3. Booting Operating Systems Abstract: Chapter 3 provides a complete coverage on operating systems booting. It explains the booting principle and the booting sequence of various kinds of bootable devices. These include booting from floppy disk, hard disk, CDROM and USB drives. Instead of writing a customized booter to boot up only MTX, it shows how to develop booter programs to boot up real operating systems, such as Linux, from a variety of bootable devices. In particular, it shows how to boot up generic Linux bzImage kernels with initial ramdisk support. It is shown that the hard disk and CDROM booters developed in this book are comparable to GRUB and isolinux in performance. In addition, it demonstrates the booter programs by sample systems. 3.1. Booting Booting, which is short for bootstrap, refers to the process of loading an operating system image into computer memory and starting up the operating system. As such, it is the first step to run an operating system. Despite its importance and widespread interests among computer users, the subject of booting is rarely discussed in operating system books. Information on booting are usually scattered and, in most cases, incomplete. A systematic treatment of the booting process has been lacking. The purpose of this chapter is to try to fill this void. In this chapter, we shall discuss the booting principle and show how to write booter programs to boot up real operating systems. As one might expect, the booting process is highly machine dependent. To be more specific, we shall only consider the booting process of Intel x86 based PCs.
    [Show full text]
  • Debugging Kernel Problems
    Debugging Kernel Problems by GregLehey Edition for AsiaBSDCon 2004 Taipei, 13 March 2004 Debugging Kernel Problems by GregLehey([email protected]) Copyright © 1995-2004 GregLehey 3Debugging Kernel Problems Preface Debugging kernel problems is a black art. Not manypeople do it, and documentation is rare, in- accurate and incomplete. This document is no exception: faced with the choice of accuracyand completeness, I chose to attempt the latter.Asusual, time was the limiting factor,and this draft is still in beta status. This is a typical situation for the whole topic of kernel debugging: building debug tools and documentation is expensive,and the people who write them are also the people who use them, so there'satendencytobuild as much of the tool as necessary to do the job at hand. If the tool is well-written, it will be reusable by the next person who looks at a particular area; if not, it might fall into disuse. Consider this book a starting point for your own develop- ment of debugging tools, and remember: more than anywhere else, this is an area with ``some as- sembly required''. Debugging Kernel Problems 4 1 Introduction Operating systems fail. All operating systems contain bugs, and theywill sometimes cause the system to behave incorrectly.The BSD kernels are no exception. Compared to most other oper- ating systems, both free and commercial, the BSD kernels offer a large number of debugging tools. This tutorial examines the options available both to the experienced end user and also to the developer. In this tutorial, we’ll look at the following topics: • Howand whykernels fail.
    [Show full text]
  • Introduction to Linux Kernel Driver Programming
    IntroductionIntroduction toto LinuxLinux kernelkernel driverdriver programmingprogramming Introduction to Linux kernel driver programming The Linux kernel device model Authors and license ● Authors – Michael Opdenacker ([email protected]) Founder of Bootlin, kernel and embedded Linux engineering company https://bootlin.com/company/staff/michael-opdenacker ● License – Creative Commons Attribution – Share Alike 4.0 https://creativecommons.org/licenses/by-sa/4.0/ – Document sources: https://github.com/e-ale/Slides Need for a device model ● For the same device, need to use the same device driver on multiple CPU architectures (x86, ARM…), even though the hardware controllers are different. ● Need for a single driver to support multiple devices of the same kind. ● This requires a clean organization of the code, with the device drivers separated from the controller drivers, the hardware description separated from the drivers themselves, etc. Driver: between bus infrastructure and framework In Linux, a driver is always interfacing with: ● a framework that allows the driver to expose the hardware features in a generic way. ● a bus infrastructure, part of the device model, to detect/communicate with the hardware. Let’s focus on the bus infrastructure for now Device model data structures The device model is organized around three main data structures: ● The struct bus_type structure, which represent one type of bus (USB, PCI, I2C, etc.) ● The struct device_driver structure, which represents one driver capable of handling certain devices on a certain bus. ● The struct device structure, which represents one device connected to a bus The kernel uses inheritance to create more specialized versions of struct device_driver and struct device for each bus subsystem.
    [Show full text]
  • A Multiplatform Pseudo Terminal
    A Multi-Platform Pseudo Terminal API Project Report Submitted in Partial Fulfillment for the Masters' Degree in Computer Science By Qutaiba Mahmoud Supervised By Dr. Clinton Jeffery ABSTRACT This project is the construction of a pseudo-terminal API, which will provide a pseudo-terminal interface access to interactive programs. The API is aimed at developing an extension to the Unicon language to allow Unicon programs to easily utilize applications that require user interaction via a terminal. A pseudo-terminal is a pair of virtual devices that provide a bidirectional communication channel. This project was constructed to enable an enhancement to a collaborative virtual environment, because it will allow external tools such to be utilized within the same environment. In general the purpose of this API is to allow the UNICON runtime system to act as the user via the terminal which is provided by the API, the terminal is in turn connected to a client process such as a compiler, debugger, or an editor. It can also be viewed as a way for the UNICON environment to control and customize the input and output of external programs. Table of Contents: 1. Introduction 1.1 Pseudo Terminals 1.2 Other Terminals 1.3 Relation To Other Pseudo Terminal Applications. 2. Methodology 2.1 Pseudo Terminal API Function Description 3. Results 3.1 UNIX Implementation 3.2 Windows Implementation 4. Conclusion 5. Recommendations 6. References Acknowledgments I would like to thank my advisor, Dr. Clinton Jeffery, for his support, patience and understanding. Dr. Jeffery has always been prompt in delivering and sharing his knowledge and in providing his assistance.
    [Show full text]