Windows Update만 쓸 수 있는 hot-patch 공간에 다른 프로그램이 끼어들면 벌어지는 일
If somebody tries to hot-patch an already-hot-patched function
Microsoft의 hot-patching은 Windows Update만 사용하도록 설계되어, 다른 코드가 이미 패치한 함수를 만나면 충돌이 발생한다. prescan 이후에 rogue 패치가 끼어들면 패처는 중간에 멈춰 롤백도 못 하고 메모리에는 반쯤 패치된 바이너리만 남는다. 결국 파일을 hot-patch 불가로 선언하고 재부팅해야 하는데, 고객은 달가워하지 않는다.
hot-patching 공간을 사용하는 애플리케이션은 소방서 주차 금지 구역에 주차하는 것과 같다. 소방차가 나타나기 전까지는 모든 게 괜찮아 보이지만, 소방차가 도착하지 못해 누군가의 집이 불타 없어진다.
HN 토론
23- drdexebtjl
Microsoft가 함수 후킹을 "rogue"라고 간주하거나, 마치 "허가받지 않은" 행위인 것처럼 프레이밍하는 게 흥미롭네요. 정작 Microsoft 자신들은 detours 라이브러리를 만들면서 이런 식으로 프레이밍한 적이 없는데 말이죠.
또한 이 설명에서 빠진 부분: 훅은 보통 사용자 공간에서 프로세스별로 적용됩니다. 동적 라이브러리의 코드 페이지는 패치를 적용하기 위해 쓰기를 하면 공유 페이지에서 CoW(기록 시 복사)됩니다.
Windows Update도 비슷하게 작동하는 건가요, 아니면 원본 공유 페이지를 어떻게든 수정해서 모든 프로세스에 영향을 미치나요? 단일 프로세스의 훅이 전체 시스템의 핫 패칭을 비활성화하나요?
- jonhohle
이전 직장에서 모놀리식 Docker 이미지 위에 개별 Java 클래스 파일을 패치하기 위한 Docker 빌드를 작성한 적이 있습니다. 이건 런타임 패칭은 아니었지만, 긴급 상황에서 단 몇 킬로바이트에 불과한 단일 레이어를 빠르게 배포할 수 있게 해주었죠.
흥미롭게도 비슷한 제약이 있었고 빌드 시점에 이를 검사했습니다: 공개 ABI 변경이 될 수 없고 한 번에 하나의 패치만 가능하다는 점이었습니다.
- fsfod
Windows의 병렬 DLL 로딩도 일부 NT DLL 함수가 후킹된 것을 발견하면 프로세스에 대해 방어적으로 스스로를 비활성화합니다 https://stackoverflow.com/questions/42789199/why-there-are-t...