btf: Add BTF layout header parsing

In kernel 7.1 the BTF header for BTF v1 was extended to now include
two optional fields. These fields hold a offset and length for BTF
layout information, a new BTF feature. When we encountered a BTF header
with these fields set to non-zero values, we would fail to parse the
header and thus fail to parse the BTF data altogether.

This commit adds support for parsing the new header fields, and ignores
them for now. Support for the BTF layout feature will be added in the
future, but this change ensures the latest version of the library
stays compatible with the latest kernels.

Signed-off-by: Dylan Reimerink <dylan.reimerink@isovalent.com>

btf: add Builder.Spec

When collecting and merging BTF types from multiple ELFs, it's convenient to be
able to query the resulting Spec in a single step. This commit adds the
Builder.Spec method to avoid having to write the BTF blob out to a file and
read it back from the filesystem.

Also add a test that checks if two identical types get correctly deduplicated
so they can be queried with AnyTypeByName afterwards.

Signed-off-by: Timo Beckers <timo@isovalent.com>

struct_ops: skip copy for zeroed nested structs and fail on non-zeroed

resolves #1880

Signed-off-by: shun159 <dreamdiagnosis@gmail.com>

linker: do not error out when there is nothing in `/sys/kernel/btf`

9958a4f allowed to perform CO-RE
against all kernel modules, but introduced a small regression where
kernels with no BTF would fail to perform CO-RE with the manually
provided types. This commit fixes the issue by skipping the modules
BTF collection if there is nothing in `/sys/kernel/btf`.

Signed-off-by: Paul Cacheux <paul.cacheux@datadoghq.com>

golangci-lint: ignore QF1010 (convert byte slices to strings before p…

…rinting)

Printing a []byte and a string([]byte) are not the same thing. We typically print
bytes on purpose, so we don't need this linter.

Fixed one case where we should've been using t.Log instead of fmt.Println anyway.

Signed-off-by: Timo Beckers <timo@isovalent.com>

Fix ksym buffer overrun on 32 bit platforms

Commit 78074c5 ("info: expose more prog jited info"), which made its
way into v0.17.0, resulted in random runc CI failures when running i386
binary on an amd64 kernel (see [1]).

Apparently [2], the kernel always returns 64-bit pointers, so uint64
(rather than uintptr) should be used for ksyms slice regardless of
the platform to avoid the buffer overrun.

Now, to keep the public API of (*ProgramInfo).JitedKsymAddrs intact,
convert those addresses back to uintptr, as it was done before
commit 78074c5. Except, if the kernel address won't fit into an
uintptr (as it is the case when running i386 binary on an amd64 kernel),
return an empty slice and a false, rather than incorrect addresses.

[1]: opencontainers/runc#4594
[2]: https://github.com/torvalds/linux/blob/2014c95afecee3e76ca4a56956a936e23283f05b/kernel/bpf/syscall.c#L4840-L4846

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>

internal: add OnLinux constant

Add a constant which indicates whether we are building for Linux.
This is so that we can write

	if !internal.OnLinux {

instead of

	if runtime.GOOS != "linux" {

This makes it easy to remove platform dependent code by removing the
constant and then fixing the breakage.

Signed-off-by: Lorenz Bauer <lmb@isovalent.com>

prog: fix shadowing log size variable in verifier log retry loop

When ProgramOptions.LogSize was removed in 0.16, the tests weren't updated to
exercise the retry loop, since a minimum log size was chosen that was larger
than what the test program could generate.

With the addition of LogSizeStart, this notoriously fragile code broke when
logSize was again tracked as a separate variable, while being accidentally
shadowed within the scope of the for loop. This resulted in an endless loop
on kernels without the LogTrueSize field.

Remove the shadowing and fix the tests.

Signed-off-by: Timo Beckers <timo@isovalent.com>

examples: tcx: use Variable API

This commit updates the `example/tcx` program to use the new Variable API
rather than traditional bpf maps. The example already depends on `bpf_link`,
which requires kernel >= v6.6, therefore the Variable API is already
supported and working (since v5.5).

Signed-off-by: Simone Magnani <simone.magnani@isovalent.com>

map: remove misleading error message when creating without BTF

Time and time again people misunderstand errors like the following:

    map create: cannot allocate memory (without BTF k/v)

Instead of focusing on the ENOMEM they assume that it has something
to do with BTF. In reality it just means that creating a map has
failed, and we didn't supply any BTF during creation.

Avoid this confusion by removing the "without BTF k/v" part.

Signed-off-by: Lorenz Bauer <lmb@isovalent.com>