운영 체제 커널의 불안정성, 적시성 부족, 무결성 문제 및 수동 개입의 필요성으로 인해 Linux 커널 정리 기술은 널리 사용되지 않았습니다. 기존 기술의 한계를 이해한 후, 이러한 문제를 해결할 수 있는 Linux 커널 조정 프레임워크를 제안하려고 합니다.
2000년경, 노년의 코더는 당시 휴대폰 운영체제로 리눅스를 사용하고 싶어 커널 테일러링이라는 아이디어를 내놓고 그 실습을 도왔다. 효과는 꽤 좋았고 이미 PDA에서 휴대폰을 실행할 수 있었습니다. 20년이 넘는 시간이 흐르고 리눅스는 많이 변했고, 커널 프루닝의 기술과 방법도 많이 달라졌습니다.
Linux 커널 프루닝은 대상 애플리케이션에서 불필요한 커널 코드를 줄이는 것으로 보안 및 성능 측면에서 상당한 이점을 제공합니다(빠른 부팅 시간 및 메모리 사용량 감소). 그러나 기존 커널 가지치기 기술에는 한계가 있습니다. 커널 가지치기를 위한 프레임워크 방법이 있습니까?
1. 커널 가지치기 정보
최근 몇 년 동안 Linux 운영 체제는 복잡성과 규모가 커졌습니다. 그러나 애플리케이션에는 일반적으로 OS 기능의 일부만 필요하며 수많은 애플리케이션 요구 사항으로 인해 Linux 커널이 비대해집니다. 운영 체제 커널 팽창은 또한 보안 위험, 부팅 시간 연장, 메모리 사용량 증가로 이어집니다.
서비스화 및 마이크로서비스의 인기로 인해 커널 조정에 대한 필요성이 더욱 높아졌습니다. 이러한 시나리오에서 가상 머신은 작은 애플리케이션을 실행합니다. 각 애플리케이션은 종종 "마이크로"이며 작은 커널 공간을 갖습니다. 일부 가상화 기술은 대상 애플리케이션에 가장 간단한 Linux 커널을 제공합니다.
운영 체제의 복잡성을 고려할 때 커널 기능을 직접 선택하여 커널을 조정하는 것은 다소 비실용적입니다. 예를 들어, Linux에는 14,000개 이상의 구성 옵션(v4.14 기준)이 있으며 매년 수백 개의 새로운 옵션이 도입됩니다. 커널 구성자(예: KConfig)는 구성 옵션을 선택하기 위한 사용자 인터페이스만 제공합니다. 낮은 유용성과 불완전한 문서로 인해 사용자가 최소한의 실용적인 커널 구성을 선택하기는 어렵습니다.
기존 커널 가지치기 기술은 일반적으로 세 단계를 따릅니다.
기존 커널 가지치기 기술에는 다섯 가지 주요 제한 사항이 있습니다.
부팅 단계에서는 보이지 않습니다. 기존 기술은 커널 부팅 후에만 시작하고 ftrace에 의존할 수 있으므로 부팅 단계에서 어떤 커널 코드가 로드되는지 관찰할 방법이 없습니다. 커널에서 중요한 모듈이 누락된 경우 커널이 부팅에 실패하는 경우가 많으며 많은 커널 기능 기능은 부팅 단계를 관찰해야만 캡처할 수 있습니다. 또한 성능 및 보안 문제도 부팅 시에만 로드되므로(예: 멀티 코어 지원을 위한 CONFIGSCHEDMC 및 CONFIGSECURITYNETWORK) 성능과 보안이 저하됩니다.
애플리케이션 배포에 대한 빠른 지원이 부족합니다. 기존 도구를 사용하여 커널에 맞게 조정된 새 애플리케이션을 배포하려면 추적, 분석 및 조립의 세 단계를 완료해야 합니다. 이 프로세스는 시간이 많이 걸리고 몇 시간 또는 며칠이 걸릴 수 있어 애플리케이션 배포의 민첩성을 방해합니다.
입자크기가 더 굵습니다. ftrace를 사용하면 함수 수준의 커널 코드만 추적할 수 있으며, 함수 내 코드에 영향을 미치는 구성 옵션을 추적하기에는 세분성이 너무 낮습니다.
불완전한 적용 범위. 동적 추적이 사용되기 때문에 적용 범위를 최대화하기 위해 커널의 코드 실행을 구동하려면 애플리케이션 워크로드가 필요합니다. 그러나 벤치마크 적용 범위는 까다로우며 애플리케이션에 추적 중에 관찰되지 않는 커널 코드가 있는 경우 잘린 커널이 런타임에 충돌할 수 있습니다.
실행 종속성에는 차이가 없으며 중복이 있을 수 있습니다. 실제로 실행될 필요가 없는 코드라도 커널 기능에 포함될 수 있습니다. 예를 들어 두 번째 파일 시스템을 초기화할 수 있습니다.
처음 세 가지 제한 사항은 극복 가능하며 향상된 설계 및 도구를 통해 해결할 수 있는 반면, 마지막 두 가지 제한 사항은 피할 수 없으며 특정 기술 이상의 노력이 필요합니다.
3.1 구성 옵션
커널 구성은 일련의 구성 옵션으로 구성됩니다. 커널 모듈에는 여러 옵션이 있을 수 있으며 각 옵션은 최종 커널 바이너리에 포함될 코드를 제어합니다. 3.2. 구성 언어 Linux 커널은 KConfig 구성 언어를 사용하여 컴파일된 커널에 포함할 코드를 컴파일러에 지시하여 구성 옵션과 코드 간의 종속성을 정의할 수 있습니다. 3.3. 구성 템플릿 Linux 커널에는 직접 제작한 많은 구성 템플릿이 함께 제공됩니다. 그러나 구성 템플릿의 하드 코딩된 특성과 수동 개입의 필요성으로 인해 다양한 하드웨어 플랫폼에 적응할 수 없으며 애플리케이션의 요구 사항을 이해하지 못합니다. 예를 들어,tinyconfig로 구축된 커널은 다른 응용 프로그램 지원은커녕 표준 하드웨어에서도 부팅할 수 없습니다. 일부 도구는 localmodconfig를 최소 구성으로 취급하지만 localmodconfig에는 정적 구성 템플릿과 동일한 제한 사항이 있으며 제어 문 수준 또는 함수 수준 C 전처리기 구성 옵션을 활성화하지 않으며 로드 가능한 커널 모듈을 처리하지 않습니다. 3.4. 클라우드의 Linux 커널 구성 Linux는 클라우드 서비스에서 지배적인 운영 체제 커널이며, 클라우드 제공업체는 일반 Linux 커널을 어느 정도 포기했습니다. 클라우드 공급업체의 사용자 정의는 로드 가능한 커널 모듈을 직접 제거하여 수행되는 경우가 많습니다. 커널 모듈 바이너리를 수동으로 정리할 때의 문제는 종속성을 위반할 수 있다는 것입니다. 중요한 것은 애플리케이션 요구 사항에 따라 코어를 추가로 맞춤화할 수 있다는 것입니다. 예를 들어, Amazon FireCracker 커널은 HTTPD를 대상 애플리케이션으로 사용하여 서비스로서의 기능을 위해 설계된 작은 가상 머신으로, 향상된 기능과 성능을 보장하면서 커널 조정을 더욱 최소화할 수 있습니다. 4. 커널 가지치기에 대한 생각 제한 사항 1의 경우 QEMU의 명령 수준 추적을 사용하여 부팅 단계 가시성을 확보할 수 있습니까? 이러한 방식으로 커널 코드를 추적하고 커널 구성 옵션에 매핑할 수 있습니다. 부팅 가능한 커널을 생성하려면 부팅 단계가 중요하므로 하이퍼바이저에서 제공하는 추적 기능을 사용하여 엔드투엔드 관찰성을 확보하고 안정적인 커널을 생성하세요. 제한사항 2의 경우, NLP 딥 러닝 경험을 바탕으로 오프라인과 온라인 방법의 조합을 사용할 수 있습니다. 대상 애플리케이션 세트가 주어지면 앱 구성을 오프라인으로 직접 생성한 다음 기본 구성과 결합하여 커널 구성이 완료되면 커널이 잘립니다. 이러한 구성 가능성을 통해 애플리케이션 구성과 이전에 빌드된 파일(예: 커널 모듈)을 재사용하여 새로운 커널을 점진적으로 빌드할 수 있습니다. 대상 애플리케이션의 구성이 알려진 경우 커널 정리는 수십 초 안에 완료될 수 있습니다. 제한 사항 3의 경우 명령 수준 추적을 사용하면 함수의 내부 기능 특성을 제어하는 커널 구성 옵션을 해결할 수 있습니다. 명령 수준 추적의 오버헤드는 테스트 도구 모음 및 성능 벤치마크를 실행하는 데 허용됩니다. 제한 사항 4와 관련하여 동적 추적 사용의 기본 제한 사항은 테스트 도구 모음 및 벤치마크의 불완전성입니다. 많은 오픈 소스 애플리케이션 테스트 도구 모음의 코드 적용 범위가 낮습니다. 다양한 워크로드를 결합하여 애플리케이션을 구동하면 이러한 제한을 어느 정도 완화할 수 있습니다. 제한 사항 5의 경우, 기본 커널에서 실행되지만 실제 배포가 실행될 때 필요하지 않은 커널 모듈을 제거하여 도메인별 정보를 사용하여 커널을 추가로 로드할 수 있습니다. Xen 및 KVM을 예로 들면 xenconfig 및 kvmconfig 구성 템플릿을 기반으로 커널 크기를 더욱 줄일 수 있습니다. 애플리케이션 지향 커널 가지치기는 커널 크기를 더욱 줄이고 커널 코드를 광범위하게 사용자 정의할 수도 있습니다. 5 커널 클리핑 프레임워크에 대한 예비 연구 커널 조정 프레임워크의 원칙은 변경되지 않았으며, 여전히 대상 애플리케이션 워크로드의 커널 사용량을 추적하여 필요한 커널 옵션을 결정합니다. 5.1 커널 클리핑 프레임워크의 핵심 기능 커널 클리핑 프레임워크는 아마도 다음과 같은 특징을 가질 수 있습니다: 5.2 커널 클리핑 프레임워크 아키텍처 커널 클리핑 프레임워크에는 오프라인/온라인 시스템이 모두 있어야 합니다. 아키텍처는 아래 그림과 같습니다. 5.3 커널 클리핑 프레임워크 구현 가능성 구성 추적 6. 요약 운영 체제 커널의 불안정성, 적시성 부족, 무결성 문제 및 수동 개입의 필요성으로 인해 Linux 커널 정리 기술은 널리 사용되지 않았습니다. 기존 기술의 한계를 이해한 후, 이러한 문제를 해결할 수 있는 Linux 커널 조정 프레임워크를 제안하려고 합니다.
구성 옵션은 C 전처리기에 의해 구현된 명령문 및 함수와 Makefile을 기반으로 구현된 객체 파일과 같은 커널 코드의 다양한 세부 수준을 제어합니다. C 전처리기는 #ifdef/#ifndef를 기반으로 코드 블록을 선택하고 구성 옵션은 매크로 정의로 사용되어 이러한 조건부 코드 블록이 명령문 세분성 또는 함수 세분성으로 컴파일된 커널에 포함되는지 여부를 결정합니다. Makefile은 컴파일된 커널에 특정 개체 파일이 포함되어 있는지 확인하는 데 사용됩니다. 예를 들어 CONFIG_CACHEFILES는 Makefile의 구성 옵션입니다.
명령문 수준 구성 옵션은 기존 커널 조정 도구에서 사용하는 함수 수준 추적을 통해 식별할 수 없습니다. 실제로 Linux 4.14의 C 전처리기 중 약 30%는 명령문 수준 옵션입니다.
커널 코드 및 기능적 기능이 급속히 성장함에 따라 커널의 구성 옵션 수도 급격히 증가하고 있으며 Linux 커널 3.0 이상에는 10,000개 이상의 구성 옵션이 있습니다.
KConfig의 구성 옵션 값은 bool, tristate 또는 상수일 수 있습니다. bool은 코드가 커널 바이너리로 정적으로 컴파일되거나 제외됨을 의미하는 반면, tristate는 코드가 로드 가능한 코어 모듈, 즉 런타임에 로드될 수 있는 독립 실행형 객체로 컴파일될 수 있음을 의미합니다. 상수는 커널 코드 변수에 대한 문자열 또는 숫자 값을 제공할 수 있습니다. 하나의 옵션은 다른 옵션에 따라 달라질 수 있으며 KConfig는 종속성을 반복적으로 선택하고 취소하는 재귀적 프로세스를 사용합니다. 최종 커널 구성에는 유효한 종속성이 있지만 사용자 입력과 다를 수 있습니다.
kvmconfig 및 xenconfig 템플릿은 KVM 및 Xen에서 실행되는 커널에 맞게 사용자 정의되었습니다. 기본 가상화 및 하드웨어 환경과 같은 도메인 지식을 제공합니다.
엔드 투 엔드 가시성. 하이퍼바이저의 가시성을 활용하여 엔드투엔드 관찰을 달성하고, 커널 부팅 단계와 애플리케이션 작업 부하를 추적할 수 있으며, QEMU 기반 Linux 커널용 맞춤 프레임워크를 구축해 볼 수 있습니다.
구성성. 핵심 아이디어는 주어진 배포 환경에서 커널을 부팅하고 대상 애플리케이션에 필요한 구성 옵션을 위해 커널 구성을 여러 구성 세트로 나누어 결합할 수 있도록 하는 것입니다. 구성 세트는 기본 구성과 애플리케이션 구성의 두 가지 유형으로 나뉩니다. 기본 구성은 반드시 특정 하드웨어에서 부팅하는 데 필요한 최소 구성 집합이 아니라 부팅 단계에서 추적되는 구성 옵션 집합입니다. 기본 구성은 하나 이상의 애플리케이션 구성과 결합되어 최종 커널 구성을 생성할 수 있습니다.
재사용 성. 기본 구성과 애플리케이션 구성 모두 데이터베이스에 저장되어 배포 환경과 애플리케이션 바이너리가 변경되지 않는 한 재사용할 수 있습니다. 이러한 재사용성은 추적 워크로드의 반복 실행을 방지하고 구성 세트 생성을 일회성 작업으로 만듭니다.
신속한 애플리케이션 배포를 지원합니다. 배포 환경과 대상 애플리케이션이 주어지면 커널 조정 프레임워크는 기본 구성과 애플리케이션 구성을 효율적으로 검색하고 이를 필수 커널 구성으로 결합한 다음 결과 구성을 사용하여 사용되지 않는 커널을 빌드할 수 있습니다.
세분화된 구성 추적, 프로그램 카운터 기반 추적을 통해 하위 수준 코드 패턴을 기반으로 구성 옵션을 식별합니다. 
오프라인 시스템을 통해 구성 추적기는 배포 환경 및 애플리케이션에 필요한 구성 옵션을 추적하고 기록하는 데 사용됩니다. 구성 생성기는 이러한 옵션을 기준 구성 및 애플리케이션 구성 옵션으로 처리하고 이를 구성 데이터베이스에 저장합니다.
온라인 시스템을 통해 구성 조합기는 기본 구성과 애플리케이션 구성을 사용하여 대상 커널 구성을 생성한 다음 커널 빌더가 맞춤형 Linux 커널을 생성합니다
커널 조정 프레임워크의 구성 추적기는 PC 레지스터를 사용하여 실행 명령의 주소를 캡처하여 대상 애플리케이션에 의해 구동되는 커널 실행 중에 구성 옵션을 추적합니다. 추적된 PC가 다른 프로세스(예: 백그라운드 서비스)가 아닌 대상 애플리케이션에 속하는지 확인하기 위해 다른 애플리케이션을 시작하지 않고 파일 시스템 /tmp, /만 마운트하는 사용자 정의 init 스크립트를 사용할 수 있습니다. proc 및 /sys, 네트워크 인터페이스(lo 및 eth0)를 활성화하고 마지막으로 커널 부팅 후 직접 애플리케이션을 시작합니다.
동시에 주소가 소스 코드에 올바르게 매핑되지만 정리된 커널에서 계속 사용할 수 있도록 커널 주소 공간 구성 무작위 로딩을 비활성화해야 할 수도 있습니다. 그런 다음 PC를 소스 코드 명령문에 매핑합니다. 로드 가능한 커널 모듈에는 추가 처리가 필요합니다. /proc/module을 사용하여 로드된 각 커널 모듈의 시작 주소를 얻고 이러한 PC를 커널 모듈 바이너리의 명령문에 매핑할 수 있습니다. 대안은 localmodconfig를 활용하는 것입니다. 그러나 localmodconfig는 모듈 세분성 수준의 정보만 제공합니다.
마지막으로 명령문을 구성에 귀속시키십시오. C 전처리기 기반 모드의 경우 C 소스 파일을 구문 분석하여 전처리기 지시문을 추출한 다음 해당 지시문의 명령문이 실행되는지 확인합니다. Makefile 기반 모드의 경우 개체 파일 세분성에서 구성 옵션을 선택해야 하는지 여부를 결정합니다. 예를 들어 해당 파일(bind.o, achefiles.o 또는 daemon.o) 중 하나를 사용하는 경우 CONFIG_CACHEFILES를 선택해야 합니다.
구성 생성
기본 구성과 애플리케이션 구성은 오프라인 시스템에서 생성됩니다. 시작 단계의 종료를 어떻게 판단합니까? 빈 스텁 함수는 mmap을 사용하여 미리 정의된 주소 세그먼트에 매핑될 수 있습니다. 위에서 설명한 init 스크립트는 대상 응용 프로그램을 실행하기 전에 스텁 함수를 호출하므로 PC에서 미리 정의된 주소를 기반으로 부팅 단계의 끝을 식별할 수 있습니다. 추적하다.
커널 조정 프레임워크는 애플리케이션에서 구성 옵션을 얻고 부팅 단계에서 관찰된 하드웨어 관련 옵션을 필터링합니다. 이러한 하드웨어 기능은 커널 소스 코드에서의 위치를 기반으로 정의됩니다. 하드웨어 관련 옵션은 애플리케이션 실행 중에만 관찰될 수 있다는 가능성을 배제할 수 없습니다. 예를 들어 필요에 따라 새 장치 드라이버를 로드합니다.
구성 및 조립
기본 구성을 하나 이상의 애플리케이션 구성과 결합하면 커널을 빌드하는 데 사용되는 최종 구성이 생성됩니다. 먼저 모든 구성 옵션이 초기 구성으로 병합된 다음 SAT 솔버를 사용하여 이들 간의 종속성을 해결합니다. 구성 종속성을 부울 만족도 문제로 모델링해 보십시오. 여기서 유효한 구성은 구성 옵션 간에 지정된 모든 종속성을 충족하는 구성입니다. 커널 구성 모델링은 SAT 솔버를 기반으로 합니다. KConfig는 선택된 모든 옵션이 포함되도록 보장하지 않고 대신 충족되지 않은 종속성을 선택 취소하기 때문입니다.
커널 빌드
Linux용 KBuild는 조립된 구성 옵션을 기반으로 맞춤형 커널을 빌드합니다. 최신 make를 사용하는 증분 빌드는 빌드 시간을 최적화할 수 있으며 이전 빌드 결과(예: 개체 파일 및 커널 모듈)를 캐시하여 중복 컴파일 및 링크를 방지할 수도 있습니다. 구성 변경이 발생하면 구성 옵션을 변경한 모듈만 다시 빌드되고 다른 파일은 재사용할 수 있습니다.
위 내용은 Linux 커널 프루닝 프레임워크에 대한 예비 연구의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
