2P by neo 2023-09-28 | favorite | 댓글 1개
  • 저자는 PowerPC32 아키텍처에서 실행되는 gdbserver와 다중 스레드 애플리케이션을 포함하는 프로젝트의 디버깅 문제를 처리하고 있었다.
  • 문제는 gdbserver에 대한 연결이 끊어져 더 이상 디버그 세션을 제어할 수 없었다는 것이었다.
  • 연구 및 조사 후, 저자는 이 문제를 초래한 정확한 커밋을 가리키는 이메일 스레드를 발견했다.
  • 저자는 PowerPC 아키텍처와 task_struct 주변의 변화에 관련된 커밋 설명을 읽는 데 3-4일을 보냈으며, 이 문제가 후속 커널 버전에서 해결되었는지 여부를 파악하려고 노력했다.
  • 저자는 thread_struct 스레드를 이동시키고, pahole로 task_struct의 레이아웃을 검사하고, ftrace를 사용하여 디버그된 프로세스의 스레드가 언제 스케줄링되는지 파악하는 등 다양한 도구와 기법을 사용했다.
  • 저자는 문제가 메모리 손상 문제일 수 있음을 발견했는데, 고착된 스레드는 다른 스레드와 달리 한 번만 스케줄링되었다.
  • 저자는 Linux에서 하드웨어 브레이크포인트를 사용하고, __state 필드에 하드웨어 브레이크포인트를 배치하여 누가 그것에 쓰는지 파악하기 위해 리눅스 커널 모듈을 구현했다.
  • 저자는 문제가 ptrace_put_fpr의 버퍼 오버플로우 (POKEUSER API에 의해 사용됨)로 인해 task_struct의 중요한 필드들이 덮어쓰여지는 것, 예를 들어 __state,임을 발견했다.
  • 저자는 이 문제가 보안 문제를 초래할 수 있으므로, 이 문제를 해결하기 위해 리눅스 커널 보안 팀(security@kernel.org)에 패치를 보냈다.
  • PowerPC 관리자인 Michael Ellerman는 저자의 패치를 받아들이는 대신 자신의 버전의 수정을 구현했다.
  • 저자는 자신의 작업이 제대로 인정받지 않아서 자신을 과소평가당한 것 같고 화가 났다. 그는 "Reported-by" 태그만 받았을 뿐이었다.
  • 저자의 첫 커널 기여는 사람들이 자신의 작업에 대한 적절한 인정을 받는 것이 중요하다고 생각하지 않는 사람들과의 대화를 통한 좌절감과 낙담감이 가득한 경험이었다.
Hacker News 의견
  • 기고자의 패치가 완전히 수용되지 않았지만, 관리자가 이 아이디어를 사용해 보안 문제를 해결한 상황에 대한 기사
  • 완전한 패치가 수용되지 않았더라도, 관리자는 기고자에게 크레딧을 줬어야 한다는 일부 댓글
  • 관리자의 패치가 더 나아고 효율적이라는 주장과 함께, 기고자가 문제를 파악하고 해결책을 제안한 것에 대한 인정이 필요하다는 다른 주장
  • Linux 커널이 보상이 아니며, 관리자가 최선의 해결책을 선택할 권리가 있다는 댓글과 함께, 기고자에게 크레딧을 주는 것의 중요성을 강조하는 일부 댓글
  • 패치 아이디어를 제안한 사람에게 크레딧을 주는 방법으로 커널 문서의 "Suggested-by" 태그 언급
  • 이것이 커널에 기여하는 일반적인 부분이며, 주요 목표는 버그를 수정하는 것이지 크레딧을 받는 것이 아니라는 일부 댓글
  • 오픈 소스 프로젝트에서 자신의 기여가 무시되거나 완전히 수용되지 않은 경험을 공유하는 댓글, 이는 추가 기여를 방해할 수 있음
  • 기고자의 패치와 관리자의 패치를 비교하는 댓글, 차이점을 지적하고 원작자에게 크레딧을 줬어야 했다고 제안
  • 후배 팀원들의 기여를 학습과 개선을 장려하는 방식으로 다루는 것의 중요성에 대해 논의도 건드림
  • 부정적인 반응에 대한 혼란을 표현하는 댓글, 인정이 중요하며 공동 저자를 추가하는 것은 작지만 의미 있는 제스처라고 주장
  • 외교의 중요성과 오픈 소스 프로젝트에서 장기적인 관계를 유지하는 것에 대한 댓글로 논의가 마무리됨