======== 개요

Question 1

보안 부팅을 비활성화하거나 커널 모듈에 서명합니다.

개인적으로 BIOS에서 보안 부팅을 비활성화합니다.

보다https://wiki.ubuntu.com/SecurityTeam/SecureBoot

또는 커널 모듈에 수동으로 서명하려면 다음을 참조하세요.

https://www.kernel.org/doc/Documentation/module-signing.txt

      ==============================          KERNEL MODULE SIGNING FACILITY
      ==============================
내용물

개요.

모듈 서명 구성.

서명 키를 생성하는 중입니다.

커널의 공개 키.

모듈에 수동으로 서명합니다.

서명된 모듈 및 스트리핑.

서명된 모듈을 로드하는 중입니다.

유효하지 않은 서명 및 서명되지 않은 모듈.

개인 키를 관리/보호합니다.

======== 개요

커널 모듈 서명 기능은 설치 중에 모듈에 암호화 방식으로 서명한 다음 모듈 로드 시 서명을 확인합니다. 이를 통해 서명되지 않은 모듈이나 유효하지 않은 키로 서명된 모듈의 로드를 허용하지 않음으로써 커널 보안을 강화할 수 있습니다. 모듈 서명은 악성 모듈을 커널에 로드하는 것을 더 어렵게 만들어 보안을 강화합니다. 모듈 서명 검사는 커널에 의해 수행되므로 신뢰할 수 있는 사용자 공간 비트가 필요하지 않습니다.

이 기능은 X.509 ITU-T 표준 인증서를 사용하여 관련된 공개 키를 인코딩합니다. 서명 자체는 산업 표준 유형으로 인코딩되지 않습니다. 이 기능은 현재 RSA 공개 키 암호화 표준만 지원합니다(단, 플러그형이며 다른 표준도 사용할 수 있음). 사용할 수 있는 해시 알고리즘은 SHA-1, SHA-224, SHA-256, SHA-384 및 SHA-512입니다(알고리즘은 서명의 데이터로 선택됨).

========================== 모듈 서명 구성

모듈 서명 기능은 커널 구성의 "Enable Loadable Module Support" 섹션으로 이동하여 활성화하면 활성화됩니다.

CONFIG_MODULE_SIG "모듈 서명 확인"

여기에는 다양한 옵션이 있습니다:

(1) "모듈이 유효하게 서명되어야 함"(CONFIG_MODULE_SIG_FORCE)
 This specifies how the kernel should deal with a module that has a
 signature for which the key is not known or a module that is unsigned.

 If this is off (ie. "permissive"), then modules for which the key is not
 available and modules that are unsigned are permitted, but the kernel will
 be marked as being tainted, and the concerned modules will be marked as
 tainted, shown with the character 'E'.

 If this is on (ie. "restrictive"), only modules that have a valid
 signature that can be verified by a public key in the kernel's possession
 will be loaded.  All other modules will generate an error.

 Irrespective of the setting here, if the module has a signature block that
 cannot be parsed, it will be rejected out of hand.
(2) "모든 모듈에 자동으로 서명"(CONFIG_MODULE_SIG_ALL)
 If this is on then modules will be automatically signed during the
 modules_install phase of a build.  If this is off, then the modules must
 be signed manually using:
스크립트/서명 파일

(3) "모듈은 어떤 해시 알고리즘으로 서명해야 합니까?"
 This presents a choice of which hash algorithm the installation phase will
 sign the modules with:
CONFIG_MODULE_SIG_SHA1 "SHA-1로 모듈 서명" CONFIG_MODULE_SIG_SHA224 "SHA-224로 모듈 서명" CONFIG_MODULE_SIG_SHA256 "SHA-256으로 모듈 서명" CONFIG_MODULE_SIG_SHA384 "SHA-384로 모듈 서명" CONFIG_MODULE_SIG_SHA512 "서명 SHA-512가 포함된 모듈"
 The algorithm selected here will also be built into the kernel (rather
 than being a module) so that modules signed with that algorithm can have
 their signatures checked without causing a dependency loop.
(4) "모듈 서명 키의 파일 이름 또는 PKCS#11 URI"(CONFIG_MODULE_SIG_KEY)
 Setting this option to something other than its default of
 "certs/signing_key.pem" will disable the autogeneration of signing keys
 and allow the kernel modules to be signed with a key of your choosing.
 The string provided should identify a file containing both a private key
 and its corresponding X.509 certificate in PEM form, or — on systems where
 the OpenSSL ENGINE_pkcs11 is functional — a PKCS#11 URI as defined by
 RFC7512. In the latter case, the PKCS#11 URI should reference both a
 certificate and a private key.

 If the PEM file containing the private key is encrypted, or if the
 PKCS#11 token requries a PIN, this can be provided at build time by
 means of the KBUILD_SIGN_PIN variable.
(5) "기본 시스템 키링을 위한 추가 X.509 키"(CONFIG_SYSTEM_TRUSTED_KEYS)
 This option can be set to the filename of a PEM-encoded file containing
 additional certificates which will be included in the system keyring by
 default.
모듈 서명을 활성화하면 서명을 수행하는 도구의 커널 빌드 프로세스에 OpenSSL 개발 패키지에 대한 종속성이 추가됩니다.

======================= 서명 키 생성

서명을 생성하고 확인하려면 암호화 키 쌍이 필요합니다. 개인 키는 서명을 생성하는 데 사용되며 해당 공개 키는 서명을 확인하는 데 사용됩니다. 개인 키는 빌드 중에만 필요하며, 그 후에는 삭제하거나 안전하게 저장할 수 있습니다. 공개 키는 모듈이 로드될 때 서명을 확인하는 데 사용할 수 있도록 커널에 내장됩니다.

정상적인 조건에서 CONFIG_MODULE_SIG_KEY가 기본값에서 변경되지 않은 경우 커널 빌드는 파일에 키 쌍이 없으면 openssl을 사용하여 자동으로 새 키 쌍을 생성합니다.

인증서/signing_key.pem

vmlinux를 빌드하는 동안(키의 공개 부분은 vmlinux에 빌드해야 함) 다음 매개변수를 사용합니다.

certs/x509.genkey

파일(아직 존재하지 않는 경우에도 생성됨)

자신만의 x509.genkey 파일을 제공하는 것이 좋습니다.

특히 x509.genkey 파일에서 req_distinguished_name 섹션을 기본값에서 변경해야 합니다.

[ req_distinguished_name ] #O = 지정되지 않은 회사 CN = 빌드 시간 자동 생성 커널 키 #emailAddress = [이메일 보호됨]

생성된 RSA 키 크기는 다음을 사용하여 설정할 수도 있습니다.

[ 요청 ] default_bits = 4096

Linux 커널 소스 트리의 루트 노드에 있는 x509.genkey 키 생성 구성 파일과 openssl 명령을 사용하여 키 개인/공용 파일을 수동으로 생성할 수도 있습니다. 다음은 공개/개인 키 파일을 생성하는 예입니다.

openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 \ -config x509.genkey -outform PEM -out kernel_key.pem \ -keyout kernel_key.pem

그런 다음 결과 kernel_key.pem 파일의 전체 경로 이름을 CONFIG_MODULE_SIG_KEY 옵션에 지정할 수 있으며, 해당 인증서와 키는 자동 생성된 키 쌍 대신 사용됩니다.

========================= 커널의 공개 키

커널에는 루트가 볼 수 있는 공개 키 링이 포함되어 있습니다. 다음을 통해 볼 수 있는 ".system_keyring"이라는 키링에 있습니다.

[root@deneb ~]# cat /proc/keys ... 223c7853 I------ 1 perm 1f030000 0 0 keyring .system_keyring: 1 302d2d52 I------
1 perm 1f010000 0 0 비대칭 Fedora 커널 서명 키: d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509.RSA a7118079 [] ...

모듈 서명을 위해 특별히 생성된 공개 키 외에도 CONFIG_SYSTEM_TRUSTED_KEYS 구성 옵션에서 참조하는 PEM 인코딩 파일에 신뢰할 수 있는 추가 인증서를 제공할 수 있습니다.

또한 아키텍처 코드는 하드웨어 상점에서 공개 키를 가져와서 (예: UEFI 키 데이터베이스에서) 추가할 수도 있습니다.

마지막으로 다음을 수행하여 추가 공개 키를 추가할 수 있습니다.

keyctl padd asymmetric "" [.system_keyring-ID] <[key-file]

예:

keyctl padd 비대칭 "" 0x223c7853
그러나 커널은 .system_keyring에 키를 추가하는 것만 허용합니다.만약에새 키의 X.509 래퍼는 키가 추가된 시점에 .system_keyring에 이미 있던 키에 의해 유효하게 서명됩니다.

========================= 수동 서명 모듈

모듈에 수동으로 서명하려면 Linux 커널 소스 트리에서 사용할 수 있는 스크립트/서명 파일 도구를 사용하세요. 스크립트에는 4개의 인수가 필요합니다.

해시 알고리즘(예: sha256)

개인 키 파일 이름 또는 PKCS#11 URI

공개 키 파일 이름

서명할 커널 모듈

다음은 커널 모듈에 서명하는 예입니다.

스크립트/서명 파일 sha512 kernel-signkey.priv \ kernel-signkey.x509 module.ko

사용되는 해시 알고리즘은 구성된 것과 일치할 필요는 없지만 그렇지 않은 경우 해시 알고리즘이 커널에 내장되어 있는지 또는 자체 요구 없이 로드될 수 있는지 확인해야 합니다.

개인 키에 암호나 PIN이 필요한 경우 $KBUILD_SIGN_PIN 환경 변수에 제공할 수 있습니다.

============================ 서명된 모듈 및 스트리핑

서명된 모듈에는 끝에 디지털 서명이 추가됩니다. 문자열 "~모듈 서명이 추가되었습니다~." 모듈 파일 끝에는 서명이 있음을 확인하지만 서명이 유효한지 확인하지는 않습니다!

서명된 모듈은 서명이 정의된 ELF 컨테이너 외부에 있으므로 취약합니다. 따라서 서명이 계산되어 첨부되면 제거될 수 없습니다. 전체 모듈은 서명 당시 존재하는 모든 디버그 정보를 포함하여 서명된 페이로드입니다.

====================== 서명된 모듈 로드 중

모듈은 insmod, modprobe, init_module() 또는 finit_module()을 사용하여 로드됩니다. 사용자 공간에서는 처리가 수행되지 않으므로 서명되지 않은 모듈과 똑같습니다. 서명 확인은 모두 커널 내에서 수행됩니다.

======================================== 유효하지 않은 서명 및 서명되지 않은 모듈

CONFIG_MODULE_SIG_FORCE가 활성화되거나 커널 명령줄에 module.sig_enforce=1이 제공되면 커널은 공개 키가 있는 유효하게 서명된 모듈만 로드합니다. 그렇지 않으면 서명되지 않은 모듈도 로드됩니다. 커널에 키가 있지만 서명 불일치가 있는 것으로 판명된 모듈은 로드가 허용되지 않습니다.

구문 분석할 수 없는 서명이 있는 모듈은 거부됩니다.

======================================== 개인 키 관리/보호

개인 키는 모듈에 서명하는 데 사용되므로 바이러스 및 맬웨어는 개인 키를 사용하여 모듈에 서명하고 운영 체제를 손상시킬 수 있습니다. 개인 키는 파기되거나 안전한 위치로 이동되어야 하며 커널 소스 트리의 루트 노드에 보관되어서는 안 됩니다.

Answer

보안 부팅을 비활성화하거나 커널 모듈에 서명합니다.

개인적으로 BIOS에서 보안 부팅을 비활성화합니다.

보다https://wiki.ubuntu.com/SecurityTeam/SecureBoot

또는 커널 모듈에 수동으로 서명하려면 다음을 참조하세요.

https://www.kernel.org/doc/Documentation/module-signing.txt

      ==============================          KERNEL MODULE SIGNING FACILITY
      ==============================
내용물

개요.

모듈 서명 구성.

서명 키를 생성하는 중입니다.

커널의 공개 키.

모듈에 수동으로 서명합니다.

서명된 모듈 및 스트리핑.

서명된 모듈을 로드하는 중입니다.

유효하지 않은 서명 및 서명되지 않은 모듈.

개인 키를 관리/보호합니다.

======== 개요

커널 모듈 서명 기능은 설치 중에 모듈에 암호화 방식으로 서명한 다음 모듈 로드 시 서명을 확인합니다. 이를 통해 서명되지 않은 모듈이나 유효하지 않은 키로 서명된 모듈의 로드를 허용하지 않음으로써 커널 보안을 강화할 수 있습니다. 모듈 서명은 악성 모듈을 커널에 로드하는 것을 더 어렵게 만들어 보안을 강화합니다. 모듈 서명 검사는 커널에 의해 수행되므로 신뢰할 수 있는 사용자 공간 비트가 필요하지 않습니다.

이 기능은 X.509 ITU-T 표준 인증서를 사용하여 관련된 공개 키를 인코딩합니다. 서명 자체는 산업 표준 유형으로 인코딩되지 않습니다. 이 기능은 현재 RSA 공개 키 암호화 표준만 지원합니다(단, 플러그형이며 다른 표준도 사용할 수 있음). 사용할 수 있는 해시 알고리즘은 SHA-1, SHA-224, SHA-256, SHA-384 및 SHA-512입니다(알고리즘은 서명의 데이터로 선택됨).

========================== 모듈 서명 구성

모듈 서명 기능은 커널 구성의 "Enable Loadable Module Support" 섹션으로 이동하여 활성화하면 활성화됩니다.

CONFIG_MODULE_SIG "모듈 서명 확인"

여기에는 다양한 옵션이 있습니다:

(1) "모듈이 유효하게 서명되어야 함"(CONFIG_MODULE_SIG_FORCE)
 This specifies how the kernel should deal with a module that has a
 signature for which the key is not known or a module that is unsigned.

 If this is off (ie. "permissive"), then modules for which the key is not
 available and modules that are unsigned are permitted, but the kernel will
 be marked as being tainted, and the concerned modules will be marked as
 tainted, shown with the character 'E'.

 If this is on (ie. "restrictive"), only modules that have a valid
 signature that can be verified by a public key in the kernel's possession
 will be loaded.  All other modules will generate an error.

 Irrespective of the setting here, if the module has a signature block that
 cannot be parsed, it will be rejected out of hand.
(2) "모든 모듈에 자동으로 서명"(CONFIG_MODULE_SIG_ALL)
 If this is on then modules will be automatically signed during the
 modules_install phase of a build.  If this is off, then the modules must
 be signed manually using:
스크립트/서명 파일

(3) "모듈은 어떤 해시 알고리즘으로 서명해야 합니까?"
 This presents a choice of which hash algorithm the installation phase will
 sign the modules with:
CONFIG_MODULE_SIG_SHA1 "SHA-1로 모듈 서명" CONFIG_MODULE_SIG_SHA224 "SHA-224로 모듈 서명" CONFIG_MODULE_SIG_SHA256 "SHA-256으로 모듈 서명" CONFIG_MODULE_SIG_SHA384 "SHA-384로 모듈 서명" CONFIG_MODULE_SIG_SHA512 "서명 SHA-512가 포함된 모듈"
 The algorithm selected here will also be built into the kernel (rather
 than being a module) so that modules signed with that algorithm can have
 their signatures checked without causing a dependency loop.
(4) "모듈 서명 키의 파일 이름 또는 PKCS#11 URI"(CONFIG_MODULE_SIG_KEY)
 Setting this option to something other than its default of
 "certs/signing_key.pem" will disable the autogeneration of signing keys
 and allow the kernel modules to be signed with a key of your choosing.
 The string provided should identify a file containing both a private key
 and its corresponding X.509 certificate in PEM form, or — on systems where
 the OpenSSL ENGINE_pkcs11 is functional — a PKCS#11 URI as defined by
 RFC7512. In the latter case, the PKCS#11 URI should reference both a
 certificate and a private key.

 If the PEM file containing the private key is encrypted, or if the
 PKCS#11 token requries a PIN, this can be provided at build time by
 means of the KBUILD_SIGN_PIN variable.
(5) "기본 시스템 키링을 위한 추가 X.509 키"(CONFIG_SYSTEM_TRUSTED_KEYS)
 This option can be set to the filename of a PEM-encoded file containing
 additional certificates which will be included in the system keyring by
 default.
모듈 서명을 활성화하면 서명을 수행하는 도구의 커널 빌드 프로세스에 OpenSSL 개발 패키지에 대한 종속성이 추가됩니다.

======================= 서명 키 생성

서명을 생성하고 확인하려면 암호화 키 쌍이 필요합니다. 개인 키는 서명을 생성하는 데 사용되며 해당 공개 키는 서명을 확인하는 데 사용됩니다. 개인 키는 빌드 중에만 필요하며, 그 후에는 삭제하거나 안전하게 저장할 수 있습니다. 공개 키는 모듈이 로드될 때 서명을 확인하는 데 사용할 수 있도록 커널에 내장됩니다.

정상적인 조건에서 CONFIG_MODULE_SIG_KEY가 기본값에서 변경되지 않은 경우 커널 빌드는 파일에 키 쌍이 없으면 openssl을 사용하여 자동으로 새 키 쌍을 생성합니다.

인증서/signing_key.pem

vmlinux를 빌드하는 동안(키의 공개 부분은 vmlinux에 빌드해야 함) 다음 매개변수를 사용합니다.

certs/x509.genkey

파일(아직 존재하지 않는 경우에도 생성됨)

자신만의 x509.genkey 파일을 제공하는 것이 좋습니다.

특히 x509.genkey 파일에서 req_distinguished_name 섹션을 기본값에서 변경해야 합니다.

[ req_distinguished_name ] #O = 지정되지 않은 회사 CN = 빌드 시간 자동 생성 커널 키 #emailAddress = [이메일 보호됨]

생성된 RSA 키 크기는 다음을 사용하여 설정할 수도 있습니다.

[ 요청 ] default_bits = 4096

Linux 커널 소스 트리의 루트 노드에 있는 x509.genkey 키 생성 구성 파일과 openssl 명령을 사용하여 키 개인/공용 파일을 수동으로 생성할 수도 있습니다. 다음은 공개/개인 키 파일을 생성하는 예입니다.

openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 \ -config x509.genkey -outform PEM -out kernel_key.pem \ -keyout kernel_key.pem

그런 다음 결과 kernel_key.pem 파일의 전체 경로 이름을 CONFIG_MODULE_SIG_KEY 옵션에 지정할 수 있으며, 해당 인증서와 키는 자동 생성된 키 쌍 대신 사용됩니다.

========================= 커널의 공개 키

커널에는 루트가 볼 수 있는 공개 키 링이 포함되어 있습니다. 다음을 통해 볼 수 있는 ".system_keyring"이라는 키링에 있습니다.

[root@deneb ~]# cat /proc/keys ... 223c7853 I------ 1 perm 1f030000 0 0 keyring .system_keyring: 1 302d2d52 I------
1 perm 1f010000 0 0 비대칭 Fedora 커널 서명 키: d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509.RSA a7118079 [] ...

모듈 서명을 위해 특별히 생성된 공개 키 외에도 CONFIG_SYSTEM_TRUSTED_KEYS 구성 옵션에서 참조하는 PEM 인코딩 파일에 신뢰할 수 있는 추가 인증서를 제공할 수 있습니다.

또한 아키텍처 코드는 하드웨어 상점에서 공개 키를 가져와서 (예: UEFI 키 데이터베이스에서) 추가할 수도 있습니다.

마지막으로 다음을 수행하여 추가 공개 키를 추가할 수 있습니다.

keyctl padd asymmetric "" [.system_keyring-ID] <[key-file]

예:

keyctl padd 비대칭 "" 0x223c7853
그러나 커널은 .system_keyring에 키를 추가하는 것만 허용합니다.만약에새 키의 X.509 래퍼는 키가 추가된 시점에 .system_keyring에 이미 있던 키에 의해 유효하게 서명됩니다.

========================= 수동 서명 모듈

모듈에 수동으로 서명하려면 Linux 커널 소스 트리에서 사용할 수 있는 스크립트/서명 파일 도구를 사용하세요. 스크립트에는 4개의 인수가 필요합니다.

해시 알고리즘(예: sha256)

개인 키 파일 이름 또는 PKCS#11 URI

공개 키 파일 이름

서명할 커널 모듈

다음은 커널 모듈에 서명하는 예입니다.

스크립트/서명 파일 sha512 kernel-signkey.priv \ kernel-signkey.x509 module.ko

사용되는 해시 알고리즘은 구성된 것과 일치할 필요는 없지만 그렇지 않은 경우 해시 알고리즘이 커널에 내장되어 있는지 또는 자체 요구 없이 로드될 수 있는지 확인해야 합니다.

개인 키에 암호나 PIN이 필요한 경우 $KBUILD_SIGN_PIN 환경 변수에 제공할 수 있습니다.

============================ 서명된 모듈 및 스트리핑

서명된 모듈에는 끝에 디지털 서명이 추가됩니다. 문자열 "~모듈 서명이 추가되었습니다~." 모듈 파일 끝에는 서명이 있음을 확인하지만 서명이 유효한지 확인하지는 않습니다!

서명된 모듈은 서명이 정의된 ELF 컨테이너 외부에 있으므로 취약합니다. 따라서 서명이 계산되어 첨부되면 제거될 수 없습니다. 전체 모듈은 서명 당시 존재하는 모든 디버그 정보를 포함하여 서명된 페이로드입니다.

====================== 서명된 모듈 로드 중

모듈은 insmod, modprobe, init_module() 또는 finit_module()을 사용하여 로드됩니다. 사용자 공간에서는 처리가 수행되지 않으므로 서명되지 않은 모듈과 똑같습니다. 서명 확인은 모두 커널 내에서 수행됩니다.

======================================== 유효하지 않은 서명 및 서명되지 않은 모듈

CONFIG_MODULE_SIG_FORCE가 활성화되거나 커널 명령줄에 module.sig_enforce=1이 제공되면 커널은 공개 키가 있는 유효하게 서명된 모듈만 로드합니다. 그렇지 않으면 서명되지 않은 모듈도 로드됩니다. 커널에 키가 있지만 서명 불일치가 있는 것으로 판명된 모듈은 로드가 허용되지 않습니다.

구문 분석할 수 없는 서명이 있는 모듈은 거부됩니다.

======================================== 개인 키 관리/보호

개인 키는 모듈에 서명하는 데 사용되므로 바이러스 및 맬웨어는 개인 키를 사용하여 모듈에 서명하고 운영 체제를 손상시킬 수 있습니다. 개인 키는 파기되거나 안전한 위치로 이동되어야 하며 커널 소스 트리의 루트 노드에 보관되어서는 안 됩니다.

Question 2

동일한 드라이버 로딩 문제가 있었습니다. 나는 module.sig_enforce=0grub Linux 커널 명령줄을 통과했습니다.

단계는 다음과 같습니다.

커널 부팅 매개변수를 영구적으로 추가

시스템에 로그인하고 터미널 창(응용→부속품→단말기).
프롬프트 에서 $다음 명령을 입력합니다.
```
sudo gedit /etc/default/grub
```
에서 메시지가 나타나면 비밀번호를 입력하세요 [sudo].

파일이 /etc/default/grub비어 있거나 존재하지 않는 경우 위의 이전 릴리스에 대한 지침을 참조하세요.

편집기 창에서 화살표 키를 사용하여 커서를 시작하는 줄로 이동한 다음 GRUB_CMDLINE_LINUX_DEFAULT해당 줄을 편집하고 단어 뒤의 큰따옴표 안의 텍스트에 매개변수를 추가합니다 quiet splash. 나는 추가했다 module.sig_enforce=0. ( splash새 매개변수를 추가하기 전에 반드시 공백을 추가하십시오 .)
다음을 클릭하세요.구하다단추
편집기 창을 닫습니다.
프롬프트 의 터미널 창에서 $다음을 입력합니다.
```
sudo update-grub
```
시스템을 다시 시작하십시오.

모듈을 로드해 보면 저에게 효과적이었습니다.

Answer

동일한 드라이버 로딩 문제가 있었습니다. 나는 module.sig_enforce=0grub Linux 커널 명령줄을 통과했습니다.

단계는 다음과 같습니다.

커널 부팅 매개변수를 영구적으로 추가

시스템에 로그인하고 터미널 창(응용→부속품→단말기).
프롬프트 에서 $다음 명령을 입력합니다.
```
sudo gedit /etc/default/grub
```
에서 메시지가 나타나면 비밀번호를 입력하세요 [sudo].

파일이 /etc/default/grub비어 있거나 존재하지 않는 경우 위의 이전 릴리스에 대한 지침을 참조하세요.

편집기 창에서 화살표 키를 사용하여 커서를 시작하는 줄로 이동한 다음 GRUB_CMDLINE_LINUX_DEFAULT해당 줄을 편집하고 단어 뒤의 큰따옴표 안의 텍스트에 매개변수를 추가합니다 quiet splash. 나는 추가했다 module.sig_enforce=0. ( splash새 매개변수를 추가하기 전에 반드시 공백을 추가하십시오 .)
다음을 클릭하세요.구하다단추
편집기 창을 닫습니다.
프롬프트 의 터미널 창에서 $다음을 입력합니다.
```
sudo update-grub
```
시스템을 다시 시작하십시오.

모듈을 로드해 보면 저에게 효과적이었습니다.

Question 3

Ubuntu 16.04는 PCI 드라이버 구축을 위해 pci_dma_supported 대신 pci_set_dma_mask를 지원합니다. API를 잘못 사용하면 드라이버를 로드할 때 보안 부팅 키 불일치 오류가 인쇄됩니다.

Answer

Ubuntu 16.04는 PCI 드라이버 구축을 위해 pci_dma_supported 대신 pci_set_dma_mask를 지원합니다. API를 잘못 사용하면 드라이버를 로드할 때 보안 부팅 키 불일치 오류가 인쇄됩니다.

Question 4

커널 v5.4에서는 플래그를 비활성화 MODULE_SIG_FORCE한 다음 커널을 다시 빌드할 수 있습니다.

Answer

커널 v5.4에서는 플래그를 비활성화 MODULE_SIG_FORCE한 다음 커널을 다시 빌드할 수 있습니다.

======== 개요

답변1

======== 개요

========================== 모듈 서명 구성

======================= 서명 키 생성

========================= 커널의 공개 키

========================= 수동 서명 모듈

============================ 서명된 모듈 및 스트리핑

====================== 서명된 모듈 로드 중

======================================== 유효하지 않은 서명 및 서명되지 않은 모듈

======================================== 개인 키 관리/보호

답변2

답변3

답변4

관련 정보