この質問に対する答えは、リリース前にLinuxカーネルのソースコードを確認する方法についての洞察と参考資料を提供します。
私にとってこの質問の特に興味深い側面は次のとおりです。
- 提供されたコード（たとえば、プール要求を介して）を確認する人は誰ですか、何人ですか？
- 特にファームウェアブロブの場合、バックドアが検出できない可能性がある変更はありますか？
- 静的/動的コード分析ツールが使用されていますか？それでは、偶発的なバグを防ぐためですか？それとも意図的なバックドアを防ぐためですか？
メッセージ: 私は見たロコムのよくある質問これにより、以下の関連ステートメントが提供されます。
カーネルにパッチを追加するには？
(RRR) パッチに応じてパッチをカーネルに入れる方法はいくつかあります。最初のステップは、あなたのコードがどの管理者に属しているかを確認することです（MAINTAINERSファイルの確認）。あなたのパッチが単なる小さなバグ修正であり、それが確実であると確信している場合 「明らかに正しい」、[...]
[...] これはもう一つの重要なポイントです。リストの目的の1つはパッチを取得することです。同僚がレビューし、完全にテストしました。[...]
問題の核心には洞察力があります。「明らかに正しい」そして同僚のレビュー（例：誰が何人ですか？）
具体的な例を挙げるために、次の例を見てみました。コミットログ段階的な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
提供されたコードを確認する人は誰で、何人ですか？
一般的に言えば、少なくともサブシステム管理者、一般にパッチの一般的なトピックに興味がある少なくとも1つまたは2人の他の開発者です。たとえば、セキュリティ改善パッチには、セキュリティに焦点を当てた開発者と、変更しているサブシステムのメンテナンスが含まれることがよくあります。開発者が他の人の関心を引き付けることができない場合、より複雑なパッチはより多くの関心を得るでしょう。過度のメンテナンスコストをもたらすパッチは適用されません（参照：この例は実際にあなたのものです）。
特にファームウェアブロブの場合、バックドアが検出されなかった可能性はありますか？
定義によると、ファームウェアブロブはほとんど不透明であるため、バックドアが検出されない可能性があります。より一般的には、特定の攻撃の複雑さを見ると、例えばWebブラウザの場合、見かけに関連しないように見える多くのパッチプロセス中にバックドアが導入される可能性があることは確かに想像できます。見た目には関係がないようなパッチが、最終的に他の開発者によってレビューされ承認された場合、特にそうです。
静的/動的コード分析ツールが使用されていますか？それでは、偶発的なバグを防ぐためですか？それとも意図的なバックドアを防ぐためですか？
私が知っている限り、これはレビュープロセスの一部ではありませんが、カーネルに対して定期的に分析ツールを実行し、その後に発生する問題を報告および/または修正するグループがたくさんあります。例は次のとおりです。CoverityScan。
これについてそのような明確な事実は何ですか？
これは大きな違いを生み出します。斑点はい慎重なレビュー（参照簡単なパッチのレビューです) しかし、パッチコミッタは予想よりも応答が少ない場合があります。特に、サブシステム管理者よりも変更するコードに慣れていないため、作成者には複雑に感じる可能性のある変更が管理者には複雑に感じられない場合があります。言うまでもなく明白だ。カーネル開発コミュニティはまた、大規模なパッチをレビュー可能な塊に分割することを要求することによって「大規模なパッチの緩いレビュー」症候群を回避する傾向があり、しばしば大規模なパッチセットがより多くのレビューを受けることを要求することもあります。残念ながら、慎重にコメントを提示しても正確さが保証されるわけではありません。私のパッチの1つはサブシステム管理者によって修正されましたが、弱いバグとマージされました！ （メンテナンス者が自分のパッチをどのように処理するかについての最近の分析がありましたが、これは関連しています。）
サブシステム管理者がツリーをマージすると、パッチも主要な管理者（Linus、Greg、およびさまざまな信頼できる管理者）に至るまで一般的なレビューを受けます。これは通常要求を変更しませんが、時には変更されることがあります。
すべての社会的側面を考慮することも重要です。よく知られている開発者がレビューを受けるのは簡単です。ソフトウェア開発の世界で私が経験したことによれば、有名な開発者は自分のパッチをあまり正確に評価することができません。あまり知られていない開発者にとっては、よく知られているレビュアーがパッチを承認すると、より簡単に入ることができます。一般的に言えば、正しい人を知ったり、正しい努力に頼ることが役に立ちます（例えば強化活動に参加）。