mirror of
https://github.com/sysprog21/lkmpg.git
synced 2024-11-28 19:33:38 +08:00
Proofread
This commit is contained in:
parent
ae308fd092
commit
fae9ac44d4
42
lkmpg.tex
42
lkmpg.tex
|
@ -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,
|
could potentially cause the complete erasure of an entire file system,
|
||||||
leading to an event that prompts a complete system reboot.
|
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.
|
A kernel module is precisely defined as a code segment capable of dynamic loading and unloading within the kernel as needed.
|
||||||
Such modules elevate kernel capabilities without the imposition of a system reboot requirement.
|
These modules enhance kernel capabilities without necessitating a system reboot.
|
||||||
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.
|
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, necessitating the direct integration of novel functionalities into the kernel image.
|
In the absence of modules, the prevailing approach leans toward monolithic kernels,
|
||||||
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.
|
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}
|
\subsection{Kernel module package}
|
||||||
\label{sec:packages}
|
\label{sec:packages}
|
||||||
|
@ -161,27 +162,30 @@ It is reassuring to note that overcoming the initial obstacle in the first attem
|
||||||
|
|
||||||
\begin{enumerate}
|
\begin{enumerate}
|
||||||
\item Modversioning.
|
\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.
|
A module compiled for one kernel will not load if a different kernel is booted,
|
||||||
We will not go into module versioning until later in this guide.
|
unless \cpp|CONFIG_MODVERSIONS| is enabled in the kernel.
|
||||||
Until we cover modversions, the examples in the guide may not work if you are running a kernel with modversioning turned on.
|
Module versioning will be discussed later in this guide.
|
||||||
However, most stock Linux distribution kernels come with it turned on.
|
Until module versioning is covered, the examples in this guide may not work correctly if running a kernel with modversioning turned on.
|
||||||
If you are having trouble loading the modules because of versioning errors, compile a kernel with modversioning turned off.
|
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.
|
\item Using X Window System.
|
||||||
\label{sec:using_x}
|
\label{sec:using_x}
|
||||||
It is highly recommended that you extract, compile and load all the examples this guide discusses from a console.
|
It is highly recommended to extract, compile, and load all the examples discussed in this guide from a console.
|
||||||
You should not be working on this stuff in X Window System.
|
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.
|
Modules cannot directly print to the screen like \cpp|printf()| can,
|
||||||
If you \sh|insmod| a module from an xterm, the information and warnings will be logged, but only to your systemd journal.
|
but they can log information and warnings that are eventually displayed on the screen,
|
||||||
You will not see it unless you look through your \sh|journalctl| .
|
specifically within a console.
|
||||||
See \ref{sec:helloworld} for details.
|
If a module is loaded from an \sh|xterm|, the information and warnings will be logged,
|
||||||
To have immediate access to this information, do all your work from the console.
|
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.
|
\item SecureBoot.
|
||||||
Many contemporary computers are pre-configured with UEFI SecureBoot enabled.
|
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.
|
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.
|
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}
|
\begin{codebash}
|
||||||
insmod ./hello-1.ko
|
insmod ./hello-1.ko
|
||||||
|
@ -191,7 +195,7 @@ insmod ./hello-1.ko
|
||||||
\emph{Lockdown: insmod: unsigned module loading is restricted;
|
\emph{Lockdown: insmod: unsigned module loading is restricted;
|
||||||
see man kernel lockdown.7}
|
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.
|
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.
|
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.
|
You could read and follow the steps in \href{https://wiki.debian.org/SecureBoot}{SecureBoot} if you are interested.
|
||||||
|
|
Loading…
Reference in New Issue
Block a user