fix(scap_engine_bpf): enable _64BIT_ARGS_SINGLE_REGISTER on ARM64

[Andreagit97]

Signed-off-by: Andrea Terzolo andrea.terzolo@polito.it

What type of PR is this?

/kind bug

Any specific area of the project related to this PR?

/area driver-bpf

/area libscap-engine-bpf

What this PR does / why we need it:

If we are on a 64-bit architecture we need to enable the _64BIT_ARGS_SINGLE_REGISTER macro and this is done correctly in our drivers. The problem is that when we compile scap we enable this define only in x86

#ifdef __x86_64__
      #define _64BIT_ARGS_SINGLE_REGISTER
#endif /* __x86_64__ */

So on ARM64, when we fill the filler table in the libscap bpf engine we use the wrong fillers for some syscalls:

#ifdef _64BIT_ARGS_SINGLE_REGISTER
	[PPME_SYSCALL_PREAD_E] = {FILLER_REF(sys_autofill), 3, APT_REG, {{0}, {2}, {3} } },
#else
	[PPME_SYSCALL_PREAD_E] = {FILLER_REF(sys_pread64_e)},
#endif
#ifdef _64BIT_ARGS_SINGLE_REGISTER
	[PPME_SYSCALL_PWRITE_E] = {FILLER_REF(sys_autofill), 3, APT_REG, {{0}, {2}, {3} } },
#else
	[PPME_SYSCALL_PWRITE_E] = {FILLER_REF(sys_pwrite64_e)},
 #endif

For PPME_SYSCALL_PREAD_E event we use the sys_pread64_e filler instead of sys_autofill and this cause an event drop since we define the sys_pread64_e in this way:

FILLER(sys_pread64_e, true)
{
#ifndef _64BIT_ARGS_SINGLE_REGISTER
    #error Implement this
#endif
	return PPM_FAILURE_BUG;
}

Causing a scap-open output similar to this:

---------------------- STATS -----------------------
events captured: 28545
seen by driver: 28741
Number of dropped events: 42
Number of dropped events caused by full buffer: 0
Number of dropped events caused by full scratch map: 0
Number of dropped events caused by invalid memory access: 0
Number of dropped events caused by an invalid condition in the kernel instrumentation: 42
Number of preemptions: 0
Number of events skipped due to the tid being in a set of suppressed tids: 0
Number of threads currently being suppressed: 0
-----------------------------------------------------

Which issue(s) this PR fixes:

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

NONE

[FedeDP]

/approve

[poiana]

LGTM label has been added.

Git tree hash: d497cd9e29995e9c47f52cb258879a9008c2005e

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Andreagit97, FedeDP

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Andreagit97,FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jasondellaluce]

Good catch!

[leogr]

LGTM