- 저자는 PowerPC32 아키텍처에서 실행되는 gdbserver와 다중 스레드 애플리케이션을 포함하는 프로젝트의 디버깅 문제를 처리하고 있었다.
- 문제는 gdbserver에 대한 연결이 끊어져 더 이상 디버그 세션을 제어할 수 없었다는 것이었다.
- 연구 및 조사 후, 저자는 이 문제를 초래한 정확한 커밋을 가리키는 이메일 스레드를 발견했다.
- 저자는 PowerPC 아키텍처와 task_struct 주변의 변화에 관련된 커밋 설명을 읽는 데 3-4일을 보냈으며, 이 문제가 후속 커널 버전에서 해결되었는지 여부를 파악하려고 노력했다.
- 저자는 thread_struct 스레드를 이동시키고, pahole로 task_struct의 레이아웃을 검사하고, ftrace를 사용하여 디버그된 프로세스의 스레드가 언제 스케줄링되는지 파악하는 등 다양한 도구와 기법을 사용했다.
- 저자는 문제가 메모리 손상 문제일 수 있음을 발견했는데, 고착된 스레드는 다른 스레드와 달리 한 번만 스케줄링되었다.
- 저자는 Linux에서 하드웨어 브레이크포인트를 사용하고, __state 필드에 하드웨어 브레이크포인트를 배치하여 누가 그것에 쓰는지 파악하기 위해 리눅스 커널 모듈을 구현했다.
- 저자는 문제가 ptrace_put_fpr의 버퍼 오버플로우 (POKEUSER API에 의해 사용됨)로 인해 task_struct의 중요한 필드들이 덮어쓰여지는 것, 예를 들어 __state,임을 발견했다.
- 저자는 이 문제가 보안 문제를 초래할 수 있으므로, 이 문제를 해결하기 위해 리눅스 커널 보안 팀([email protected])에 패치를 보냈다.
- PowerPC 관리자인 Michael Ellerman는 저자의 패치를 받아들이는 대신 자신의 버전의 수정을 구현했다.
- 저자는 자신의 작업이 제대로 인정받지 않아서 자신을 과소평가당한 것 같고 화가 났다. 그는 "Reported-by" 태그만 받았을 뿐이었다.
- 저자의 첫 커널 기여는 사람들이 자신의 작업에 대한 적절한 인정을 받는 것이 중요하다고 생각하지 않는 사람들과의 대화를 통한 좌절감과 낙담감이 가득한 경험이었다.