aarch64-linux support

[06kellyjac]

aarch64-linux support tracker

---

Current build issues:

# github.com/quarkslab/kdigger/pkg/plugins/syscalls
pkg/plugins/syscalls/syscalls.go:155:7: undefined: unix.SYS_SELECT
pkg/plugins/syscalls/syscalls.go:156:7: undefined: unix.SYS_PAUSE
pkg/plugins/syscalls/syscalls.go:163:7: undefined: unix.SYS_FORK
pkg/plugins/syscalls/syscalls.go:164:7: undefined: unix.SYS_VFORK
pkg/plugins/syscalls/syscalls.go:173:47: undefined: unix.SYS_SELECT
pkg/plugins/syscalls/syscalls.go:173:72: undefined: unix.SYS_PAUSE
pkg/plugins/syscalls/syscalls.go:183:40: undefined: unix.SYS_FORK
pkg/plugins/syscalls/syscalls.go:183:63: undefined: unix.SYS_VFORK
pkg/plugins/syscalls/syscalls.go:230:12: undefined: unix.SYS_OPEN
pkg/plugins/syscalls/syscalls.go:234:12: undefined: unix.SYS_STAT
pkg/plugins/syscalls/syscalls.go:234:12: too many errors
github.com/quarkslab/kdigger/pkg/plugins/authorization

Original post

# github.com/quarkslab/kdigger/pkg/plugins/syscalls
pkg/plugins/syscalls/syscalls.go:155:7: undefined: unix.SYS_SELECT
pkg/plugins/syscalls/syscalls.go:156:7: undefined: unix.SYS_PAUSE
pkg/plugins/syscalls/syscalls.go:163:7: undefined: unix.SYS_FORK
pkg/plugins/syscalls/syscalls.go:164:7: undefined: unix.SYS_VFORK
pkg/plugins/syscalls/syscalls.go:173:47: undefined: unix.SYS_SELECT
pkg/plugins/syscalls/syscalls.go:173:72: undefined: unix.SYS_PAUSE
pkg/plugins/syscalls/syscalls.go:183:40: undefined: unix.SYS_FORK
pkg/plugins/syscalls/syscalls.go:183:63: undefined: unix.SYS_VFORK
pkg/plugins/syscalls/syscalls.go:230:12: undefined: unix.SYS_OPEN
pkg/plugins/syscalls/syscalls.go:234:12: undefined: unix.SYS_STAT
pkg/plugins/syscalls/syscalls.go:234:12: too many errors
github.com/quarkslab/kdigger/pkg/plugins/authorization

on aarch64-linux and x86_64-darwin

are there plans for supporting non-x86_64-linux platforms in the future or no?

[mtardy]

Yes, that's why I set the build to Linux x86 here. In fact, we could have a _linux or _darwin version to handle this (by just skipping the syscall scan on macOS) but I don't think it's really relevant to run kdigger on macOS (I work on macOS x86 myself).

Since you shouldn't be supposed to run kdigger on your host directly (in principle) but in pods on nodes that are running mostly Linux, I don't think it's really interesting. Maybe Linux arm64 would be of more interest. If you really need to run on macOS x86, I would be super interested to know why and could fix it! The only thing I can think of is to scan the admission control chain; maybe, this is one of the only remote features (along with version, authorization and apiresources, but they are easily replaceable with kubectl).

[06kellyjac]

yeah your darwin point makes total sense, not sure what I was thinking 😅 yeah unless there are more external client -> cluster (kubectl style) features there's not much point in a darwin build

I could see aarch64-linux being handy for some workloads but yeah x86_64-linux is by far the most useful

[06kellyjac]

I've updated the ticket to track (potential) aarch64-linux support

[mtardy]

Hehehe 😃 thanks! I didn't know if anyone was interested in other architectures, but I'd be happy to implement it if anyone needs it!