eBPF: программы/карты bpf по умолчанию?

Я столкнулся со странным поведением bpf с последним ядром net-next. Со всеми включенными параметрами ядра BPF (включая CONFIG_BPF_JIT_ALWAYS_ON) и без загруженных каких-либо bpf программ bpftool сообщает следующее:

# ./bpftool prog show
2: cgroup_skb  tag 7be49e3934a125ba
        loaded_at Feb 05/10:17  uid 0
        xlated 296B  jited 229B  memlock 4096B  map_ids 2,3
3: cgroup_skb  tag 2a142ef67aaad174
        loaded_at Feb 05/10:17  uid 0
        xlated 296B  jited 229B  memlock 4096B  map_ids 2,3
4: cgroup_skb  tag 7be49e3934a125ba
        loaded_at Feb 05/10:17  uid 0
        xlated 296B  jited 229B  memlock 4096B  map_ids 4,5
5: cgroup_skb  tag 2a142ef67aaad174
        loaded_at Feb 05/10:17  uid 0
        xlated 296B  jited 229B  memlock 4096B  map_ids 4,5
6: cgroup_skb  tag 7be49e3934a125ba
        loaded_at Feb 05/10:17  uid 0
        xlated 296B  jited 229B  memlock 4096B  map_ids 6,7
7: cgroup_skb  tag 2a142ef67aaad174
        loaded_at Feb 05/10:17  uid 0
        xlated 296B  jited 229B  memlock 4096B  map_ids 6,7
#
# ./bpftool map show
2: lpm_trie  flags 0x1
        key 8B  value 8B  max_entries 1  memlock 4096B
3: lpm_trie  flags 0x1
        key 20B  value 8B  max_entries 1  memlock 4096B
4: lpm_trie  flags 0x1
        key 8B  value 8B  max_entries 1  memlock 4096B
5: lpm_trie  flags 0x1
        key 20B  value 8B  max_entries 1  memlock 4096B
6: lpm_trie  flags 0x1
        key 8B  value 8B  max_entries 1  memlock 4096B
7: lpm_trie  flags 0x1
        key 20B  value 8B  max_entries 1  memlock 4096B
#

Вот что содержит программа:

# ./bpftool prog dump xlated id 2
   0: (bf) r6 = r1
   1: (69) r7 = *(u16 *)(r6 +192)
   2: (b4) (u32) r8 = (u32) 0
   3: (55) if r7 != 0x8 goto pc+14
   4: (bf) r1 = r6
   5: (b4) (u32) r2 = (u32) 16
   6: (bf) r3 = r10
   7: (07) r3 += -4
   8: (b4) (u32) r4 = (u32) 4
   9: (85) call bpf_skb_load_bytes#6169312
  10: (18) r1 = map[id:2]
  12: (bf) r2 = r10
  13: (07) r2 += -8
  14: (62) *(u32 *)(r2 +0) = 32
  15: (85) call bpf_map_lookup_elem#73712
  16: (15) if r0 == 0x0 goto pc+1
  17: (44) (u32) r8 |= (u32) 2
  18: (55) if r7 != 0xdd86 goto pc+14
  19: (bf) r1 = r6
  20: (b4) (u32) r2 = (u32) 24
  21: (bf) r3 = r10
  22: (07) r3 += -16
  23: (b4) (u32) r4 = (u32) 16
  24: (85) call bpf_skb_load_bytes#6169312
  25: (18) r1 = map[id:3]
  27: (bf) r2 = r10
  28: (07) r2 += -20
  29: (62) *(u32 *)(r2 +0) = 128
  30: (85) call bpf_map_lookup_elem#73712
  31: (15) if r0 == 0x0 goto pc+1
  32: (44) (u32) r8 |= (u32) 2
  33: (b7) r0 = 1
  34: (55) if r8 != 0x2 goto pc+1
  35: (b7) r0 = 0
  36: (95) exit
#

Самое смешное, что я явно не загрузил никакую eBPF программу. Интересно, есть ли теперь в ядре блоб по умолчанию eBPF, который появляется?

Это происходит сразу после загрузки машины. Единственная разница между этой системой и другой (работающей с тем же ядром и параметрами, и где я не вижу этой проблемы с несколькими программами cgroup_skb) заключается в наличии /sys/fs/cgroup/unified cgroup2 FS. Я не знаю, связано ли это с моей проблемой, но я не знаю, как отключить /sys/fs/cgroup/unified, размонтирование запрещено.


c linux-kernel bpf ebpf
person Mark    schedule 05.02.2018    source источник
comment
Не то, чтобы я знаю. Возможно ли, что вы запускаете на машине какую-то программу, которая будет присоединять программы eBPF к контрольным группам? Или это происходит сразу после загрузки машины, без каких-либо конкретных действий?   -  person Qeole    schedule 05.02.2018
comment
У меня возникло бы желание взглянуть на sytemd по этому поводу, но я не совсем уверен, что это виновник. Попробую глянуть, если получится.   -  person Qeole    schedule 05.02.2018
comment
Требует дальнейшего изучения, но этот PR systemd может быть связан с: github.com/systemd/systemd/pull/ 6764   -  person Qeole    schedule 05.02.2018
comment
Ах, так это же было systemd :-). Часть «Можем ли мы закрыть его», вероятно, легче разобраться, но мои знания о systemd очень ограничены, и я не могу помочь в этом.   -  person Qeole    schedule 06.02.2018
comment
Да, systemd является виновником, на данный момент я перешел на более раннюю версию, в которой нет функции IPAccess; systemd настолько толстый, что его можно быстро понять и соответствующим образом настроить ;-)   -  person Mark    schedule 06.02.2018

Ответы (1)


arrow_upward
2
arrow_downward

Как и подозревал Qeole, это исходит от systemd, в частности, systemd v235 представила функцию eBPF управления IP-доступом с двумя открытыми параметрами конфигурации, IPAddressDeny и IPAddressAllow. (Я не знаю, можно ли отключить его во время компиляции).

person Mark    schedule 06.02.2018