Linux Device Drivers 2nd Edition (779877), страница 5
Текст из файла (страница 5)
The programmer has, obviously,much more power than a plain user. In other words, it’s as dangerous to run aprogram you got from somebody else from the root account as it is to give him orher a root shell now and then. Although having access to a compiler is not a security hole per se, the hole can appear when compiled code is actually executed;everyone should be careful with modules, because a kernel module can do anything. A module is just as powerful as a superuser shell.Any security check in the system is enforced by kernel code.
If the kernel hassecurity holes, then the system has holes. In the official kernel distribution, onlyan authorized user can load modules; the system call cr eate_module checks if theinvoking process is authorized to load a module into the kernel. Thus, when running an official kernel, only the superuser,* or an intruder who has succeeded inbecoming privileged, can exploit the power of privileged code.When possible, driver writers should avoid encoding security policy in their code.Security is a policy issue that is often best handled at higher levels within the kernel, under the control of the system administrator.
There are always exceptions,however. As a device driver writer, you should be aware of situations in whichsome types of device access could adversely affect the system as a whole, andshould provide adequate controls. For example, device operations that affectglobal resources (such as setting an interrupt line) or that could affect other users(such as setting a default block size on a tape drive) are usually only available tosufficiently privileged users, and this check must be made in the driver itself.Driver writers must also be careful, of course, to avoid introducing security bugs.The C programming language makes it easy to make several types of errors.
Manycurrent security problems are created, for example, by buffer overrun errors, inwhich the programmer forgets to check how much data is written to a buffer, anddata ends up written beyond the end of the buffer, thus overwriting unrelated* Version 2.0 of the kernel allows only the superuser to run privileged code, while version2.2 has more sophisticated capability checks. We discuss this in “Capabilities andRestricted Operations” in Chapter 5.922 June 2001 16:32http://openlib.org.uaChapter 1: An Introduction to Device Driversdata.
Such errors can compromise the entire system and must be avoided. Fortunately, avoiding these errors is usually relatively easy in the device driver context,in which the interface to the user is narrowly defined and highly controlled.Some other general security ideas are worth keeping in mind. Any input receivedfrom user processes should be treated with great suspicion; never trust it unlessyou can verify it. Be careful with uninitialized memory; any memory obtainedfrom the kernel should be zeroed or otherwise initialized before being made available to a user process or device.
Otherwise, information leakage could result. Ifyour device interprets data sent to it, be sure the user cannot send anything thatcould compromise the system. Finally, think about the possible effect of deviceoperations; if there are specific operations (e.g., reloading the firmware on anadapter board, formatting a disk) that could affect the system, those operationsshould probably be restricted to privileged users.Be careful, also, when receiving software from third parties, especially when thekernel is concerned: because everybody has access to the source code, everybodycan break and recompile things.
Although you can usually trust precompiled kernels found in your distribution, you should avoid running kernels compiled by anuntrusted friend—if you wouldn’t run a precompiled binary as root, then you’dbetter not run a precompiled kernel. For example, a maliciously modified kernelcould allow anyone to load a module, thus opening an unexpected back door viacr eate_module.Note that the Linux kernel can be compiled to have no module support whatsoever, thus closing any related security holes. In this case, of course, all neededdrivers must be built directly into the kernel itself.
It is also possible, with 2.2 andlater kernels, to disable the loading of kernel modules after system boot, via thecapability mechanism.Version NumberingBefore digging into programming, we’d like to comment on the version numbering scheme used in Linux and which versions are covered by this book.First of all, note that every software package used in a Linux system has its ownrelease number, and there are often interdependencies across them: you need aparticular version of one package to run a particular version of another package.The creators of Linux distributions usually handle the messy problem of matchingpackages, and the user who installs from a prepackaged distribution doesn’t needto deal with version numbers.
Those who replace and upgrade system software,on the other hand, are on their own. Fortunately, almost all modern distributionssupport the upgrade of single packages by checking interpackage dependencies;the distribution’s package manager generally will not allow an upgrade until thedependencies are satisfied.1022 June 2001 16:32http://openlib.org.uaVersion NumberingTo run the examples we introduce during the discussion, you won’t need particular versions of any tool but the kernel; any recent Linux distribution can be usedto run our examples.
We won’t detail specific requirements, because the file Documentation/Changes in your kernel sources is the best source of such information ifyou experience any problem.As far as the kernel is concerned, the even-numbered kernel versions (i.e., 2.2.xand 2.4.x) are the stable ones that are intended for general distribution.
The oddversions (such as 2.3.x), on the contrary, are development snapshots and are quiteephemeral; the latest of them represents the current status of development, butbecomes obsolete in a few days or so.This book covers versions 2.0 through 2.4 of the kernel. Our focus has been toshow all the features available to device driver writers in 2.4, the current version atthe time we are writing. We also try to cover 2.2 thoroughly, in those areas wherethe features differ between 2.2 and 2.4.
We also note features that are not availablein 2.0, and offer workarounds where space permits. In general, the code we showis designed to compile and run on a wide range of kernel versions; in particular, ithas all been tested with version 2.4.4, and, where applicable, with 2.2.18 and2.0.38 as well.This text doesn’t talk specifically about odd-numbered kernel versions.
Generalusers will never have a reason to run development kernels. Developers experimenting with new features, however, will want to be running the latest development release. They will usually keep upgrading to the most recent version to pickup bug fixes and new implementations of features. Note, however, that there’s noguarantee on experimental kernels,* and nobody will help you if you have problems due to a bug in a noncurrent odd-numbered kernel. Those who run oddnumbered versions of the kernel are usually skilled enough to dig in the codewithout the need for a textbook, which is another reason why we don’t talk aboutdevelopment kernels here.Another feature of Linux is that it is a platform-independent operating system, notjust “a Unix clone for PC clones” anymore: it is successfully being used with Alphaand SPARC processors, 68000 and PowerPC platforms, as well as a few more. Thisbook is platform independent as far as possible, and all the code samples havebeen tested on several platforms, such as the PC brands, Alpha, ARM, IA-64, M68k,PowerPC, SPARC, SPARC64, and VR41xx (MIPS).
Because the code has been testedon both 32-bit and 64-bit processors, it should compile and run on all other platforms. As you might expect, the code samples that rely on particular hardwaredon’t work on all the supported platforms, but this is always stated in the sourcecode.* Note that there’s no guarantee on even-numbered kernels as well, unless you rely on acommercial provider that grants its own warranty.1122 June 2001 16:32http://openlib.org.uaChapter 1: An Introduction to Device DriversLicense TermsLinux is licensed with the GNU General Public License (GPL), a document devisedfor the GNU project by the Free Software Foundation.
The GPL allows anybody toredistribute, and even sell, a product covered by the GPL, as long as the recipientis allowed to rebuild an exact copy of the binary files from source. Additionally,any software product derived from a product covered by the GPL must, if it isredistributed at all, be released under the GPL.The main goal of such a license is to allow the growth of knowledge by permittingeverybody to modify programs at will; at the same time, people selling software tothe public can still do their job. Despite this simple objective, there’s a never-ending discussion about the GPL and its use. If you want to read the license, you canfind it in several places in your system, including the directory /usr/src/linux, as afile called COPYING.Third-party and custom modules are not part of the Linux kernel, and thus you’renot forced to license them under the GPL.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
