fix empty arguments resolution

[ShohamBit]

1. Explain what the PR does

• fix issue Failure in argument name resolution results in empty value #3892
• fix the empty result of failed parse helper argument
• add test to parse_args_helper.go

make check-pr:

1cbdc3d tests: add argument parsers tests
69d55cb fix: empty arguments resolution

69d55cb fix: empty arguments resolution

When tracee tries to resolve a numeric argument to a string (e.g. cmd value of
bpf syscall), if the resolution fails, the event field will contain an empty
string.

Return the raw value as a string in case of a failed resolution.

2. Explain how to test it

In order to test you can run the test in the file with this command

GOOS=linux CC=clang GOARCH=amd64 CGO_CFLAGS="-I/tracee/dist/libbpf -I/tracee/3rdparty/libbpf/include/uapi" CGO_LDFLAGS="-L/tracee/dist/libbpf/obj -lbpf" \
go test \
	-tags ebpf \
        -v \
        -short \
	-race \
	-coverprofile=coverage.txt \
	./pkg/events -run TestParseArgsHelpers

• this will run the test functions for parse_args_helpers.go file
• you can change TestParseArgsHelpers to a function name like: TestParseBPFCmd to test a more specific

3. Other comments

Resolves #3892

[yanivagman]

Let's change all parsers inside this file that currently return an empty value on an error to return the raw value instead

[ShohamBit]

Let's change all parsers inside this file that currently return an empty value on an error to return the raw value instead.

Okay, but I think the code is still going to look weird because if we just print the information without any need for processing it behind the scenes, why would we write the function like this:

func funcArg(arg *trace.Argument, val uint64) {
    arg.Type = "string"
    argument, err := parsers.funcArg(mode) 
    if err != nil {
        arg.Value = "" 
        return 
    }
    arg.Value = argument.String() 
}

instead of like this:

func funcArg(arg *tracee.Argument, val uint64) {
    arg.Type = "string"
    arg.Value = val 
}

or just remove it entirely?

It looks pretty weird that we check for an error and don't even use it.

Note: Not every function behaves like this, but most of them do.

[oshaked1]

It looks pretty weird that we check for an error and don't even use it.

We do use the error, that way we know to use the raw value.

[yanivagman]

Let's change all parsers inside this file that currently return an empty value on an error to return the raw value instead.

Okay, but I think the code is still going to look weird because if we just print the information without any need for processing it behind the scenes, why would we write the function like this:

func funcArg(arg *trace.Argument, val uint64) {
    arg.Type = "string"
    argument, err := parsers.funcArg(mode) 
    if err != nil {
        arg.Value = "" 
        return 
    }
    arg.Value = argument.String() 
}

instead of like this:

func funcArg(arg *tracee.Argument, val uint64) {
    arg.Type = "string"
    arg.Value = val 
}

or just remove it entirely?

It looks pretty weird that we check for an error and don't even use it.

Note: Not every function behaves like this, but most of them do.

Because the parsers return the parsed value of the argument. For example, if some (fake) argument has a raw value 0x4 which means F_WRITE, the output string will be "F_WRITE". However, if it has a value of 0x20, but the parsers don't know this value, an error will be returned. In this case, we can simply return the string value of the raw argument, which is "0x20"

[oshaked1]

LGTM

[ShohamBit]

@yanivagman I added tests for parse_args_helpers.go

[geyslan]

Put some thoughts.

[rscampos]

@ShohamBit

Since the cmd field from both ebpf and security_bpf is int, shouldn't we use the following instead?

arg.Value = strconv.FormatInt(int64(cmd), 10)

If we use BPF_INVALID_CMD=-1 in the python script, the Tracee result in cmd field is 18446744073709551615 (0xFFFFFFFFFFFFFFFF) and not -1, take a look:

sudo ./dist/tracee -e bpf -s comm=python3.10
TIME             UID    COMM             PID     TID     RET              EVENT                     ARGS
06:13:50:764876  1000   python3.10       117825  117825  -1               bpf                       cmd: 18446744073709551615, attr: 0x0, size: 0

[ShohamBit]

well as you can see the cmd arg is unit64 and not int64, do you suggest we change it to int64?

[rscampos]

I was discussing it with @geyslan and decided to open this issue #4504. Realized that there are some casting between int and uint that should be avoid (at least from my understanding).

[ShohamBit]

I reviewed this issue and think it is a great addition, also removes unnecessary casting that will also resolute in better performance

[yanivagman]

LGTM