프로그램이 메모리를 너무 많이 먹으면 자동으로 멈추고, 바꿔놓은 설정도 원래대로 돌리는 감시 장치를 시험했다. 말로만 안전하다고 하지 않으려면 일부러 사고를 내봐야 했다.
시험 프로그램에 10MB짜리 메모리를 70번 잡게 했다. 제한은 200MB였다.
두 번 연속 넘자 실제로 죽였다
감시 결과는 756.7MB > 200MB. 한 번 튄 값으로 바로 끊지 않고 연속 2회 초과를 확인한 뒤 프로세스를 종료했다. 기록에는 killed:true, samples:2가 남았다.
설정 복구도 시험했다. 작업이 바꿔놓은 adopt_threshold 1을 원래 값 70으로 되돌렸다. 삭제·강제 초기화·배포 같은 우회 명령 다섯 종류도 5/5 차단됐다.
처음 측정은 0MB였다
그런데 이 결과까지 오는 동안 감시자 자신이 두 번 틀렸다. 명령을 껍데기 하나 더 거쳐 실행하니, 감시자는 껍데기만 재고 실제로 메모리를 먹는 자식은 못 봤다. 결과가 0MB에 가까웠다.
윈도우 프로세스 부모·자식 관계를 6단계까지 따라가서 합산하자 756.7MB가 잡혔다. 종료할 때도 자식만 끊으면 손자가 남아서, 전체 트리를 종료해야 했다.
감시자가 자기 CPU를 범인으로 만들었다
CPU 검사에서는 더 웃긴 일이 났다. 짧은 간격을 바쁜 반복문으로 기다렸더니 감시자 자신이 CPU 97.7%를 썼다. 제한 90%를 넘겨 정상 명령까지 막았다. 감시가 사고를 만든 셈이다.
바쁜 대기를 없애고 실제 대기 방식과 3회 중앙값으로 바꿨다. 오탐 93.2%였던 측정은 1.8~16.1% 범위로 안정됐다.
이 장치는 하드웨어 한도가 아니다. 반드시 감시 경로를 거친 명령만 본다. 그래서 “초과를 막는다”가 아니라 “초과를 감지해 죽이고 되돌린다”고 기록했다.
① 자원 사용량은 부모 하나가 아니라 프로세스 트리 전체를 합산한다.
② 종료도 자식·손자까지 포함해 좀비가 남지 않게 한다.
③ 감시용 대기가 자원을 먹지 않는지 감시자 자체 비용을 먼저 잰다.
④ 보호 범위 밖 실행은 못 막는다는 한계를 숨기지 않는다.