이 질문에 대한 답은 출시 전에 Linux 커널 소스 코드를 검토하는 방법에 대한 통찰력과 참고 자료를 제공할 것입니다.
나에게 있어 이 질문의 특히 흥미로운 측면은 다음과 같습니다.
- 제공된 코드(예: 풀 요청을 통해)를 검토하는 사람은 누구이며 몇 명입니까?
- 특히 펌웨어 blob의 경우 백도어가 감지하지 못할 수 있는 변경 사항이 있습니까?
- 정적/동적 코드 분석 도구가 사용됩니까? 그렇다면 우발적인 버그를 방지하기 위한 것입니까, 아니면 의도적인 백도어를 방지하기 위한 것입니까?
메시지: 나는 보았다로컴 FAQ이는 다음과 같은 관련 진술을 제공합니다
커널에 패치를 어떻게 추가하나요?
(RRR) 패치에 따라 패치를 커널에 넣는 방법은 여러 가지가 있습니다. 첫 번째 단계는 귀하의 코드가 어느 관리자에 속해 있는지 확인하는 것입니다(MAINTAINERS 파일 확인). 귀하의 패치가 단지 작은 버그 수정일 뿐이고 그것이 확실하다고 확신하는 경우 “분명히 맞습니다”, [...]
[...] 이것은 또 다른 중요한 점입니다. 목록의 목적 중 하나는 패치를 얻는 것입니다.동료가 검토하고 완전히 테스트했습니다.[...]
문제의 핵심에는 통찰력이 있습니다.“분명히 맞습니다”그리고동료 검토(예: 누가, 몇 명입니까?)
구체적인 예를 들기 위해 다음 예를 살펴보았습니다.커밋 로그단계적 rtl8188euWi-Fi 칩 장치 드라이버의 경우 다음 위치에서 찾을 수 있습니다 /usr/srx/linux/drivers/staging/rtl8188eu.
- 수정된 파일의 제출 건수는
[...]/rtl8188eu1560건 입니다.git log --format="%x00%h%n%an%n%cn%n%s" --name-status | tr '\0\n' '\n\0' | grep -a '8188eu' | tee commits | wc -l - 저자 수: 190명
sed 's/^[^\x00]*\x00//g;s/\x00.*$//g' <commits | sort | uniq | wc -l - 커미터 수 12명(Al Viro, David S. Miller, Greg Kroah-Hartman, Ingo Molnar, Jeff Kirsher, Jiri Kosina, Johannes Berg, John W. Linville, Kees Cook, Linus Torvalds, Michael S. Tsirkin, Peter P Waskiewicz Jr )
sed 's/^[^\x00]*\x00//g;s/^[^\x00]*\x00//g;s/\x00.*$//g' <commits | sort | uniq
답변1
제공된 코드를 검토하는 사람은 누구이며 몇 명입니까?
일반적으로 말해서, 최소한 하위 시스템 관리자, 그리고 일반적으로 패치의 일반적인 주제에 관심이 있는 최소한 한두 명의 다른 개발자입니다. 예를 들어, 보안 개선 패치에는 보안에 초점을 맞춘 개발자와 수정 중인 하위 시스템의 유지관리자가 포함되는 경우가 많습니다. 개발자가 다른 사람의 관심을 끌 수 없다면 더 복잡한 패치는 더 많은 관심을 받게 될 것입니다. 과도한 유지 관리 비용을 초래하는 패치는 적용되지 않습니다(참조:이 예는 실제로 당신의 것입니다).
특히 펌웨어 blob의 경우 백도어가 감지되지 않았을 가능성이 있습니까?
정의에 따르면 펌웨어 blob은 거의 불투명하므로 백도어가 감지되지 않을 수도 있습니다. 보다 일반적으로 특정 공격의 복잡성을 살펴보면예를 들어웹 브라우저의 경우 겉보기에 관련이 없어 보이는 많은 패치 프로세스 중에 백도어가 도입될 수 있다는 것은 확실히 상상할 수 있습니다. 겉보기에 관련이 없어 보이는 패치가 결국 다른 개발자에 의해 검토되고 승인되는 경우 특히 그렇습니다.
정적/동적 코드 분석 도구가 사용됩니까? 그렇다면 우발적인 버그를 방지하기 위한 것입니까, 아니면 의도적인 백도어를 방지하기 위한 것입니까?
내가 아는 한, 이는 검토 프로세스의 일부가 아니지만 커널에 대해 정기적으로 분석 도구를 실행하고 이후에 제기되는 문제를 보고 및/또는 수정하는 그룹이 많이 있습니다. 예는 다음과 같습니다CoverityScan.
이것에 대해 그렇게 분명한 사실은 무엇입니까?
이것은 큰 차이를 만듭니다. 반점예신중한 검토(참조간단한 패치에 대한 리뷰입니다) 그러나 패치 커미터는 예상보다 응답이 적을 수 있습니다. 특히 하위 시스템 관리자보다 변경하는 코드에 익숙하지 않기 때문에 작성자에게는 복잡하게 느껴질 수 있는 변경 사항이 관리자에게는 복잡하게 느껴지지 않을 수 있습니다. 말할 것도 없이 분명하다. 커널 개발 커뮤니티는 또한 대규모 패치를 검토 가능한 덩어리로 분할하도록 요구함으로써 "대형 패치의 느슨한 검토" 증후군을 피하는 경향이 있으며 종종 대규모 패치 세트가 더 많은 검토를 받도록 요구하기도 합니다. 불행하게도, 주의 깊게 의견을 제시한다고 해서 정확성이 보장되는 것은 아닙니다. 내 패치 중 하나가 하위 시스템 관리자에 의해 수정되었으나, 고약한 버그와 병합되었습니다! (유지관리자가 자신의 패치를 어떻게 처리하는지에 대한 최근 분석이 있었는데, 이는 관련이 있습니다.)
하위 시스템 관리자가 트리를 병합하면 패치도 주요 관리자(Linus, Greg 및 다양한 안정적인 관리자)에 이르기까지 일반적인 검토를 받습니다. 이로 인해 일반적으로 요청이 변경되지 않지만 때로는 변경되는 경우도 있습니다.
모든 것의 사회적 측면을 고려하는 것도 중요합니다. 잘 알려진 개발자가 리뷰를 받는 것이 더 쉽습니다. 소프트웨어 개발 세계에서 제가 경험한 바에 따르면, 유명한 개발자는 자신의 패치가 덜 정밀하게 평가될 수 있습니다. 덜 알려진 개발자의 경우, 잘 알려진 리뷰어가 패치를 승인하면 더 쉽게 들어갈 수 있습니다. 일반적으로 말하면, 올바른 사람을 알거나 올바른 노력에 의존하는 것이 도움이 됩니다(예를 들어강화 활동에 참여).