On Thu, Dec 1, 2022 at 9:36 PM Hao Luo <haoluo@xxxxxxxxxx> wrote: > > On Thu, Dec 1, 2022 at 6:47 AM Yafang Shao <laoar.shao@xxxxxxxxx> wrote: > > > > On Thu, Dec 1, 2022 at 8:38 AM Hao Luo <haoluo@xxxxxxxxxx> wrote: > <...> > > > 3. IIRC, Song proposed introducing a namespace for BPF isolation, not > > > just isolating IDs [1]. How does it relate to the BPF_ID namespace? > > > > > > [1] https://lore.kernel.org/all/CAPhsuW6c17p3XkzSxxo7YBW9LHjqerOqQvt7C1+S--8C9omeng@xxxxxxxxxxxxxx/ > > > > I have looked through the slides of this proposal, but failed to > > figure out how Song will design the BPF namespace. Maybe Song can give > > us a better explanation. > > Per my understanding, the goal of Song's proposal should be combined > > by many namespaces and other isolation mechanisms. For example, with > > the help of PID namespace, we can make sure only the tasks in this > > container can be traced by the bpf programs running in it. The proposal didn't really go anywhere. LOL. As Yafang said, it requires multiple mechanisms to work together, and thus is very complicated. OTOH, we are not sure whether BPF tracing is still useful when it is really safe. Specifically, probe_read is not safe, but really useful. A related idea is tracer namespace, presented by Mathieu Desnoyers at LPC 2022. [2] [2] https://lpc.events/event/16/contributions/1237/ > > > > Among the 5 items in [1], it looks like the third item "Limit which > BPF programs are accessible to non-root users" is what you proposed > here. The other items are more about isolation, I think. So, the > question is, if we have a BPF_ID namespace, would that be sufficient > for debugging in containers? If yes, at least it's something useful. > We can start from the BPF_ID namespace, bring it for discussion, and > gather other requirements gradually. BPF_ID namespace is a better defined idea. I am not sure whether we want the complexity of a namespace, though. Thanks, Song
