Linux 커널은 설계에 의해 모놀리식입니다. 그러나 각 사용 사례에 필요한 경우 선택적 또는 추가 모듈로 컴파일됩니다. 즉, 동적으로 로드된 커널 모듈을 사용하여 커널 기능을 확장할 수 있습니다. 커널 모듈은 다음을 제공할 수 있습니다.

커널 자체와 마찬가지로 모듈은 동작을 사용자 지정하는 매개 변수를 사용할 수 있습니다. 기본 매개 변수는 대부분의 경우 잘 작동합니다. 커널 모듈과 관련하여 사용자 공간 툴은 다음 작업을 수행할 수 있습니다.

kmod 패키지에서 제공하는 이러한 유틸리티 중 많은 유틸리티는 작업을 수행할 때 모듈 종속성을 고려합니다. 따라서 수동 dependency-tracking이 거의 필요하지 않습니다.

최신 시스템에서 커널 모듈은 필요할 때 다양한 메커니즘에 의해 자동으로 로드됩니다. 그러나 모듈을 수동으로 로드하거나 언로드해야 하는 경우가 있습니다. 예를 들어 기본 기능을 제공할 수 있거나 모듈이 예기치 않게 수행하는 경우 한 모듈이 다른 모듈을보다 우선합니다.

특정 커널 모듈은 때때로 하나 이상의 다른 커널 모듈에 의존합니다. /lib/modules/<KERNEL_VERSION>/modules.dep 파일에는 해당 커널 버전에 대한 전체 커널 모듈 종속 항목이 포함되어 있습니다.

종속성 파일은 kmod 패키지의 일부인 depmod 프로그램으로 생성됩니다. kmod 에서 제공하는 많은 유틸리티에서는 작업을 수행할 때 모듈 종속성을 고려하여 수동 dependency-tracking이 필요하지 않습니다.

다음과 같이 lsmod 명령을 실행하여 현재 커널에 로드된 모든 커널 모듈을 나열할 수 있습니다.

# lsmod
Module                  Size  Used by
tcp_lp                 12663  0
bnep                   19704  2
bluetooth             372662  7 bnep
rfkill                 26536  3 bluetooth
fuse                   87661  3
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_nat_ipv6            13279  1 ip6table_nat
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
[output truncated]

lsmod 출력은 세 개의 열을 지정합니다.

마지막으로 lsmod 출력은 덜 자세한 정보이며 /proc/modules pseudo-file의 콘텐츠보다 상당히 쉽게 읽을 수 있습니다.

modinfo < MODULE_NAME > 명령을 사용하여 커널 모듈에 대한 자세한 정보를 표시할 수 있습니다.

# modinfo e1000e
filename:       /lib/modules/3.10.0-121.el7.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 커널 기능을 확장하는 최적의 방법은 커널 모듈을 로드하는 것입니다. 다음 절차에서는 modprobe 명령을 사용하여 현재 실행 중인 커널에 커널 모듈을 찾아서 로드하는 방법을 설명합니다.

경우에 따라 실행 중인 커널에서 특정 커널 모듈을 언로드해야 합니다. 다음 절차에서는 modprobe 명령을 사용하여 현재 로드된 커널에서 시스템 런타임에서 커널 모듈을 찾아서 언로드하는 방법을 설명합니다.

다음 절차에서는 부팅 프로세스 중에 자동으로 로드되도록 커널 모듈을 구성하는 방법을 설명합니다.

다음 절차에서는 부팅 프로세스 중에 자동으로 로드되지 않도록 커널 모듈을 거부 목록에 추가하는 방법을 설명합니다.

Red Hat Enterprise Linux 7에는 UEFI Secure Boot 기능이 포함되어 있으므로 UEFI Secure Boot가 활성화된 시스템에서 Red Hat Enterprise Linux 7을 설치하고 실행할 수 있습니다. Red Hat Enterprise Linux 7에는 UEFI 시스템에서 Secure Boot를 사용할 필요가 없습니다.

Secure Boot가 활성화된 경우 UEFI 운영 체제 부트 로더, Red Hat Enterprise Linux 커널 및 모든 커널 모듈은 개인 키로 서명되고 해당 공개 키로 인증되어야 합니다. 서명 및 인증되지 않은 경우 시스템은 부팅 프로세스를 완료할 수 없습니다.

Red Hat Enterprise Linux 7 배포에는 다음이 포함됩니다.

또한 서명된 첫 번째 단계 부트 로더와 서명된 커널에는 Red Hat 공개 키가 포함됩니다. 서명된 실행 파일 바이너리 및 임베디드 키를 사용하면 Red Hat Enterprise Linux 7이 UEFI 펌웨어에서 UEFI Secure Boot를 지원하는 시스템의 UEFI 펌웨어에서 제공하는 Microsoft UEFI Secure Boot 인증 기관 키를 설치, 부팅 및 실행할 수 있습니다.

다음 섹션에서 제공되는 정보는 Secure Boot가 활성화된 UEFI 기반 빌드 시스템에서 Red Hat Enterprise Linux 7과 함께 사용하기 위해 개인 빌드 커널 모듈을 자체 서명하는 단계를 설명합니다. 이러한 섹션에서는 공개 키를 커널 모듈을 배포하려는 대상 시스템으로 가져오기 위한 사용 가능한 옵션에 대한 개요도 제공합니다.

커널 모듈에 서명하고 로드하려면 다음을 수행해야 합니다.

# keyctl list %:.system_keyring
3 keys in keyring:
...asymmetric: Red Hat Enterprise Linux Driver Update Program (key 3): bf57f3e87...
...asymmetric: Red Hat Enterprise Linux kernel signing key: 4249689eefc77e95880b...
...asymmetric: Red Hat Enterprise Linux kpatch signing key: 4d38fd864ebe18c5f0b7...

# keyctl list %:.system_keyring
6 keys in keyring:
...asymmetric: Red Hat Enterprise Linux Driver Update Program (key 3): bf57f3e87...
...asymmetric: Red Hat Secure Boot (CA key 1): 4016841644ce3a810408050766e8f8a29...
...asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed...
...asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e...
...asymmetric: Red Hat Enterprise Linux kernel signing key: 4249689eefc77e95880b...
...asymmetric: Red Hat Enterprise Linux kpatch signing key: 4d38fd864ebe18c5f0b7...

# dmesg | grep 'EFI: Loaded cert'
[5.160660] EFI: Loaded cert 'Microsoft Windows Production PCA 2011: a9290239...
[5.160674] EFI: Loaded cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309b...
[5.165794] EFI: Loaded cert 'Red Hat Secure Boot (CA key 1): 4016841644ce3a8...

커널 튜닝 가능 항목은 부팅 시 또는 시스템이 실행되는 동안 필요에 따라 Red Hat Enterprise Linux의 동작을 사용자 지정하는 데 사용됩니다. 일부 하드웨어 매개변수는 부팅 시에만 지정되며 시스템이 실행되면 변경할 수 없지만, 대부분의 경우 필요에 따라 변경하고 다음 부팅 시 영구적으로 설정할 수 있습니다.

커널 튜닝 가능 항목을 수정하는 방법은 세 가지가 있습니다.

튜닝 가능 항목은 커널 sybsystem에 의해 그룹으로 나뉩니다. Red Hat Enterprise Linux 시스템에는 다음과 같은 튜닝 가능 항목이 있습니다.

커널 인수라고도 하는 커널 명령줄 매개 변수는 부팅 시만 Red Hat Enterprise Linux의 동작을 사용자 지정하는 데 사용됩니다.

Linux Kernel Module Source Checker(ksc)는 지정된 커널 모듈에서 허용 목록에 없는 기호를 확인하는 툴입니다. Red Hat 파트너는 Red Hat bugzilla 데이터베이스의 버그를 제출하여 이 툴을 사용하여 화이트리스트 포함에 대한 기호 검토를 요청할 수도 있습니다.

# ksc -k e1000e.ko
Checking against architecture x86_64
Total symbol usage: 165	Total Non white list symbol usage: 74

# ksc -k /path/to/module

Invalid architecture, (Only kernel object files are supported)

'파일 시스템 dax' 또는 'fs dax'로 알려진 파일에 대한 직접 액세스를 사용하면 애플리케이션이 장치에 대한 버퍼 액세스에 페이지 캐시를 사용하지 않고 dax-capable 스토리지 장치에서 데이터를 읽고 쓸 수 있습니다.

이 기능은 'ext4' 또는 'xfs' 파일 시스템을 사용할 때 사용할 수 있으며, -o dax 로 파일 시스템을 마운트하거나 /etc/fstab 의 마운트 항목에 대한 옵션 섹션에 dax 를 추가하여 활성화할 수 있습니다.

코드 예제를 포함한 자세한 내용은 kernel-doc 패키지에서 찾을 수 있으며 /usr/share/doc/kernel-doc-<version>/Documentation/filesystems/dax.txt에 저장됩니다. 여기서 '<version>'은 해당 커널 버전 번호입니다.

메모리 보호 키는 페이지 기반 보호를 시행하기 위한 메커니즘을 제공하지만, 애플리케이션이 보호 도메인을 변경할 때 페이지 테이블을 수정할 필요 없이 메커니즘을 제공합니다. 이는 각 페이지 테이블 항목에서 "보호 키"에 이전에 무시된 4비트를 사용하여 16개의 가능한 키를 지정하여 작동합니다.

메모리 보호 키는 일부 Intel CPU 칩셋의 하드웨어 기능입니다. 프로세서가 이 기능을 지원하는지 확인하려면 /proc/cpuinfo에 pku 가 있는지 확인하십시오.

$ grep pku /proc/cpuinfo

이 기능을 지원하기 위해 CPU는 각 키에 대해 두 개의 개별 비트(Access Disable 및 Write Disable)를 사용하여 새 사용자 액세스 레지스터(PKRU)를 제공합니다. 새로운 레지스터를 읽고 쓰는 두 가지 새로운 명령 (RDPKRU 및 WRPKRU)이 있습니다.

프로그래밍 예제를 포함한 추가 문서는 kernel-doc 패키지에서 제공하는 /usr/share/doc/kernel-doc-*/Documentation/x86/protection-keys.txt 에서 확인할 수 있습니다.

Kernel Adress Space Layout Randomization (KASLR)은 Linux 커널의 보안을 개선하기 위해 함께 작동하는 두 부분으로 구성되어 있습니다.

커널 텍스트 자체의 물리적 주소 및 가상 주소는 다른 위치로 임의로 지정됩니다. 커널의 물리적 주소는 64TB 미만의 아무 곳에나 있을 수 있지만 커널의 가상 주소는 [0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffc0000000] 간에 제한되며 1GB 공간입니다.

메모리 관리 KASLR에는 시작 주소가 특정 영역에서 임의의 3개의 섹션이 있습니다. 따라서 KASLR은 커널 주소 공간에 관심 기호가 어디에 있는지 확인하는 데 의존하는 경우 커널 실행을 악의적인 코드로 리디렉션하는 것을 방지할 수 있습니다.

메모리 관리 KASLR 섹션은 다음과 같습니다.

KASLR 코드는 이제 Linux 커널로 컴파일되며 기본적으로 활성화되어 있습니다. 명시적으로 비활성화하려면 nokaslr 커널 옵션을 커널 명령줄에 추가합니다.

Red Hat Enterprise Linux에는 다음과 같은 커널 패키지가 포함되어 있습니다.

커널을 업그레이드하기 전에 몇 가지 준비 단계를 수행하는 것이 좋습니다.

먼저 문제가 발생할 경우 시스템에 대해 부팅 미디어가 작동하는지 확인합니다. 부트 로더가 새 커널을 부팅하도록 제대로 구성되지 않은 경우 이 미디어를 사용하여 Red Hat Enterprise Linux로 부팅할 수 있습니다.

USB 미디어에는 종종 펜 드라이브,엄지상 디스크 또는 키가 외부에 연결된 하드 디스크 장치라고도 하는 플래시 장치 형태가 있습니다. 이 유형의 거의 모든 미디어가 VFAT 파일 시스템으로 포맷됩니다. ext2,ext3,ext4 또는 VFAT 으로 포맷된 미디어에서 부팅 가능한 USB 미디어를 만들 수 있습니다.

배포 이미지 파일 또는 최소 부팅 미디어 이미지 파일을 USB 미디어에 전송할 수 있습니다. 장치에서 사용 가능한 공간이 충분한지 확인합니다. 배포 DVD 이미지, 배포 CD 이미지의 경우 약 4GB 또는 최소 부팅 미디어 이미지에는 약 10MB가 필요합니다.

Red Hat Enterprise Linux 설치 DVD에서 boot.iso 파일 사본이나 CD-ROM #1을 설치해야 하며 VFAT 파일 시스템 및 약 16MB의 여유 공간으로 포맷된 USB 스토리지 장치가 필요합니다.

USB 스토리지 장치를 사용하는 방법에 대한 자세한 내용은 USB 키를 포맷 하는 방법과 그래픽이 아닌 환경 솔루션 문서에 USB 플래시 드라이브를 수동으로 마운트하는 방법을 검토하십시오.

다음 절차는 사용자가 복사한 파일과 동일한 경로 이름이 없는 한 USB 스토리지 장치의 기존 파일에는 영향을 미치지 않습니다. USB 부팅 미디어를 생성하려면 root 사용자로 다음 명령을 수행합니다.

또는 플로피 드라이브가 있는 시스템에서 를 설치하여 부트 디스켓을 만들 수 있습니다. mkbootdisk root 로 mkbootdisk 명령을 패키징하고 실행합니다. 사용 정보는 패키지를 설치한 후 man mkbootdisk man 페이지를 참조하십시오.

설치된 커널 패키지를 확인하려면 쉘 프롬프트에서 yum list installed "kernel-*" 명령을 실행합니다. 출력은 시스템의 아키텍처에 따라 다음 패키지의 일부 또는 모두로 구성되며 버전 번호는 다를 수 있습니다.

# yum list installed "kernel-*"
kernel.x86_64                   3.10.0-54.0.1.el7           @rhel7/7.0
kernel-devel.x86_64             3.10.0-54.0.1.el7           @rhel7
kernel-headers.x86_64           3.10.0-54.0.1.el7           @rhel7/7.0

출력에서 커널 업그레이드에 대해 다운로드해야 하는 패키지를 확인합니다. 단일 프로세서 시스템의 경우 필요한 유일한 패키지는 입니다. kernel 패키지. 다양한 패키지에 대한 설명은 5.1절. “커널 패키지 개요” 을 참조하십시오.

시스템에서 업데이트된 커널을 사용할 수 있는지 확인하는 방법은 여러 가지가 있습니다.

if yum Red Hat Network에서 업데이트된 커널을 다운로드하여 설치하는 데 사용되었으며 5.5절. “초기 RAM 파일 시스템 이미지 확인” 및 5.6절. “부트 로더 확인” 의 지침에 따라 기본적으로 부팅 할 커널을 변경하지 마십시오. Red Hat Network는 기본 커널을 최신 버전으로 자동 변경합니다. 커널을 수동으로 설치하려면 5.4절. “업그레이드 수행” 계속하십시오.

필요한 모든 패키지를 검색한 후 기존 커널을 업그레이드해야 합니다.

쉘 프롬프트에서 커널 RPM 패키지가 포함된 디렉터리로 변경합니다. rpm 명령과 함께 -i 인수를 사용하여 이전 커널을 유지합니다. 부트 로더 문제가 생성되는 현재 설치된 커널을 덮어쓰므로 -U 옵션을 사용하지 마십시오. 예를 들어 다음과 같습니다.

# rpm -ivh kernel-kernel_version.arch.rpm

다음 단계는 초기 RAM 파일 시스템 이미지가 생성되었는지 확인하는 것입니다. 자세한 내용은 5.5절. “초기 RAM 파일 시스템 이미지 확인” 를 참조하십시오.

초기 RAM 파일 시스템 이미지의 작업은 IDE, SCSI 또는 RAID와 같은 블록 장치 모듈을 사전 로드하여 해당 모듈이 일반적으로 상주하는 루트 파일 시스템을 그런 다음 액세스하고 마운트할 수 있도록 하는 것입니다. Red Hat Enterprise Linux 7 시스템에서 새 커널이 둘 중 하나를 사용하여 설치될 때마다 Yum, PackageKit또는 RPM 패키지 관리자, Dracut utility는 항상 initramfs 를 생성하기 위해 설치 스크립트에 의해 호출됩니다(initial RAM 파일 시스템 이미지).

/etc/sysctl.conf 파일이나 다른 sysctl 구성 파일을 수정하여 커널 속성을 변경하고 변경된 설정이 부팅 프로세스 초기에 사용된 경우 dracut -f 명령을 실행하여 Initial RAM File System Image를 다시 빌드해야 할 수 있습니다. 예를 들어 네트워킹과 관련된 변경 사항이 있고 네트워크 연결 스토리지에서 부팅되는 경우입니다.

IBM eServer System i( “IBM eServer System i에서 초기 RAM 파일 시스템 이미지 및 커널 확인”참조) 이외의 모든 아키텍처에서 dracut 명령을 실행하여 initramfs 를 생성할 수 있습니다. 그러나 일반적으로 initramfs 를 수동으로 생성할 필요는 없습니다. 이 단계는 커널 및 관련 패키지가 Red Hat에서 배포하는 RPM 패키지에서 설치되거나 업그레이드되는 경우 자동으로 수행됩니다.

다음 절차에 따라 현재 커널 버전에 해당하는 initramfs 가 존재하고 grub.cfg 구성 파일에 올바르게 지정되었는지 확인할 수 있습니다.

IBM eServer System i에서 초기 RAM 파일 시스템 이미지 및 커널 확인

IBM eServer System i 시스템에서 초기 RAM 파일 시스템 및 커널 파일이 addRamDisk 명령으로 생성되는 단일 파일로 결합됩니다. 이 단계는 커널 및 관련 패키지가 Red Hat에서 배포한 RPM 패키지에서 설치 또는 업그레이드되므로 수동으로 실행할 필요가 없습니다. 이 파일이 생성되었는지 확인하려면 root 로 다음 명령을 실행하여 /boot/vmlinitrd-kernel_version 파일이 이미 있는지 확인합니다.

# ls -l /boot/

kernel_version 이 방금 설치된 커널 버전과 일치해야 합니다.

초기 RAM 파일 시스템 이미지의 변경 사항 다시 확인

예를 들어 시스템을 잘못 구성하고 더 이상 부팅하지 않는 경우 다음 절차에 따라 초기 RAM 파일 시스템 이미지에 대한 변경 사항을 취소해야 하는 경우도 있습니다.

예를 들어 sysctl.conf 파일에 vm.nr_hugepages 를 잘못 설정한 경우 위의 절차가 유용할 수 있습니다. sysctl.conf 파일은 initramfs 에 포함되어 있기 때문에 새 vm.nr_hugepages 설정이 initramfs 에 적용되며 이로 인해 initramfs가 다시 작성됩니다. 그러나 설정이 올바르지 않으므로 새 initramfs 가 손상되고 새로 빌드된 커널이 부팅되지 않으므로 위 절차를 사용하여 설정을 수정해야 합니다.

초기 RAM 파일 시스템 이미지의 콘텐츠 나열

initramfs 에 포함된 파일을 나열하려면 root로 다음 명령을 실행합니다.

# lsinitrd

/etc 디렉토리에 있는 파일만 나열하려면 다음 명령을 사용합니다.

# lsinitrd | grep etc/

현재 커널의 initramfs 에 저장된 특정 파일의 내용을 출력하려면 -f 옵션을 사용합니다.

# lsinitrd -f filename

예를 들어 sysctl.conf 의 내용을 출력하려면 다음 명령을 사용합니다.

# lsinitrd -f /etc/sysctl.conf

커널 버전을 지정하려면 --kver 옵션을 사용합니다.

# lsinitrd --kver kernel_version -f /etc/sysctl.conf

예를 들어 커널 버전 3.10.0-327.10.1.el7.x86_64에 대한 정보를 나열하려면 다음 명령을 사용합니다.

# lsinitrd --kver 3.10.0-327.10.1.el7.x86_64 -f /etc/sysctl.conf

yum 명령을 사용하거나 rpm 명령을 사용하여 커널을 설치할 수 있습니다.

rpm 을 사용하여 커널을 설치할 때 커널 패키지는 해당 새 커널의 부트 로더 구성 파일에 항목을 생성합니다.

두 명령 모두 /etc/sysconfig/kernel 구성 파일에 다음 설정을 포함하는 경우에만 기본 커널로 부팅되도록 새 커널을 구성합니다.

DEFAULTKERNEL=kernel
UPDATEDEFAULT=yes

DEFAULTKERNEL 옵션은 기본 커널 패키지 유형을 지정합니다. UPDATEDEFAULT 옵션은 새 커널 패키지가 새 커널을 기본값으로 만들지 여부를 지정합니다.

kpatch 유틸리티는 Red Hat 리포지토리에서 제공하는 RPM 모듈을 사용하여 Red Hat에서 지원하는 유일한 커널 라이브 패치 유틸리티입니다. Red Hat은 Red Hat 자체에서 제공하지 않은 실시간 패치를 지원하지 않습니다.

타사 라이브 패치를 지원하는 경우 패치를 제공한 공급 업체에 문의하십시오.

타사 라이브 패치로 실행되는 모든 시스템의 경우 Red Hat은 Red Hat 제품 및 지원 소프트웨어를 사용하여 재생을 요청할 수 있는 권한을 보유합니다. 이것이 가능하지 않은 경우 동일한 동작이 관찰되는지 확인하기 위해 실시간 패치를 적용하지 않고 테스트 환경에 유사한 시스템과 워크로드를 배포해야 합니다.

타사 소프트웨어 지원 정책에 대한 자세한 내용은 Red Hat 글로벌 지원 서비스에서 타사 소프트웨어, 드라이버 및/또는 인증되지 않은 하드웨어/하이퍼 바이저 또는 게스트 운영 체제를 처리하는 방법을참조하십시오.

커널 라이브 패치 기능은 RPM 패키지로 제공되는 커널 모듈(.ko 파일)으로 구현됩니다.

모든 고객은 일반적인 채널을 통해 제공되는 커널 라이브 패치에 액세스할 수 있습니다. 그러나 연장된 지원 제공을 서브스크립션하지 않은 고객은 다음 마이너 릴리스가 출시되면 현재 마이너 릴리스의 새 패치에 액세스할 수 없습니다. 예를 들어 표준 서브스크립션이 있는 고객은 RHEL 8.3이 릴리스될 때까지만 RHEL 8.2 커널을 패치할 수 있습니다.

커널 라이브 패치의 구성 요소는 다음과 같습니다.

kpatch 커널 패치 솔루션에서는 라이브 패치 커널 하위 시스템을 사용하여 이전 기능을 새 기능으로 리디렉션합니다. 라이브 커널 패치가 시스템에 적용되면 다음과 같은 일이 발생합니다.

그림 6.1. 커널 라이브 패치 작동 방식

커널 패치 모듈은 패치되는 커널 버전과 관련된 RPM 패키지로 제공됩니다. 각 RPM 패키지는 시간이 지남에 따라 누적 업데이트됩니다.

다음 하위 섹션에서는 지정된 커널에 대한 모든 누적 라이브 패치 업데이트를 수신하는 방법을 설명합니다.

커널 패치 모듈이 RPM 패키지를 통해 전달 및 적용되므로 누적 커널 패치 모듈을 업데이트하는 것은 다른 RPM 패키지를 업데이트하는 것과 같습니다.

사전 요구 사항

절차

추가 리소스

시스템 관리자가 Red Hat Enterprise Linux 커널 라이브 패치와 연결된 예기치 않은 부정적인 영향을 미치는 경우 이를 통해 메커니즘을 비활성화할 수 있습니다. 다음 섹션에서는 라이브 패치 솔루션을 비활성화하는 방법에 대해 설명합니다.

커널 드라이버의 블랙리스트 지정은 커널 드라이버가 로드되고 사용되지 않도록 하는 메커니즘입니다. /etc/sysconfig/kdump 파일에 드라이버를 추가하여 kdump initramfs 가 블랙리스트 모듈을 로드하지 못하도록 합니다.

커널 드라이버를 블랙리스트로 지정하면 oom 킬러 또는 기타 충돌 커널 오류가 발생하지 않습니다. 커널 드라이버를 블랙리스트로 지정하려면 /etc/sysconfig/kdump 파일에서 KDUMP_COMMANDLINE_APPEND= 변수를 업데이트하고 다음 블랙리스트 옵션 중 하나를 지정할 수 있습니다.

설정을 테스트하려면 kdump 가 활성화된 시스템을 재부팅하고 서비스가 실행 중인지 확인합니다.

~]# systemctl is-active kdump
active

쉘 프롬프트에 다음 명령을 입력합니다.

echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger

이렇게 하면 Linux 커널이 충돌하게 되며 주소-YYYY-MM-DD-HH:MM:SS/vmcore 파일이 구성에서 선택한 위치에 복사됩니다(즉, 기본적으로 /var/crash/ 로 변경).

시스템 충돌의 원인을 확인하려면 다음을 사용하십시오. crash GDB(GNU Debugger)와 매우 유사한 대화형 프롬프트를 제공하는 유틸리티. 이 유틸리티를 사용하면 netdump,diskdump,xendump 또는 kdump 로 생성된 코어 덤프뿐만 아니라 실행 중인 Linux 시스템을 대화형으로 분석할 수 있습니다.

yum install crash

debuginfo-install kernel

crash /usr/lib/debug/lib/modules/<kernel>/vmlinux \ /var/crash/<timestamp>/vmcore

~]# crash /usr/lib/debug/lib/modules/2.6.32-69.el6.i686/vmlinux \
/var/crash/127.0.0.1-2010-08-25-08:45:02/vmcore

crash 5.0.0-23.el6
Copyright (C) 2002-2010  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...

      KERNEL: /usr/lib/debug/lib/modules/2.6.32-69.el6.i686/vmlinux
    DUMPFILE: /var/crash/127.0.0.1-2010-08-25-08:45:02/vmcore  [PARTIAL DUMP]
        CPUS: 4
        DATE: Wed Aug 25 08:44:47 2010
      UPTIME: 00:09:02
LOAD AVERAGE: 0.00, 0.01, 0.00
       TASKS: 140
    NODENAME: hp-dl320g5-02.lab.bos.redhat.com
     RELEASE: 2.6.32-69.el6.i686
     VERSION: #1 SMP Tue Aug 24 10:31:45 EDT 2010
     MACHINE: i686  (2394 Mhz)
      MEMORY: 8 GB
       PANIC: "Oops: 0002 [#1] SMP " (check log for details)
         PID: 5591
     COMMAND: "bash"
        TASK: f196d560  [THREAD_INFO: ef4da000]
         CPU: 2
       STATE: TASK_RUNNING (PANIC)

crash>

crash> log
... several lines omitted ...
EIP: 0060:[<c068124f>] EFLAGS: 00010096 CPU: 2
EIP is at sysrq_handle_crash+0xf/0x20
EAX: 00000063 EBX: 00000063 ECX: c09e1c8c EDX: 00000000
ESI: c0a09ca0 EDI: 00000286 EBP: 00000000 ESP: ef4dbf24
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process bash (pid: 5591, ti=ef4da000 task=f196d560 task.ti=ef4da000)
Stack:
 c068146b c0960891 c0968653 00000003 00000000 00000002 efade5c0 c06814d0
<0> fffffffb c068150f b7776000 f2600c40 c0569ec4 ef4dbf9c 00000002 b7776000
<0> efade5c0 00000002 b7776000 c0569e60 c051de50 ef4dbf9c f196d560 ef4dbfb4
Call Trace:
 [<c068146b>] ? __handle_sysrq+0xfb/0x160
 [<c06814d0>] ? write_sysrq_trigger+0x0/0x50
 [<c068150f>] ? write_sysrq_trigger+0x3f/0x50
 [<c0569ec4>] ? proc_reg_write+0x64/0xa0
 [<c0569e60>] ? proc_reg_write+0x0/0xa0
 [<c051de50>] ? vfs_write+0xa0/0x190
 [<c051e8d1>] ? sys_write+0x41/0x70
 [<c0409adc>] ? syscall_call+0x7/0xb
Code: a0 c0 01 0f b6 41 03 19 d2 f7 d2 83 e2 03 83 e0 cf c1 e2 04 09 d0 88 41 03 f3 c3 90 c7 05 c8 1b 9e c0 01 00 00 00 0f ae f8 89 f6 <c6> 05 00 00 00 00 01 c3 89 f6 8d bc 27 00 00 00 00 8d 50 d0 83
EIP: [<c068124f>] sysrq_handle_crash+0xf/0x20 SS:ESP 0068:ef4dbf24
CR2: 0000000000000000

crash> bt
PID: 5591   TASK: f196d560  CPU: 2   COMMAND: "bash"
 #0 [ef4dbdcc] crash_kexec at c0494922
 #1 [ef4dbe20] oops_end at c080e402
 #2 [ef4dbe34] no_context at c043089d
 #3 [ef4dbe58] bad_area at c0430b26
 #4 [ef4dbe6c] do_page_fault at c080fb9b
 #5 [ef4dbee4] error_code (via page_fault) at c080d809
    EAX: 00000063  EBX: 00000063  ECX: c09e1c8c  EDX: 00000000  EBP: 00000000
    DS:  007b      ESI: c0a09ca0  ES:  007b      EDI: 00000286  GS:  00e0
    CS:  0060      EIP: c068124f  ERR: ffffffff  EFLAGS: 00010096
 #6 [ef4dbf18] sysrq_handle_crash at c068124f
 #7 [ef4dbf24] __handle_sysrq at c0681469
 #8 [ef4dbf48] write_sysrq_trigger at c068150a
 #9 [ef4dbf54] proc_reg_write at c0569ec2
#10 [ef4dbf74] vfs_write at c051de4e
#11 [ef4dbf94] sys_write at c051e8cc
#12 [ef4dbfb0] system_call at c0409ad5
    EAX: ffffffda  EBX: 00000001  ECX: b7776000  EDX: 00000002
    DS:  007b      ESI: 00000002  ES:  007b      EDI: b7776000
    SS:  007b      ESP: bfcb2088  EBP: bfcb20b4  GS:  0033
    CS:  0073      EIP: 00edc416  ERR: 00000004  EFLAGS: 00000246

crash> ps
   PID    PPID  CPU   TASK    ST  %MEM     VSZ    RSS  COMM
>     0      0   0  c09dc560  RU   0.0       0      0  [swapper]
>     0      0   1  f7072030  RU   0.0       0      0  [swapper]
      0      0   2  f70a3a90  RU   0.0       0      0  [swapper]
>     0      0   3  f70ac560  RU   0.0       0      0  [swapper]
      1      0   1  f705ba90  IN   0.0    2828   1424  init
... several lines omitted ...
   5566      1   1  f2592560  IN   0.0   12876    784  auditd
   5567      1   2  ef427560  IN   0.0   12876    784  auditd
   5587   5132   0  f196d030  IN   0.0   11064   3184  sshd
>  5591   5587   2  f196d560  RU   0.0    5084   1648  bash

crash> vm
PID: 5591   TASK: f196d560  CPU: 2   COMMAND: "bash"
   MM       PGD      RSS    TOTAL_VM
f19b5900  ef9c6000  1648k    5084k
  VMA       START      END    FLAGS  FILE
f1bb0310    242000    260000 8000875  /lib/ld-2.12.so
f26af0b8    260000    261000 8100871  /lib/ld-2.12.so
efbc275c    261000    262000 8100873  /lib/ld-2.12.so
efbc2a18    268000    3ed000 8000075  /lib/libc-2.12.so
efbc23d8    3ed000    3ee000 8000070  /lib/libc-2.12.so
efbc2888    3ee000    3f0000 8100071  /lib/libc-2.12.so
efbc2cd4    3f0000    3f1000 8100073  /lib/libc-2.12.so
efbc243c    3f1000    3f4000 100073
efbc28ec    3f6000    3f9000 8000075  /lib/libdl-2.12.so
efbc2568    3f9000    3fa000 8100071  /lib/libdl-2.12.so
efbc2f2c    3fa000    3fb000 8100073  /lib/libdl-2.12.so
f26af888    7e6000    7fc000 8000075  /lib/libtinfo.so.5.7
f26aff2c    7fc000    7ff000 8100073  /lib/libtinfo.so.5.7
efbc211c    d83000    d8f000 8000075  /lib/libnss_files-2.12.so
efbc2504    d8f000    d90000 8100071  /lib/libnss_files-2.12.so
efbc2950    d90000    d91000 8100073  /lib/libnss_files-2.12.so
f26afe00    edc000    edd000 4040075
f1bb0a18   8047000   8118000 8001875  /bin/bash
f1bb01e4   8118000   811d000 8101873  /bin/bash
f1bb0c70   811d000   8122000 100073
f26afae0   9fd9000   9ffa000 100073
... several lines omitted ...

crash> files
PID: 5591   TASK: f196d560  CPU: 2   COMMAND: "bash"
ROOT: /    CWD: /root
 FD    FILE     DENTRY    INODE    TYPE  PATH
  0  f734f640  eedc2c6c  eecd6048  CHR   /pts/0
  1  efade5c0  eee14090  f00431d4  REG   /proc/sysrq-trigger
  2  f734f640  eedc2c6c  eecd6048  CHR   /pts/0
 10  f734f640  eedc2c6c  eecd6048  CHR   /pts/0
255  f734f640  eedc2c6c  eecd6048  CHR   /pts/0

crash> exit
~]#

클러스터형 환경에서 Kdump를 사용하려면 어떤 고려 사항을 수행해야 합니까?

RHEL 6, 7 고가용성 애드온과 함께 사용할 수 있도록 kdump를 구성하려면 어떻게 해야 합니까?에서는 고가용성 애드온 을 사용하여 시스템 관리자가 사용할 수 있는 옵션을 보여줍니다.

초기 부팅 과정에서 kdump가 실패합니다. 부팅 로그를 캡처하는 방법은 무엇입니까?

두 번째 커널을 부팅하는 데 문제가 있는 경우 초기 부팅 로그를 검토해야 합니다. 이러한 부팅은 영향을 받는 시스템에 직렬 콘솔을 활성화하여 얻을 수 있습니다.

RHEL7에서 직렬 콘솔을 설정하려면 어떻게 해야 합니까? 는 초기 부팅 메시지에 대한 액세스를 활성화하는 데 필요한 구성을 보여줍니다.

디버깅을 위해 makedumpfile에서 메시징을 늘리려면 어떻게 해야 합니까?

makedumpfile 이 실패하는 경우 로그 수준을 높여 무엇이 잘못되는지 파악해야 합니다. 이는 덤프 수준을 설정하는 것과 다르며 /etc/kdump.conf 를 편집하고 core_collector 행 항목에서 dumpfile을 만들기 위해 message_level 옵션을 늘려서 달성됩니다.

기본적으로 makedumpfile 은 출력 출력 내용을 진행률 표시로 제한하는 level 1로 설정됩니다. 이 메시지 수준을 31로 설정하여 모든 디버깅 정보를 활성화합니다. 메시지 수준 31은 진행 상태 표시, 일반적인 메시지, 오류 메시지, 디버그 메시지 및 보고서 메시지에 대한 세부 정보를 출력합니다.

설정된 경우 core_collector 구성 줄이 다음과 유사하게 표시되는지 확인합니다.

core_collector makedumpfile -l --message-level 1 -d 31

Dracut을 어떻게 디버깅할 수 있습니까?

때로는 dracut 이 initramfs를 빌드하지 못할 수 있습니다. 이 경우 문제를 격리하려면 dracut 에서 로그 수준을 늘립니다.

/etc/kdump.conf 를 편집하고 필요한 다른 dracut 인수 외에 -L 5 옵션을 포함하도록 dracut_args 행을 변경합니다.

dracut_args 에 다른 옵션이 구성되어 있지 않은 경우 결과는 다음과 유사합니다.

dracut_args -L 5

가상 머신에 사용할 수 있는 덤프 방법은 무엇입니까?

대부분의 경우, kdump 메커니즘은 충돌 또는 패닉 발생 후 시스템에서 메모리 덤프를 얻는 데 충분합니다. 이는 베어 메탈에 설치와 동일한 방식으로 설정할 수 있습니다.

그러나 크래시 덤프를 얻으려면 하이퍼바이저와 직접 작업해야 하는 경우도 있습니다. 이 작업을 수행하기 위해 libvirt 에서 사용할 수 있는 두 가지 메커니즘은 pvpanic 및 virsh dump 입니다. 이러한 두 가지 방법은 모두 가상화 배포 및 관리 가이드에서 설명합니다.

pvpanic 메커니즘은 가상화 배포 및 관리 가이드 - 창에서 장치 설정을 참조하십시오.

virsh dump 명령은 가상화 배포 및 관리 가이드 - 도메인 코어의 덤프 파일 생성에 설명되어 있습니다.

Red Hat 지원 서비스에 대용량 덤프 파일을 업로드하려면 어떻게 해야 합니까?

경우에 따라 분석을 위해 커널 크래시 덤프 파일을 Red Hat 글로벌 지원 서비스로 보내야 할 수도 있습니다. 그러나 덤프 파일은 필터링 된 후에도 매우 클 수 있습니다. 새 지원 케이스를 열 때 250MB보다 큰 파일은 Red Hat 고객 포털을 통해 직접 업로드할 수 없으므로 Red Hat은 대용량 파일을 업로드하기 위해 FTP 서버를 제공합니다.

FTP 서버의 주소는 dropbox.redhat.com 이며 파일은 /incoming/ 디렉토리에 업로드됩니다. FTP 클라이언트를 패시브 모드로 설정해야 합니다. 방화벽에서 이 모드를 허용하지 않는 경우 활성 모드를 사용하여 origin-dropbox.redhat.com 서버를 사용하십시오.

업로드 된 파일이 다음과 같은 프로그램을 사용하여 압축되어 있는지 확인하십시오. gzip 그리고 적절하고 설명적으로 이름이 지정되어 있습니다. 파일 이름에 지원 케이스 번호를 사용하는 것이 좋습니다. 필요한 모든 파일을 성공적으로 업로드한 후 정확한 파일 이름과 SHA1 또는 MD5 체크섬을 사용하여 지원 케이스를 담당 엔지니어를 제공하십시오.

자세한 내용은 Red Hat 지원에 파일을 제공하는 방법을 참조하십시오.

크래시 덤프를 완료하는 데 시간이 얼마나 필요합니까?

종종 덤프를 완료하는 데 걸리는 시간을 확인하기 위해 재해 복구 계획의 목적을 위해 필요합니다. 그러나 걸리는 시간은 디스크에 복사되는 메모리 양과 RAM과 스토리지 간의 인터페이스 속도에 따라 크게 달라집니다.

타이밍 테스트의 경우 대표적 로드 하에서 시스템이 작동해야 합니다. 그렇지 않으면 페이지 제외 선택 사항이 완전히 로드된 프로덕션 시스템과 함께 kdump 동작에 대한 잘못된 보기를 제공할 수 있습니다. 이러한 불일치는 특히 대량의 RAM과 함께 작업할 때 존재합니다.

또한 덤프할 시간을 평가할 때 계획에서 스토리지 인터페이스를 고려합니다. 예를 들어 네트워크 제약 조건으로 인해 ssh 를 통해 덤프하는 연결에서 로컬로 연결된 SATA 디스크보다 완료하는 데 시간이 오래 걸릴 수 있습니다.

설치 중에 Kdump가 어떻게 구성되어 있습니까?

다음을 구성할 수 있습니다. kdump Kickstart의 옵션 세트 또는 대화형 GUI를 사용하여 설치하는 동안.

The kdump 를 사용한 구성 anaconda 설치 GUI는 설치 가이드의 KDUMP 섹션에 설명되어 있습니다.

The kickstart 구문은 다음과 같습니다.

%addon com_redhat_kdump [--disable,enable] [--reserve-mb=[auto,value]]
%end

Kickstart에 대한 이 애드온을 사용하면 kdump 기능을 비활성화하거나 활성화할 수 있으며 선택적으로 auto의 기본 옵션(전체 스위치가 생략되는 경우) 또는 메가바이트 단위로 숫자 값을 지정하여 예약된 메모리 크기를 정의할 수 있습니다.

Kickstart를 사용하여 시스템 배포를 자동화하는 방법을 알아보려면 설치 가이드에서 Kickstart 설치를 참조하십시오.

Kickstart 애드온 구문에 대한 자세한 내용은 설치 가이드의 Kickstart 구문 참조 를 참조하십시오.

Portal Labs 는 시스템 관리자가 여러 시스템 작업을 수행하는 데 도움이 되는 작은 웹 애플리케이션입니다. 현재 Kdump에 대한 두 가지 랩이 있습니다. Kdump Helper 및 커널 Oops Analyzer.

무결성 하위 시스템은 시스템의 데이터 무결성을 유지 관리하는 커널의 일부입니다. 이 하위 시스템은 사용자가 특정 시스템 파일을 원치 않는 변경을 방지하여 시스템을 초기 상태로 유지하는 데 도움이 됩니다.

커널 무결성 하위 시스템은 다음 두 가지 주요 구성 요소로 구성됩니다.

IMA 및 EVM 모두 추가 기능을 가져오는 다양한 기능 확장 기능이 포함되어 있습니다. 예를 들어 다음과 같습니다.

커널 무결성 하위 시스템은 신뢰할 수 있는 플랫폼 모듈(TPM)을 사용하여 시스템 보안을 더욱 강화할 수 있습니다. TPM은 중요한 암호화 기능에 대한 Trusted Computing Group(TCG)의 사양입니다. TPM은 일반적으로 플랫폼의 마더보드에 연결된 전용 하드웨어로 구현되며 하드웨어 칩의 보호 및 변조 영역에서 암호화 기능을 제공하여 소프트웨어 기반 공격을 방지합니다. TPM 기능 중 일부는 다음과 같습니다.

IMA(Integrity Measurement Architecture)는 커널 무결성 하위 시스템의 구성 요소입니다. IMA는 액세스 하기 전에 파일의 해시를 측정, 저장 및 앱 올리는 방식으로 로컬 파일의 내용을 유지 하는 것을 목표로 합니다. 이렇게 하면 신뢰할 수 없는 데이터의 읽기 및 실행을 방지하고 시스템 보안이 향상됩니다.

EVM(Extended Verification Module)은 파일의 확장 속성(xattr)의 변경 사항을 모니터링하는 커널 무결성 하위 시스템의 구성 요소입니다. 무결성 측정 아키텍처(IMA( Integrity Measurement Architecture)를 포함한 많은 보안 지향 기술은 콘텐츠 해시와 같은 중요한 파일 정보를 확장된 특성에 저장합니다. EVM은 이러한 확장 속성과 부팅 시 로드되는 특수 키에서 또 다른 해시를 생성합니다. 확장된 속성이 사용될 때마다 결과 해시의 유효성이 검사됩니다. 예를 들어 IMA에서 파일을 예상하는 경우입니다.

신뢰할 수 있고 암호화된 키는 커널 키링 서비스에서 사용하는 커널에서 생성되는 변수 길이의 대칭 키입니다. 이러한 유형의 키는 암호화되지 않은 형식으로 사용자 공간에 표시되지 않으므로 무결성을 확인할 수 있습니다. 따라서 예를 들어 확장 확인 모듈(EVM)을 사용하여 실행 중인 시스템의 무결성을 확인하고 확인할 수 있습니다. 사용자 수준 프로그램은 암호화된 Blob 형식의 키만 액세스할 수 있습니다.

신뢰할 수 있는 키에는 키를 만들고 암호화(seal)하는 데 사용되는 신뢰할 수 있는 플랫폼 모듈(TPM) 칩의 하드웨어 구성 요소가 필요합니다. TPM은 스토리지 루트 키(SRK)라는 2048비트 RSA 키를 사용하여 키를 봉인합니다.

신뢰할 수 있고 암호화된 키에 대한 자세한 내용은 다음을 참조하십시오. Trusted and Encrypted Keys 섹션 RHEL 7 보안 가이드.

무결성 측정 아키텍처(IMA) 및 EVM(Extended verification module)은 다양한 방식으로 시스템 보안을 향상시키는 커널 무결성 하위 시스템의 구성 요소입니다. IMA 및 EVM을 구성하면 파일에 서명하여 시스템 보안을 강화할 수 있습니다.

무결성 측정 아키텍처(IMA)의 첫 번째 작업 수준은 파일 해시를 생성하고 해당 파일의 확장 속성(xattrs)으로 저장할 수 있는 측정 단계입니다. 다음 섹션에서는 파일 해시를 생성하고 검사하는 방법을 설명합니다.