aya: Fix program loading on kernels with a patch > 255

[nrxus]

This fixes an issue that made aya not able to load eBPF programs on kernels with a patch number greater than 255.

I noticed this when trying to load some eBPF programs on an AWS instance running a 4.14.304-226.531.amzn2.x86_64 kernel. The kernel code that it tried to load was for a 4.15 kernel instead which caused a verifier error.

I considered doing this directly in the KernelVersion::current function but per the comments in: torvalds/linux@9b82f13 it looks like the clamp should only be applied for the context of creating the LINUX_VERSION_CODE so I limited the fix to only the calculating of the code for bpf prog loading.

[netlify]

✅ Deploy Preview for aya-rs-docs ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	0a6a267
🔍 Latest deploy log	https://app.netlify.com/sites/aya-rs-docs/deploys/651462d4578e220008f0ff0e
😎 Deploy Preview	https://deploy-preview-791--aya-rs-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[alessandrod]

Thanks! Could you also paste the verifier error? @marysaka has been using kernels with patch > 255 so I'm wondering how we missed this failure and where it shows up

[marysaka]

I'm pretty sure I tested kernel with patch > 255 apart from Debian ones as I was testing all kernel of every major distro around (cc @Arignir could you confirm that?)

[nrxus]

Could you have been using kernels that are above 5.0? Starting on 5.0 the checks for kern_code were skipped: torvalds/linux@6c4fc209fcf9

The verifier doesn't have any output on the error, it just returns an EINVAL. The way we realize it was due to an incorrect kern_code was by straceing the syscall and saw that it was emitting a code for a 4.15 kernel

[tamird]

I added clamping logic in 6e570f0 -- maybe that was overly specific to 4.19.x and can be relaxed rather than adding disjoint logic?

[tamird]

The commit you linked first appeared in 5.x kernels - how does libbpf deal with this case on that aws 4.14 kernel?

[nrxus]

I added clamping logic in 6e570f0 -- maybe that was overly specific to 4.19.x and can be relaxed rather than adding disjoint logic?

I saw that clamping code but I wasn't sure if that was meant for checking the kernel version in major/minor/patch form or if it was meant specifically to clamp the code during prog load. For this PR I specifically only want to target the kern code during prog load.

The commit you linked first appeared in 5.x kernels - how does libbpf deal with this case on that aws 4.14 kernel?

The helper in libbpf clamp the patch to 256 regardless of the major/minor version:
https://github.com/torvalds/linux/blob/d90b0276af8f25a0b8ae081a30d1b2a61263393b/tools/lib/bpf/bpf_helpers.h#L74

[tamird]

Even that macro appeared fairly late torvalds/linux@9ae2c26

[nrxus]

It looks like libbpf when doing prog load relies on the kernel provided KERNEL_VERSION_CODE macro if I understand this thread correctly: https://lore.kernel.org/lkml/2023041729-luckiness-active-3ddb@gregkh/T/. Since aya couldn't use that then I think it should clamp to 255 which is what newer kernel versions do when calculating the kernel version code

[alessandrod]

My thoughts so far: I like the idea of clamping only when generating the kernel code, instead of always clamping in KernelVersion::current() - API wise a caller might want to get the actual patch level for other puposes not necessarily for generating a kernel code.

Once we split code generation, we can clamp regardless of 4.x 5.x X.x?

[nrxus]

Does this mean you'd like me to move the pre-existing clamping code into the crate public method I created?

[alessandrod]

Does this mean you'd like me to move the pre-existing clamping code into the crate public method I created?

Yes, I don't think clamping slightly differently in two difference places is a good idea

[tamird]

Nice archaeology digging up all the commits.

[nrxus]

The integration tests are failing on something unrelated, the image that it is trying to use is no longer available in the Debian ftp. I am not really sure what image would be more stable so you all don't have to keep fixing it every few weeks though

[tamird]

I'm pretty confused about that - I took a look earlier and the most recent 6.4.0-x image is

linux-image-6.4.0-0.deb12.2-cloud-amd64-unsigned_6.4.4-3~bpo12+1_amd64.deb	2023-08-16 06:27	26M

I don't understand why it would have been reverted back to August 16.