Querying the XDP program that is attached to an interface

[mpastyl]

Hi, I would like to query which XDP program (if any) is attached to an interface and trying to figure out if there is support for that.

I managed to make it work by extending the wrappers around the main BPF syscall with a LinkGetNextID, similar to ProgramGetNextID and I can open a PR if you are interested in that.
But I am wondering if I am missing a more obvious way to do it.

PS. There is a QueryPrograms that returns attached programs and any links they might have. Unfortunately, AFAIU, the underlying syscall does not support the BPF_XDP attach type.

[florianl]

Without further information, it might be hard to get from a Link to an interface. In addition, Link is only supported for Linux kernel version 5.7 and newer iirc.

Instead of querying the BPF syscall, I would recomment to walk the interfaces using rtnetlink. As shown in the example, one can query all interfaces quite easily and then further check the XDP element in the LinkAttributes in the returned LinkMessage. LinkXDP holds FD, which can be used as argument to NewProgramFromFD() to resolve the eBPF program.

[mpastyl]

Correct, I don't have easy access to the link. However, I was able to get it by extending the link package with a LinkGetNextID() and a NewLinkFromID(), which also includes extending the sys package a little bit to implement a bpf sycall for BPF_LINK_GET_FD_BY_ID and BPF_LINK_GET_NEXT_ID.

So let me rephrase my original question, because I think I did a poor job explaining my intentions 😄
Are you interested in me opening a PR with the extensions mentioned above? Or should this use case better be handled with the help of another library, such as rtnetlink as @florianl pointed out.

[lmb]

Iterating bpf_links is definitely in scope, your contribution would be very welcome. I think it would make sense to base the code on

ebpf/btf/handle.go

Lines 200 to 260 in 65fb774

	// HandleIterator allows enumerating BTF blobs loaded into the kernel.
	type HandleIterator struct {
	// The ID of the current handle. Only valid after a call to Next.
	ID ID
	// The current Handle. Only valid until a call to Next.
	// See Take if you want to retain the handle.
	Handle *Handle
	err error
	}
	// Next retrieves a handle for the next BTF object.
	//
	// Returns true if another BTF object was found. Call [HandleIterator.Err] after
	// the function returns false.
	func (it *HandleIterator) Next() bool {
	id := it.ID
	for {
	attr := &sys.BtfGetNextIdAttr{Id: id}
	err := sys.BtfGetNextId(attr)
	if errors.Is(err, os.ErrNotExist) {
	// There are no more BTF objects.
	break
	} else if err != nil {
	it.err = fmt.Errorf("get next BTF ID: %w", err)
	break
	}
	id = attr.NextId
	handle, err := NewHandleFromID(id)
	if errors.Is(err, os.ErrNotExist) {
	// Try again with the next ID.
	continue
	} else if err != nil {
	it.err = fmt.Errorf("retrieve handle for ID %d: %w", id, err)
	break
	}
	it.Handle.Close()
	it.ID, it.Handle = id, handle
	return true
	}
	// No more handles or we encountered an error.
	it.Handle.Close()
	it.Handle = nil
	return false
	}
	// Take the ownership of the current handle.
	//
	// It's the callers responsibility to close the handle.
	func (it *HandleIterator) Take() *Handle {
	handle := it.Handle
	it.Handle = nil
	return handle
	}
	// Err returns an error if iteration failed for some reason.
	func (it *HandleIterator) Err() error {
	return it.err
	}

(but call it link.Iterator instead or something along those lines.)

[mpastyl]

Thanks a lot!

[ti-mo]

Something I didn't see mentioned in the thread: check out link.QueryPrograms. It will return a set of program IDs, either attached using netlink, prog_attach for cgroups, as well as everything attached using bpf() (tcx, xdp_link, netkit).

You won't be able to retrieve the link, but to check for XDP attachment to a specific interface in a generic way, I think it's your best bet. You can check out how we use it in cilium/cilium for inspiration.

Those link_get_next patches would still be welcome if you haven't sent them already!

[mpastyl]

You can check out how we use it in cilium/cilium for inspiration.

Thanks for the hint, I will take a look.

Those link_get_next patches would still be welcome if you haven't sent them already!

Sorry, I forgot to mention it here, but the changes have been merged :) #1392
Let me close the discussion here, since it can now be done via iterating over the links.