커널 모듈 작업
-
새로운 하드웨어를 위한 지원을 추가하는 장치 드라이버; 또는,
-
btrfs
또는 `NFS`와 같은 파일 시스템 지원.
커널 자체와 같이, 모듈은 기본 매개 변수가 대부분의 경우에 잘 작동하지만, 그 들 행위를 사용자 정의하는 매개 변수를 사용 할 수 있습니다. 사용자-공간 도구는 현재 실행 중인 커널에 적재된 모듈을 나열 할 수 있습니다; 사용 가능한 매개 변수와 모듈-지정 정보를 위하여 사용 가능한 모듈을 쿼리합니다; 실행 중인 커널에 동적으로 적재하거나 제거합니다. kmod 꾸러미에 의해 제공 하는 것과 같은 이들 유틸리티의 대부분은, 수동 종속성-추적이 거의 필요하지 않도록 작업을 수행 할 때에 모듈 종속성을 고려하세요.
On modern systems, kernel modules are automatically loaded by various mechanisms when the conditions call for it. However, there are occasions when it is necessary to load or unload modules manually, such as when one module is preferred over another although either could provide basic functionality, or when a module is misbehaving.
이 장은 다음과 같은 방법을 설명합니다:
-
use the user-space kmod utilities to display, query, load and unload kernel modules and their dependencies;
-
set module parameters both dynamically on the command line and permanently so that you can customize the behavior of your kernel modules; and,
-
부트 시간에 모듈을 적재합니다.
kmod 꾸러미 설치
이 장에서 설명하는 커널 모듈 유틸리티를 사용하기 위하여, 우선 root로 실행에 의해 kmod 꾸러미가 시스템에 설치되어 있는지 확인하세요: ~]# dnf install kmod DNF와 함께 꾸러미 설치에 대한 자세한 내용은, 꾸러미 설치하기를 참조하세요. |
현재-적재된 모듈 나열하기
You can list all kernel modules that are currently loaded into the kernel by running the lsmod command, for example:
~]$ lsmod Module Size Used by tcp_lp 12663 0 bnep 19704 2 bluetooth 372662 7 bnep rfkill 26536 3 bluetooth fuse 87661 3 ip6t_rpfilter 12546 1 ip6t_REJECT 12939 2 ipt_REJECT 12541 2 xt_conntrack 12760 7 ebtable_nat 12807 0 ebtable_broute 12731 0 bridge 110196 1 ebtable_broute stp 12976 1 bridge llc 14552 2 stp,bridge ebtable_filter 12827 0 ebtables 30913 3 ebtable_broute,ebtable_nat,ebtable_filter ip6table_nat 13015 1 nf_conntrack_ipv6 18738 5 nf_defrag_ipv6 34651 1 nf_conntrack_ipv6 nf_nat_ipv6 13279 1 ip6table_nat ip6table_mangle 12700 1 ip6table_security 12710 1 ip6table_raw 12683 1 ip6table_filter 12815 1 ip6_tables 27025 5 ip6table_filter,ip6table_mangle,ip6table_security,ip6table_nat,ip6table_raw iptable_nat 13011 1 nf_conntrack_ipv4 14862 4 nf_defrag_ipv4 12729 1 nf_conntrack_ipv4 nf_nat_ipv4 13263 1 iptable_nat nf_nat 21798 4 nf_nat_ipv4,nf_nat_ipv6,ip6table_nat,iptable_nat [잘린 출력]
lsmod 출력의 각 행에서 다음을 지정합니다:
-
커널 모듈의 이름은 현재 메모리에 적재되었습니다;
-
사용하는 메모리의 사용량; 그리고,
-
the sum total of processes that are using the module and other modules which depend on it, followed by a list of the names of those modules, if there are any. Using this list, you can first unload all the modules depending the module you want to unload. For more information, see Unloading a Module.
최종적으로, lsmod 출력은 /proc/modules
의사-파일의 내용보다 덜 장황하고 상당히 읽기 쉽습니다.
모듈에 대한 정보 표시하기
You can display detailed information about a kernel module by running the modinfo module_name command.
모듈 이름은 .ko로 끝나지 않습니다
kmod 유틸리티 중 하나로 인수로 커널 모듈의 이름을 입력 할 때에, 이름의 끝에`.ko` 확장자를 추가하지 마세요. 커널 모듈 이름은 확장자가 없습니다; 해당 파일이 있습니다. |
인텔 PRO/1000 네트워크 드라이버 인`e1000e` 모듈에 대한 정보를 표시하려면, 다음을 실행하세요:
~]# modinfo e1000e filename: /lib/modules/3.17.4-302.fc21.x86_64/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko version: 2.3.2-k license: GPL description: Intel(R) PRO/1000 Network Driver author: Intel Corporation, <linux.nics@intel.com> srcversion: 2FBED3F5E2EF40112284D95 alias: pci:v00008086d00001503sv*sd*bc*sc*i* alias: pci:v00008086d00001502sv*sd*bc*sc*i* [some alias lines omitted] alias: pci:v00008086d0000105Esv*sd*bc*sc*i* depends: ptp intree: Y vermagic: 3.17.4-302.fc21.x86_64 SMP mod_unload signer: Fedora kernel signing key sig_key: 1F:C9:E6:8F:74:19:55:63:48:FD:EE:2F:DE:B7:FF:9D:A6:33:7B:BF sig_hashalgo: sha256 parm: debug:Debug level (0=none,...,16=all) (int) parm: copybreak:Maximum size of packet that is copied to a new buffer on receive (uint) parm: TxIntDelay:Transmit Interrupt Delay (array of int) parm: TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int) parm: RxIntDelay:Receive Interrupt Delay (array of int) parm: RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int) parm: InterruptThrottleRate:Interrupt Throttling Rate (array of int) parm: IntMode:Interrupt Mode (array of int) parm: SmartPowerDownEnable:Enable PHY smart power down (array of int) parm: KumeranLockLoss:Enable Kumeran lock loss workaround (array of int) parm: WriteProtectNVM:Write-protect NVM [WARNING: disabling this can lead to corrupted NVM] (array of int) parm: CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)
다음은 modinfo 출력에서 몇 가지 부분의 설명입니다:
- 파일이름
-
.ko
커널 객체 파일에 대한 절대 경로입니다. 당신은filename
부분만 출력하기 위해 바로가기 명령처럼 [command]#modinfo -n#을 사용 할 수 있습니다. - 설명
-
모듈에 대한 간단한 설명. 당신은 설명 부분만 출력하기 위해 바로 가기 명령으로 [command]#modinfo -d#를 사용 할 수 있습니다.
- 별칭
-
alias
부분은 모듈에 대한 별칭이 있는 만큼 많이 표시되거나, 만약 별칭이 없으면 완전히 생략됩니다. - 의존성
-
이 부분에는 이 모듈이 의존하는 모든 모듈의 쉼표-구분된 목록이 포함됩니다.
의존 부분 생략하기만약 모듈이 의존성이 없으면,
depends
부분은 출력에서 생략 될 수 있습니다. - parm
-
Each
parm
field presents one module parameter in the form `parameter_name:description`, where:-
parameter_name is the exact syntax you should use when using it as a module parameter on the command line, or in an option line in a
.conf
file in the/etc/modprobe.d/
directory; and, -
description is a brief explanation of what the parameter does, along with an expectation for the type of value the parameter accepts (such as
int
,unit
orarray of int
) in parentheses.Example 2. 모듈 매개변수를 나열하기You can list all parameters that the module supports by using the
-p
option. However, because useful value type information is omitted from modinfo -p output, it is more useful to run:~]# modinfo e1000e | grep "^parm" | sort parm: copybreak:Maximum size of packet that is copied to a new buffer on receive (uint) parm: CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int) parm: debug:Debug level (0=none,...,16=all) (int) parm: InterruptThrottleRate:Interrupt Throttling Rate (array of int) parm: IntMode:Interrupt Mode (array of int) parm: KumeranLockLoss:Enable Kumeran lock loss workaround (array of int) parm: RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int) parm: RxIntDelay:Receive Interrupt Delay (array of int) parm: SmartPowerDownEnable:Enable PHY smart power down (array of int) parm: TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int) parm: TxIntDelay:Transmit Interrupt Delay (array of int) parm: WriteProtectNVM:Write-protect NVM [WARNING: disabling this can lead to corrupted NVM] (array of int)
-
모듈 적재
To load a kernel module, run modprobe module_name as root
. For example, to load the wacom
module, run:
~]# modprobe wacom
By default, modprobe attempts to load the module from /lib/modules/kernel_version/kernel/drivers/
. In this directory, each type of module has its own subdirectory, such as net/
and scsi/
, for network and SCSI interface drivers respectively.
Some modules have dependencies, which are other kernel modules that must be loaded before the module in question can be loaded. The modprobe command always takes dependencies into account when performing operations. When you ask modprobe to load a specific kernel module, it first examines the dependencies of that module, if there are any, and loads them if they are not already loaded into the kernel. modprobe resolves dependencies recursively: it will load all dependencies of dependencies, and so on, if necessary, thus ensuring that all dependencies are always met.
You can use the -v
(or --verbose
) option to cause modprobe to display detailed information about what it is doing, which can include loading module dependencies.
당신은 쉘 입력기에서 다음을 입력하여`이더넷을 통한 광 채널`모듈을 자세히 적재 할 수 있습니다:
~]# modprobe -v fcoe insmod /lib/modules/3.17.4-302.fc21.x86_64/kernel/drivers/scsi/scsi_transport_fc.ko.xz insmod /lib/modules/3.17.4-302.fc21.x86_64/kernel/drivers/scsi/libfc/libfc.ko.xz insmod /lib/modules/3.17.4-302.fc21.x86_64/kernel/drivers/scsi/fcoe/libfcoe.ko.xz insmod /lib/modules/3.17.4-302.fc21.x86_64/kernel/drivers/scsi/fcoe/fcoe.ko.xz
In this example, you can see that modprobe loaded the scsi_tgt
, scsi_transport_fc
, libfc
and libfcoe
modules as dependencies before finally loading fcoe
. Also note that modprobe used the more primitive insmod command to insert the modules into the running kernel.
항상 insmod 대신에 modprobe를 사용하세요!
Although the insmod command can also be used to load kernel modules, it does not resolve dependencies. Because of this, you should always load modules using modprobe instead. |
모듈 적재하기
You can unload a kernel module by running modprobe -r module_name as root
. For example, assuming that the wacom
module is already loaded into the kernel, you can unload it by running:
~]# modprobe -r wacom
아무튼, 이 명령은 만약 처리를 다음과 같이 사용하면 실패 할 것입니다:
-
wacom
모듈; -
`wacom`이 직접 의존하는 모듈, 또는;
-
종속성 트리를 통해, `wacom`이 간접적으로 의존하는 모든 모듈.
See Listing Currently-Loaded Modules for more information about using lsmod to obtain the names of the modules which are preventing you from unloading a certain module.
예를 들면, firewire_ohci
모듈을 제거 하고자 하면, 당신의 터미널 세션은 이와 같이 유사 할 수 있습니다:
~]# modinfo -F depends firewire_ohci firewire-core ~]# modinfo -F depends firewire_core crc-itu-t ~]# modinfo -F depends crc-itu-t
You have figured out the dependency tree (which does not branch in this example) for the loaded Firewire modules: firewire_ohci
depends on firewire_core
, which itself depends on crc-itu-t
.
You can unload firewire_ohci
using the modprobe -v -r module_name command, where -r
is short for --remove
and -v
for --verbose
:
~]# modprobe -r -v firewire_ohci rmmod firewire_ohci rmmod firewire_core rmmod crc_itu_t
The output shows that modules are unloaded in the reverse order that they are loaded, given that no processes depend on any of the modules being unloaded.
rmmod를 직접 사용하지 마세요!
Although the rmmod command can be used to unload kernel modules, it is recommended to use modprobe -r instead. |
모듈 매개변수 설정하기
Like the kernel itself, modules can also take parameters that change their behavior. Most of the time, the default ones work well, but occasionally it is necessary or desirable to set custom parameters for a module. Because parameters cannot be dynamically set for a module that is already loaded into a running kernel, there are two different methods for setting them.
-
You can unload all dependencies of the module you want to set parameters for, unload the module using modprobe -r, and then load it with modprobe along with a list of customized parameters. This method is often used when the module does not have many dependencies, or to test different combinations of parameters without making them persistent, and is the method covered in this section.
-
Alternatively, you can list the new parameters in an existing or newly created file in the
/etc/modprobe.d/
directory. This method makes the module parameters persistent by ensuring that they are set each time the module is loaded, such as after every reboot or modprobe command. This method is covered in Persistent Module Loading, though the following information is a prerequisite.
You can use modprobe to load a kernel module with custom parameters using the following command line format:
~]# modprobe module_name parameter=value
명령줄에서 사용자 정의 매개변수와 함께 모듈을 적재 할 때에, 다음 사항을 유의 하세요:
-
당신은 공백으로 이를 분리하여 여러 매개변수와 값을 입력 할 수 있습니다.
-
Some module parameters expect a list of comma-separated values as their argument. When entering the list of values, do not insert a space after each comma, or modprobe will incorrectly interpret the values following spaces as additional parameters.
-
The modprobe command silently succeeds with an exit status of 0 if:
-
모듈이 성공적으로 적재되었습니다, 또는
-
모듈은 이미 커널에 적재되었습니다.
Thus, you must ensure that the module is not already loaded before attempting to load it with custom parameters. The modprobe command does not automatically reload the module, or alert you that it is already loaded.
-
Here are the recommended steps for setting custom parameters and then loading a kernel module. This procedure illustrates the steps using the e1000e
module, which is the network driver for Intel PRO/1000 network adapters, as an example:
-
우선, 모듈이 커널에 이미 적재 되지 않았는지 확인하세요:
~]# lsmod |grep e1000e ~]#
Output would indicate that the module is already loaded into the kernel, in which case you must first unload it before proceeding. See Unloading a Module for instructions on safely unloading it.
-
Load the module and list all custom parameters after the module name. For example, if you wanted to load the Intel PRO/1000 network driver with the interrupt throttle rate set to 3000 interrupts per second for the first, second, and third instances of the driver, and turn on debug, you would run, as
root
:~]# modprobe e1000e InterruptThrottleRate=3000,3000,3000 debug=1
This example illustrates passing multiple values to a single parameter by separating them with commas and omitting any spaces between them.
지속적인 모듈 적재
As shown in Listing information about a kernel module with lsmod, many kernel modules are loaded automatically at boot time. You can specify additional modules to be loaded by the systemd-modules-load.service
daemon by creating a program.conf
file in the /etc/modules-load.d/
directory, where program is any descriptive name of your choice. The files in /etc/modules-load.d/
are text files that list the modules to be loaded, one per line.
To create a file to load the virtio-net.ko
module, create a file /etc/modules-load.d/virtio-net.conf
with the following content:
# Load virtio-net.ko at boot virtio-net
See the modules-load.d(5)
and systemd-modules-load.service(8)
man pages for more information.
보안 부트를 위해 커널 모듈을 서명하기
Fedora includes support for the UEFI Secure Boot feature, which means that Fedora can be installed and run on systems where UEFI Secure Boot is enabled. [1] When Secure Boot is enabled, the EFI operating system boot loaders, the Fedora kernel, and all kernel modules must be signed with a private key and authenticated with the corresponding public key. The Fedora distribution includes signed boot loaders, signed kernels, and signed kernel modules. In addition, the signed first-stage boot loader and the signed kernel include embedded Fedora public keys. These signed executable binaries and embedded keys enable Fedora to install, boot, and run with the Microsoft UEFI Secure Boot CA keys that are provided by the UEFI firmware on systems that support UEFI Secure Boot.[2]
The information provided in the following sections describes steps necessary to enable you to self-sign privately built kernel modules for use with Fedora on UEFI-based systems where Secure Boot is enabled. These sections also provide an overview of available options for getting your public key onto the target system where you want to deploy your kernel module.
전제조건
In order to enable signing of externally built modules, the tools listed in the following table are required to be installed on the system.
Tool | Provided by Package | Used on | Purpose |
---|---|---|---|
openssl |
openssl |
Build system |
Generates public and private X.509 key pair |
sign-file |
kernel-devel |
Build system |
Perl script used to sign kernel modules |
perl |
perl |
Build system |
Perl interpreter used to run the signing script |
mokutil |
mokutil |
Target system |
Optional tool used to manually enroll the public key |
keyctl |
keyutils |
Target system |
Optional tool used to display public keys in the system key ring |
Note that the build system, where you build and sign your kernel module, does not need to have UEFI Secure Boot enabled and does not even need to be a UEFI-based system. |
커널 모듈 인증
In Fedora, when a kernel module is loaded, the module’s signature is checked using the public X.509 keys on the kernel’s system key ring, excluding those keys that are on the kernel’s system black list key ring.
Sources For Public Keys Used To Authenticate Kernel Modules
During boot, the kernel loads X.509 keys into the system key ring or the system black list key ring from a set of persistent key stores as shown in Sources For System Key Rings
Source of X.509 Keys | User Ability to Add Keys | UEFI Secure Boot State | Keys Loaded During Boot |
---|---|---|---|
Embedded in kernel |
No |
- |
|
UEFI Secure Boot "db" |
Limited |
Not enabled |
No |
Enabled |
|
||
UEFI Secure Boot "dbx" |
Limited |
Not enabled |
No |
Enabled |
|
||
|
No |
Not enabled |
No |
Enabled |
|
||
장비 소유자 키(MOK) 목록 |
Yes |
Not enabled |
No |
Enabled |
|
Note that if the system is not UEFI-based or if UEFI Secure Boot is not enabled, then only the keys that are embedded in the kernel are loaded onto the system key ring and you have no ability to augment that set of keys without rebuilding the kernel. The system black list key ring is a list of X.509 keys which have been revoked. If your module is signed by a key on the black list then it will fail authentication even if your public key is in the system key ring.
Secure 부트가 활성화 되었는지 확인하려면, 다음과 같이 명령을 입력하세요:
~]$ mokutil --sb-state
SecureBoot enabled
If Secure Boot is not enabled then the message Failed to read SecureBoot
is displayed.
You can display information about the keys on the system key rings using the keyctl utility. The following is abbreviated example output from a Fedora system where UEFI Secure Boot is not enabled.
~]# keyctl list %:.system_keyring 1 key in keyring: 265061799: ---lswrv 0 0 asymmetric: Fedora kernel signing key: ba8e2919f98f3f8e2e27541cde0d1f...
The following is abbreviated example output from a Fedora system where UEFI Secure Boot is enabled.
~]# keyctl list %:.system_keyring 5 keys in keyring: ...asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c497... ...asymmetric: Fedora kernel signing key: ba8e2919f98f3f8e2e27541cde0d... ...asymmetric: Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4... ...asymmetric: Red Hat Test Certifying CA: 08a0ef5800cb02fb587c12b4032... ...asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8...
The above output shows the addition of two keys from the UEFI Secure Boot "db" keys plus the Fedora Secure Boot CA
which is embedded in the shim.efi
boot loader.
Kernel Module Authentication Requirements
If UEFI Secure Boot is enabled or if the module.sig_enforce
kernel parameter has been specified, then only signed kernel modules that are authenticated using a key on the system key ring can be successfully loaded.[3] If UEFI Secure Boot is disabled and if the module.sig_enforce
kernel parameter has not been specified, then unsigned kernel modules and signed kernel modules without a public key can be successfully loaded. This is summarized in Kernel Module Authentication Requirements for Loading.
Module Signed | Public Key Found and Signature Valid | UEFI Secure Boot State | module.sig_enforce | Module Load | Kernel Tainted |
---|---|---|---|---|---|
Unsigned |
- |
Not enabled |
Not enabled |
Succeeds |
Yes |
Not enabled |
Enabled |
Fails |
|||
Enabled |
- |
Fails |
- |
||
Signed |
No |
Not enabled |
Not enabled |
Succeeds |
Yes |
Not enabled |
Enabled |
Fails |
- |
||
Enabled |
- |
Fails |
- |
||
Signed |
Yes |
Not enabled |
Not enabled |
Succeeds |
No |
Not enabled |
Enabled |
Succeeds |
No |
||
Enabled |
- |
Succeeds |
No |
Subsequent sections will describe how to generate a public and private X.509 key pair, how to use the private key to sign a kernel module, and how to enroll the public key into a source for the system key ring.
Generating a Public and Private X.509 Key Pair
You need to generate a public and private X.509 key pair that will be used to sign a kernel module after it has been built. The corresponding public key will be used to authenticate the kernel module when it is loaded.
-
The openssl tool can be used to generate a key pair that satisfies the requirements for kernel module signing in Fedora. Some of the parameters for this key generation request are best specified with a configuration file; follow the example below to create your own configuration file.
~]# cat << EOF > configuration_file.config [ req ] default_bits = 4096 distinguished_name = req_distinguished_name prompt = no string_mask = utf8only x509_extensions = myexts [ req_distinguished_name ] O = Organization CN = Organization signing key emailAddress = E-mail address [ myexts ] basicConstraints=critical,CA:FALSE keyUsage=digitalSignature subjectKeyIdentifier=hash authorityKeyIdentifier=keyid EOF
-
After you have created the configuration file, you can create an X.509 public and private key pair. The public key will be written to the
public_key.der
file and the private key will be written to theprivate_key.priv
file.~]# openssl req -x509 -new -nodes -utf8 -sha256 -days 36500 \ > -batch -config configuration_file.config -outform DER \ > -out public_key.der \ > -keyout private_key.priv
-
Enroll your public key on all systems where you want to authenticate and load your kernel module.
Take proper care to guard the contents of your private key. In the wrong hands, the key could be used to compromise any system which has your public key. |
Enrolling Public Key on Target System
When Fedora boots on a UEFI-based system with Secure Boot enabled, all keys that are in the Secure Boot db key database, but not in the dbx database of revoked keys, are loaded onto the system keyring by the kernel. The system keyring is used to authenticate kernel modules.
공개 키가 포함된 공장 펌웨어 이미지
To facilitate authentication of your kernel module on your systems, consider requesting your system vendor to incorporate your public key into the UEFI Secure Boot key database in their factory firmware image.
Executable Key Enrollment Image Adding Public Key
It is possible to add a key to an existing populated and active Secure Boot key database. This can be done by writing and providing an EFI executable enrollment image. Such an enrollment image contains a properly formed request to append a key to the Secure Boot key database. This request must include data that is properly signed by the private key that corresponds to a public key that is already in the system’s Secure Boot Key Exchange Key (KEK) database. Additionally, this EFI image must be signed by a private key that corresponds to a public key that is already in the key database.
It is also possible to write an enrollment image that runs under Fedora. However, the Fedora image must be properly signed by a private key that corresponds to a public key that is already in the KEK database.
The construction of either type of key enrollment images requires assistance from the platform vendor.
System Administrator Manually Adding Public Key to the MOK List
The Machine Owner Key (MOK) facility is a feature that is supported by Fedora and can be used to augment the UEFI Secure Boot key database. When Fedora boots on a UEFI-enabled system with Secure Boot enabled, the keys on the MOK list are also added to the system keyring in addition to the keys from the key database. The MOK list keys are also stored persistently and securely in the same fashion as the Secure Boot key database keys, but these are two separate facilities. The MOK facility is supported by shim.efi, MokManager.efi, grubx64.efi, and the Fedora mokutil utility.
The major capability provided by the MOK facility is the ability to add public keys to the MOK list without needing to have the key chain back to another key that is already in the KEK database. However, enrolling a MOK key requires manual interaction by a physically present user at the UEFI system console on each target system. Nevertheless, the MOK facility provides an excellent method for testing newly generated key pairs and testing kernel modules signed with them.
당신의 공용 키를 MOK 항목에 추가하기 위해 다음 단계를 따르세요:
-
페도라 사용자 공간 유틸리티를 사용하여 MOK 목록에서 추가적인 당신의 공개 키를 요청합니다:
~]# mokutil --import my_signing_key_pub.der
이 MOK 등록 요청에 대한 비밀번호를 입력하고 확인하라고 요청될 것입니다.
-
이 장비를 재시작합니다.
-
The pending MOK key enrollment request will be noticed by
shim.efi
and it will launchMokManager.efi
to allow you to complete the enrollment from the UEFI console. You will need to enter the password you previously associated with this request and confirm the enrollment. Your public key is added to the MOK list, which is persistent.
Once a key is on the MOK list, it will be automatically propagated to the system key ring on this and subsequent boots when UEFI Secure Boot is enabled.
Signing Kernel Module with the Private Key
There are no extra steps required to prepare your kernel module for signing. You build your kernel module normally. Assuming an appropriate Makefile and corresponding sources, follow these steps to build your module and sign it:
-
Build your
my_module.ko
module the standard way:~]# make -C /usr/src/kernels/$(uname -r) M=$PWD modules
-
Sign your kernel module with your private key. This is done with a Perl script. Note that the script requires that you provide both the files that contain your private and the public key as well as the kernel module file that you want to sign.
~]# perl /usr/src/kernels/$(uname -r)/scripts/sign-file \ > sha256 \ > my_signing_key.priv \ > my_signing_key_pub.der \ > my_module.ko
Your kernel module is in ELF image format and this script computes and appends the signature directly to the ELF image in your my_module.ko
file. The modinfo utility can be used to display information about the kernel module’s signature, if it is present. For information on using the utility, see Displaying Information About a Module.
Note that this appended signature is not contained in an ELF image section and is not a formal part of the ELF image. Therefore, tools such as readelf will not be able to display the signature on your kernel module.
Your kernel module is now ready for loading. Note that your signed kernel module is also loadable on systems where UEFI Secure Boot is disabled or on a non-UEFI system. That means you do not need to provide both a signed and unsigned version of your kernel module.
Loading Signed Kernel Module
Once your public key is enrolled and is in the system keyring, the normal kernel module loading mechanisms will work transparently. In the following example, you will use mokutil to add your public key to the MOK list and you will manually load your kernel module with modprobe.
-
Optionally, you can verify that your kernel module will not load before you have enrolled your public key. First, verify what keys have been added to the system key ring on the current boot by running the keyctl list %:.system_keyring as root. Since your public key has not been enrolled yet, it should not be displayed in the output of the command.
-
공개 키 등록을 요청하세요.
~]# mokutil --import my_signing_key_pub.der
-
재시작, 그리고 UEFI 콘솔에서 등록을 완료합니다.
~]# reboot
-
After the system reboots, verify the keys on the system key ring again.
~]# keyctl list %:.system_keyring
-
You should now be able to load your kernel module successfully.
~]# modprobe -v my_module insmod /lib/modules/3.17.4-302.fc21.x86_64/extra/my_module.ko ~]# lsmod | grep my_module my_module 12425 0
추가 자원
For more information on kernel modules and their utilities, see the following resources.
-
lsmod(8)
— The manual page for the lsmod command. -
modinfo(8)
— The manual page for the modinfo command. -
modprobe(8)
— The manual page for the modprobe command. -
rmmod(8)
— The manual page for the rmmod command. -
ethtool(8)
— The manual page for the ethtool command. -
mii-tool(8)
— The manual page for the mii-tool command.
-
Linux Loadable Kernel Module HOWTO — The Linux Loadable Kernel Module HOWTO from the Linux Documentation Project contains further information on working with kernel modules.
Want to help? Learn how to contribute to Fedora Docs ›