eBPFはどの点でユーザー側の検証カーネルモジュールよりも優れていますか？
コード検証の価値については疑問を提起しません。どちらのアプローチも完全に静的に検証されます。どちらの方法でも、通常、特権を持つユーザーにのみ付与される機能が必要です。
ただし、ユーザースペースでバリデーターを実行すると、ユーザーはバリデーター、セキュリティーレベル、および許可されている前提条件の中からより多くの選択肢が提供されます。バリデータはカーネルとは無関係に、より迅速に開発することもできます。
この質問をする前に読んだことがあります。:
私が見つけたこのハッカーニューストピック、これは一部制限されたeBPFフィルタには権限は必要ありませんが、ほとんどのeBPFアプリケーションにはまだ権限が必要であることがわかります。
私が見つけたこのページ、それは主張する
カーネルモジュールには、特定のエントリポイント（init_module（））と終了ポイント（cleanup_module（））があります。 eBPFはすべてのkprobe/kretprobe/tracepointに接続できるため、トレースに使用できます。
前のリファレンスとは異なり、Linuxのドキュメントによれば、kprobe/kretprobe/tracepointsは、ロード可能なカーネルモジュールでフック（登録とも呼ばれる）ができるようです。kprobes/kretprobesそしてトラッキングポイント。
このページさらに、eBPFはプリエンプションできませんが、カーネルモジュールはプリエンプトできると主張されます。 Linuxカーネルプリエンプションモジュールコードを検索するたびに、常にカーネルスペースではなくユーザースペースプリエンプションについて話します。 「カーネルモジュールが通常のカーネルコードプリエンプションロジックに従う」ということは何を意味するのかわかりませんが、「eBPF命令セットの実行はカーネルによってプリエンプションできません」という意味です。