Proofread

This commit is contained in:
Jim Huang 2023-08-10 10:26:11 +08:00
parent ae308fd092
commit fae9ac44d4

View File

@ -105,11 +105,12 @@ This endeavor delves into a realm where an unchecked pointer, if left unattended
could potentially cause the complete erasure of an entire file system,
leading to an event that prompts a complete system reboot.
Precisely defined, a kernel module refers to a segment of code that possesses the ability to be dynamically loaded and unloaded within the kernel according to necessity.
Such modules elevate kernel capabilities without the imposition of a system reboot requirement.
A notable instance is observed in the device driver module, which serves to facilitate the interaction of the kernel with the hardware components attached to the system.
In the absence of modules, the prevailing approach leans toward monolithic kernels, necessitating the direct integration of novel functionalities into the kernel image.
This approach not only contributes to the generation of larger kernels but also mandates the undertaking of kernel rebuilding and subsequent system rebooting whenever a desired addition of functionality arises.
A kernel module is precisely defined as a code segment capable of dynamic loading and unloading within the kernel as needed.
These modules enhance kernel capabilities without necessitating a system reboot.
A notable example is seen in the device driver module, which facilitates kernel interaction with hardware components linked to the system.
In the absence of modules, the prevailing approach leans toward monolithic kernels,
requiring direct integration of new functionalities into the kernel image.
This approach leads to larger kernels and necessitates kernel rebuilding and subsequent system rebooting when new functionalities are desired.
\subsection{Kernel module package}
\label{sec:packages}
@ -161,27 +162,30 @@ It is reassuring to note that overcoming the initial obstacle in the first attem
\begin{enumerate}
\item Modversioning.
A module compiled for one kernel will not load if you boot a different kernel unless you enable \cpp|CONFIG_MODVERSIONS| in the kernel.
We will not go into module versioning until later in this guide.
Until we cover modversions, the examples in the guide may not work if you are running a kernel with modversioning turned on.
However, most stock Linux distribution kernels come with it turned on.
If you are having trouble loading the modules because of versioning errors, compile a kernel with modversioning turned off.
A module compiled for one kernel will not load if a different kernel is booted,
unless \cpp|CONFIG_MODVERSIONS| is enabled in the kernel.
Module versioning will be discussed later in this guide.
Until module versioning is covered, the examples in this guide may not work correctly if running a kernel with modversioning turned on.
However, most stock Linux distribution kernels come with modversioning enabled.
If difficulties arise when loading the modules due to versioning errors, consider compiling a kernel with modversioning turned off.
\item Using X Window System.
\label{sec:using_x}
It is highly recommended that you extract, compile and load all the examples this guide discusses from a console.
You should not be working on this stuff in X Window System.
It is highly recommended to extract, compile, and load all the examples discussed in this guide from a console.
Working on these tasks within the X Window System is discouraged.
Modules can not print to the screen like \cpp|printf()| can, but they can log information and warnings, which ends up being printed on your screen, but only on a console.
If you \sh|insmod| a module from an xterm, the information and warnings will be logged, but only to your systemd journal.
You will not see it unless you look through your \sh|journalctl| .
See \ref{sec:helloworld} for details.
To have immediate access to this information, do all your work from the console.
Modules cannot directly print to the screen like \cpp|printf()| can,
but they can log information and warnings that are eventually displayed on the screen,
specifically within a console.
If a module is loaded from an \sh|xterm|, the information and warnings will be logged,
but solely within the systemd journal. These logs will not be visible unless consulting the \sh|journalctl|.
Refer to \ref{sec:helloworld} for more information.
For instant access to this information, it is advisable to perform all tasks from the console.
\item SecureBoot.
Many contemporary computers are pre-configured with UEFI SecureBoot enabled.
It is a security standard that can make sure the device boots using only software that is trusted by original equipment manufacturer.
The default Linux kernel from some distributions have also enabled the SecureBoot.
For such distributions, the kernel module has to be signed with the security key or you would get the "\emph{ERROR: could not insert module}" when you insert your first hello world module:
For such distributions, the kernel module has to be signed with the security key or you would get the ``\emph{ERROR: could not insert module}'' when you insert your first hello world module:
\begin{codebash}
insmod ./hello-1.ko
@ -191,7 +195,7 @@ insmod ./hello-1.ko
\emph{Lockdown: insmod: unsigned module loading is restricted;
see man kernel lockdown.7}
If you got this message, the simplest way is to disable the UEFI SecureBoot from the PC/laptop boot menu to have your "hello-1" to be inserted.
If you got this message, the simplest way is to disable the UEFI SecureBoot from the PC/laptop boot menu to have your ``hello-1'' to be inserted.
Of course you can go through complicated steps to generate keys, install keys to your system, and finally sign your module to make it work.
However, this is not suitable for beginners.
You could read and follow the steps in \href{https://wiki.debian.org/SecureBoot}{SecureBoot} if you are interested.