Enhance kernel version detection by using uname

[Vyom-Yadav]

• Refactored the detectKernelVersion function to not solely rely on vdsoVersion. Added a fallback mechanism using the KernelRelease function, which utilizes the uname system call to get the kernel release string.

---

I had vDSO disabled for tapping into some syscalls, so this is something good to have.

[brycekahle]

We moved away from uname because it is notoriously hard to parse, and often doesn't contain enough information to match the value the kernel expects (for kernels < 5.0).

You can always set ProgramSpec.KernelVersion if you don't want the library to automatically set the value.

[Vyom-Yadav]

We moved away from uname because it is notoriously hard to parse, and often doesn't contain enough information to match the value the kernel expects (for kernels < 5.0).

@brycekahle I added this as a fallback mechanism. Setting the flag manually v/s at least having something to get the kernel version 🤷🏼‍♂️

[brycekahle]

I understand, but this is more code to maintain for what sounds like a very narrow use case (vDSO disabled). See the code we removed in #500 for the old parsing code.

Maybe the maintainers feel differently, but my vote is to not add more maintenance burden.

[Vyom-Yadav]

I can see why the team took that decision. I was using Tetragon, and it isn't working with vDSO disabled, so I was trying to work around that somehow. I don't program using eBPF so I don't know how to set this up using some external Tetragon config, if possible.

[lmb]

I agree with Bryce, we've been down this path and it's not very pretty.

Out of curiosity, why do you have vDSO disabled? It'll cause a pretty massive slowdown for e.g. time related syscalls.

[Vyom-Yadav]

Indeed, it's not pretty, but that is just a backup option in case vdso is disabled.

It is not reducing any functionality, just enhancing it. It does not break anything.

I have vDSO disabled to tap into time syscalls. This would help in debugging unreproducible builds, so that's the reason behind it.

[lmb]

Discussed this with @ti-mo, we're not going to bring back uname parsing. That said, I think we should allow running without the vDSO.

In fact, the current version of the library shouldn't really rely on the vDSO any more since fbff7db Can you check which version of the library you are using at the moment? My guess is that you don't have the commit above. If that isn't true, please open a bug report that includes the error you are seeing and which version of the library you are using. We might be able to work around this in some other fashion.

[Vyom-Yadav]

@lmb Nope, it still doesn't work, I'm using Tetragon's latest ci images, and they have that particular commit.
time="2024-03-30T12:00:54Z" level=fatal msg="Failed to start tetragon" error="failed prog /var/lib/tetragon/bpf_exit.o kern_version 393472 loadInstance: opening collection '/var/lib/tetragon/bpf_exit.o' failed: program event_exit_disassociate_ctty: detecting kernel version: finding vDSO memory address: no vdso address found in auxv"

---

time="2024-03-26T13:29:51Z" level=fatal msg="Failed to start tetragon" error="failed prog /var/lib/tetragon/bpf_exit.o kern_version 394509 loadInstance: opening collection '/var/lib/tetragon/bpf_exit.o' failed: program event_exit_acct_process: detecting kernel version: finding vDSO memory address: no vdso address found in auxv"

[Vyom-Yadav]

@lmb Created #1408