問題タブ [ebpf]

したがってBPF、プログラムはカーネル空間内で実行されるため、カーネル エンティティです。一方、コンテナーとも呼ばれる Linux 名前空間は、アプリケーション レベルの分離を提供します。この場合、それらはすべてホストのカーネル、カーネル モジュールなどを共有します。

bpfホスト上でも見えるようになるので、コンテナごとにプログラムをロードするのは意味がないと思いますか？

bpfしたがって、プログラムはホストとモニター/マングルなどにロードされると思います。名前空間との間のパケット。struct sock名前空間 ID に関する情報があるとすれば、特定の種類のプログラムだけがbpfそれを実行できると思いますか?

さまざまな種類のBPFプログラムを調べていたところ、プログラムの種類ごとにコンテキストが異なる方法で渡されていることに気付きました。

例：

1. program typeBPF_PROG_TYPE_SOCK_OPSの場合、 type のオブジェクトstruct bpf_sock_ops_kernが渡されます。ただし、このタイプの BPF プログラムは への参照を取りますstruct bpf_sock_ops。なぜこのように行われるのですか? からbpf_sock_ops_kernへの「翻訳」はどこにありbpf_sock_opsますか?

2. プログラム typeBPF_PROG_TYPE_CGROUP_SKBの場合、 type のオブジェクトstruct sk_buffが渡されますが (たとえば in __cgroup_bpf_run_filter_skb)、BPF プログラムは最小化されたバージョンstruct __sk_buff.

そこで、struct bpf_verifier_ops関数 callbacksを調べましたが、BPF ベリファイアによって呼び出されるため、BPF 命令のオフセットのみを調整しているようです。

誰かが BPF コンテキストがどのように定義されているかを明らかにできれば幸いです。ありがとう。

カーネルが複数の CPU で同時に実行できる eBPF プログラムのインスタンスの数に制限はありますか (python GIL の問題と同様)。

特に、eBPF tc プログラムは複数の CPU で同時に動作できますか?

複数の CPU で同じコードを実行している場合、eBPF によってカーネル データ構造のロックはどのように行われますか?