chore(ci): mirror unit and integration tests to arm64

[NDStrahilevitz]

1. Explain what the PR does

"Replace me with make check-pr output"

2. Explain how to test it

3. Other comments

Resolve #4621
Related #4162

[NDStrahilevitz]

Both red from bugs, which is good in the sense we have increased coverage. I will be fixing these and then opening to review.

[NDStrahilevitz]

1. Unit tests
   • data_test.go: Matching 'syscall' data value of sys_enter as string & Matching 'syscall' data value of hooked_syscall as int
     • Filter defined with string syscall -> converted to int via event definitions
     • Match fails because arm64 syscall event ids differ
     • Possible resolution: formatted strings with programmatic access to the event id
   • "Test O_RDWR | O_CREAT | O_DSYNC | O_LARGEFILE”
     • One of the flags is expanded to include “O_NOFOLLOW” in the string in ARM64. The values creating the flag are arch-neutral (supposedly, from events/parsers/data_parsers.go), but are then converted according to arch-specific parsing values (in events/parsers/data_parsers_arch.go).
2. Integration Tests
   • Test_EventFilters/comm:_event:_data:_trace_event_set_in_a_specific_policy_with_data_from_fakeprog1_and_fakeprog2_commands
     • Tests for Open and Openat syscalls from the syscaller program. The event ids are set programatically which means this shouldn’t be the issue, unlike unit tests.
     • Therefore the issue is likely a mismatch in arguments or that ARM64 machines will emit a different syscall than intended in this scenario

This raises the need to normalize syscall ids at the definition layer. I think it also implies that we shouldn’t allow setting syscall filters with numerical ids, we should enforce a string usage and provide system appropriate parsing. I am not sure what to make of the flag situation currently, nor the integration test failure.

@geyslan FYI

[geyslan]

This raises the need to normalize syscall ids at the definition layer.

For sure, and as we've discussed priorly, one idea is to use the same ids given to grpc api, then any consumer should use only that. Maybe we need to convert all syscall event IDs to a common set - architecture independent. They should align to Tracce's detected syscalls and could be translated in (comming from ebpf) and out (on the event emission) depending on the architecture.

I think it also implies that we shouldn’t allow setting syscall filters with numerical ids, we should enforce a string usage and provide system appropriate parsing.

If we use a common set for Tracee itself, the numeric id wouldn't be a problem - but I assume that it could confuse the user trying to set a syscall ID based on its own arch. So maybe enforcing a syscall as string would be a better solution as you thought for filters. But I'm for the common set (performance wise).

I am not sure what to make of the flag situation currently, nor the integration test failure.

I'm pinging @rscampos to give us a hand as he loves arm64.