Linux の「ランダムな」カーネル コードの改善に最近多くの作業を費やしている WireGuard の名声は、ユーザー空間の開発者のニーズによりよく対応するために、パフォーマンスを向上させるために vDSO に getrandom() サポートを追加する提案を送信しました。
Phoronix を読んでいるうちに、Jason Donenfeld は GNU C ライブラリに arc4random 関数が追加されていることを知りました。一方、Donenfeld は Glibc メーリング リストで議論を開始し、いくつかの異なる見解を示しました。そしてその目的についての質問。
これは良いアイデアなのか、glibc が望んでいるものなのか、長期的にコミットする価値のあるデザインなのか、本当に疑問に思っています。
まず、これが実際に役立つのはどのようなユースケースですか?最近の Linux カーネルの変更により、4.9 に完全にバックポートされました!–getrandom() と/dev/urandom は非常に高速で、CPU ごとの状態でロックなしで動作します。ユーザー空間でそれを行うことでシステムコールを回避することは確かですが、それは本当に重要ですか?誰がこれから正確に利益を得ますか?
そのように見ると、何の役にも立たないほど複雑で、最終的にバグやさまざまな見落としにつながる複雑さのように思えます。
たとえば、仮想マシンが ACPI 経由でカーネルに渡された識別子を使用して fork すると、カーネルはそれ自体を再シードします。また、システムの再開時に、通常の S3 スリープからだけでなく、さらに重要なことに休止状態からも再シードします。そして一般的に、カーネルはエントロピーの調停者であるため、いつ再シードするのが理にかなっているかを判断する態勢が整っています。
一方、Glibc はいくつかのヒューリスティックを採用し、いくつかの決定を下すことができます (フォーク、16 MiB の後など)。カーネルが持っている情報。
arc4random ではこれを見逃しており、将来その情報が何らかの形でユーザー空間にエクスポートされるとしたら、カーネル インターフェイスと一緒にユーザー空間インターフェイスを設計するのは非常に良いことです。
そのため、ユーザー空間 libcs で乱数を生成するというこれまでの議論は、何らかの方法で vDSO でこれを行うことに向けられており、カーネルがその取り組みの一部となる可能性があります。
この観点から見ると、OpenBSD の古いパラダイムを使用することはかなり制限的である可能性があります。カーネルと libc の間で協力して、後で元に戻すのが難しいセマンティクスを備えたインターフェイスに落ち着く前に、より良いものを考え出すことができるかどうかを確認してみませんか?
現状では、これらの関数を実際に使用することを推奨するのは困難です。 getrandom(2) を使い続けてください。これは、ほとんど好ましいセマンティクスを持っています。
はい、わかりました。乱数ジェネレーターを作成するのは楽しいので、多くのプロジェクトが何らかの方法で別の乱数ジェネレーターを作成する方法を考え出しています。しかし、そうする傾向は、エコシステム全体を助けてきたものではなく、奇妙なコンピューターいじり病のように感じます.
だから私は疑問に思っています: 実際に誰がこれを必要とし、なぜですか?パフォーマンス要件はどのようなものですか? getrandom(2) が不十分なのはなぜですか?そして、これは本当に最善のアプローチですか?これが必要な場合、代わりに vDSO アプローチで協力することについてどう思いますか?それとも、そもそもこれを実際に必要としている人はいないのでしょうか?
そして第二に、とにかく glibc がこれを行うことが *できない* ことはありますか?それとも、その船は完全に航行したのでしょうか?
その結果、Donenfeld と GNU ツールチェーンの開発者の間で、パフォーマンスのニーズと、BSD で長い間利用されてきた Glibc の arc4random 関数の開発につながった理由について、多くの議論が行われました。
ランダムなパフォーマンスのニーズにより適切に対処しようとして、今日、Donenfeld は提案しました。 vDSO に getrandom() を実装します。もちろん、vDSO は、カーネルがすべてのユーザー空間ソフトウェアのアドレス空間に自動的にマップする仮想動的共有オブジェクト ライブラリです。 getrandom() を vDSO に追加することで、システム コールのオーバーヘッドよりもパフォーマンスを大幅に向上させることができるはずです。 Jason はそのコメントのリクエストに次のように書いています。しかし、これは非常に若く未熟なコードであり、RFC に適しており、それ以上のものではありません。 [email protected]/”>メーリング リストで技術的な詳細を確認してください。
さらに、Jason Donenfeld は arc4random 設計を簡素化して Glibc にしました。コードであり、既に Git にマージされています。この設計の簡素化は、ユーザー空間で 16MiB のエントロピーをバッファリングするのではなく、毎回 getrandom() を呼び出すことにより、新しい arc4random 関数の安全性を高めるためのものです。そのため、少なくとも当分の間、この簡素化によりパフォーマンスのオーバーヘッドが発生します。