지난 몇 년간 다양한라이브 커널 패치이 기술은 가능한 최고의 시스템 가동 시간을 보장하기 위해 노력하는 시스템 관리자들 사이에서 인기를 얻었습니다.
이 프로세스를 가능하게 하기 위해 사용자 정의 패치를 준비한 다음 종종 유료 고객에게 배포하고 때로는 가정 사용자에게 무료로 배포합니다.
실행 중인 커널 버전과 사용 가능한 최신 소스 코드 간의 차이점을 이용하여 이러한 패치를 자동으로 생성할 수 없는 이유는 무엇입니까? 내가 이해한 바로는 가장 많은 이점을 얻을 수 있는 서버 코어는 일반적으로 몇 년에 한 번씩 큰 변경 사항만 받고 그 외에는 주요 버그 수정 및 보안 업데이트만 받기 때문에 이 작업이 더 쉬워지는 것 같습니다. 마찬가지로 안정성이 문제라면 상대적으로 중요도가 낮은 기계를 실행하는 자원 봉사자가 먼저 패치를 구축하고 패치가 얼마나 잘 작동하는지 자동으로 보고하는 시스템을 설정하는 것이 간단해 보일 수 있습니다.
그러나 이 중 아무 일도 일어나지 않았습니다. 내가 무엇을 놓쳐서 이런 일이 일어났는가?
답변1
우리는 프로그램 실행을 프로그램을 생성하는 정적 소스 코드로 생각하고 싶습니다. 하지만 그들은 계속해서 변화하고 있습니다. 마찬가지로 메모리의 커널은 디스크의 커널과 다릅니다.
Dijkstra의 편지를 인용하자면 "goto는 유해한 것으로 간주됩니다."...
내가 첫 번째로 지적할 점은 올바른 프로그램을 구축하면 프로그래머의 활동이 끝나지만, 프로그램의 통제 하에서 발생하는 프로세스가 그의 활동의 실제 주제라는 것입니다. 왜냐하면 원하는 효과를 달성해야 하는 것이 바로 이 프로세스이기 때문입니다. 필수 사양을 충족해야 하는 이 프로세스의 동적 동작. 그러나 일단 프로그램이 만들어지면 해당 프로세스의 '만들기'는 기계에 맡겨집니다.
두 번째 진술은 우리의 지능은 정적 관계를 파악하는 데 더 적합한 반면, 시간이 지남에 따라 진화하는 프로세스를 시각화하는 능력은 상대적으로 제대로 개발되지 않았다는 것입니다. 그러므로 우리는 (우리의 한계를 알고 있는 현명한 프로그래머들이) 최선을 다해야 합니다.정적 프로그램과 동적 프로세스 간의 개념적 격차 해소, 프로그램(텍스트 공간으로 확장됨)과 프로세스(시간으로 확장됨) 간의 대응을 가능한 한 단순하게 만듭니다.
이것으로부터 나는 디스크에서 커널을 로드하지 않는 프로그램이나 커널을 메모리에 넣는 것은 나쁜 생각이라는 것을 추론했습니다. 다른 것을 알고 싶지 않다면,할 수 있는재부팅하면 현재 실행 중인 것과 동일한 커널이 생성됩니다.
시스템 관리자로서 여러분은 실제 커널이 패치한 커널과 미묘하게 다르기 때문에 프랑켄슈타인의 괴물이 아닌 실제 일반 커널로 끝나고 있다는 것을 알고 싶습니다.
실시간 패치가 정말 어렵네요. 라이브 패치를 자동으로 생성하는 것은 기술적으로 불가능합니다.
프로그램 코드가 효과적으로 자체적으로 재작성될 수 있다는 점을 이해하는 것이 중요합니다.
int X = 10;
void run(){
X=5;
}
이 코드 예제에서는 X=10숫자가 코드로 실행되지 않습니다. 컴파일러는 10숫자를 "X" 위치에 배치합니다. 3행이 런타임 시 실행되면 "X" 위치의 값이 대체됩니다. 실제로 값을 덮어쓰는데, 이는 10 실행 중인 프로그램 코드에서 숫자가 완전히 사라진다는 의미입니다 .
이제 다음 명령을 사용하여 이 문제를 라이브로 패치하려고 합니다.
int X = 20;
void run(){
X=15;
}
X는 무엇을 20이나 15로 패치해야 합니까? 패치해야 할까요, 아니면 그냥 놔둬야 할까요? 여기서는 코드만 변경하는 것이 아니라 동적으로 생성된 값을 변경합니다. 동적으로 생성되므로 변경할 필요가 없다고 생각할 수도 있지만 변경하지 않으면 새 코드에서 5 또는 10이 여전히 유효한 값이라는 것을 알고 있습니까? 이 작업은 자동으로 수행될 수 없습니다!
간단히 말해서, 라이브 패치를 만드는 기술과 관련 도구가 있지만 이를 사용하고 결과를 테스트하려면 전문가가 필요합니다. 이러한 도구를 출시하고 일반 사용자가 해당 도구를 사용하는 방법을 알아내기를 기대하는 것은 많은 일반 사용자가 시스템을 망칠 수 있는 좋은 방법입니다.
답변2
실행 중인 커널에 패치를 도입하기 위해 사용할 수 있는 모든 메커니즘은 실행 중인 커널에 루트킷을 도입하는 등 나쁜 용도로도 사용될 수 있습니다.
악성 코드가 적절한 다른 네트워크 수준 취약점을 통해 유입된 경우 손상의 증거로 사용할 수 있는 로컬로 수정된 파일이 전혀 없을 수 있습니다.
또한 다음과 같은 것들이KASLR(커널 주소 공간 레이아웃 무작위화)커널에 대한 공격을 더욱 어렵게 만들기 위해 설계된 이 방법은 보호하려는 정보(메모리에 있는 다양한 커널 루틴의 주소)도 성공적인 라이브 패치에 필요한 정보이기 때문에 라이브 패치를 복잡하게 만듭니다. 아마도 이 정보는 합법적인 목적으로만 사용될 수 있도록 영리하게 관리될 수 있겠지만, 이는 까다로운 문제라고 생각합니다.
단일 대형 서버가 아닌 가상화, 병렬성 및 여러 개의 소형 서버를 강조하는 최신 "클라우드" 애플리케이션 설계 원칙으로 인해 개별 서버 가동 시간이 예전보다 덜 중요해지고 있습니까? 애플리케이션 아키텍처에 로드 밸런싱된 여러 서버 집합이 포함되어 있고 집합의 크기가 가변적인 경우 패치가 적용된 새 가상 서버를 가동하고 패치가 적용되지 않은 이전 가상 서버를 해체한 후 모든 서버가 복구될 때까지 이 작업을 반복할 수 있습니다. 패치되었습니다. 새로운 것으로 교체되었습니다. 애플리케이션 스택의 모든 수준에서 이 작업을 수행할 수 있다면 문제가 다른 방법으로 해결될 수 있으므로 라이브 패치가 전혀 필요하지 않을 것입니다.
답변3
커널은 *nix 기반 운영 체제의 핵심입니다. 운영 체제의 모든 동작을 제어합니다. 따라서 실시간 패치는 현재 진행 중인 작업을 방해할 수 있습니다. 그래서 실시간 패치가 안되는군요.