Open AlonZivony opened 1 year ago
This is a general problem we have across flag arguments see here #2190. If it's ok for you, it would be nice if you could make your solution extendible to the other events with flags
arguments.
Also, we now have access to the libbpfgo helpers in signatures so that may make the work easier in tracee itself too.
The problem with what you propose is that each syscall has its own flags. You need to have a dedicated function for each type of flags to be able to parse them, so it isn't possible to make it a generic flags parsing.
We can create a generic function that get the event ID and parse the flags accordingly, but it will just call the dedicated functions behind the scenes... So this means in my opinion that creating a generic function is relevant to another issue and PR and not specifically to this issue.
We can create a generic function that get the event ID and parse the flags accordingly, but it will just call the dedicated functions behind the scenes... So this means in my opinion that creating a generic function is relevant to another issue and PR and not specifically to this issue.
This is what I mean, that the infrastructure you create for handling this event's flags can be later extended for other flag types. I'm aware that we have multiple flag types, IIRC between open and exec as well. I have a start for different argument types filtering (for the syscall argument need) here #2251, but if you propose something different I can also fit the solution there to yours.
The only thing I can think of is like I wrote before - function that parse flags according to eventID+flags
func ParseFlags(eventID events.ID, flags int) (helpers.SystemFunctionArgument, error) {
...
switch eventID {
case events.Clone:
return helpers.ParseCloneFlags(uint64(flags))
...
}
It might be a bit of a bad practice to return an interface though...
It might be a bit of a bad practice to return an interface though...
I actually think it's a good start for the internal mechanism. I think it would be best in a FlagsFilter
, that would do this work, and we could use from libbpfgo OptionAreContainedInArgument
since that already gives a bool check for the flags we want to be set, so we could skip the parsing.
Then the options we check we can parse from the cli and store them per context (so for openat, O_RDONLY
but for security_file_open maybe O_WRONLY
).
Yea I agree it sounds better than really parsing it.
You do need to notice that sometimes there are values hidden in the flags, like HUGE_TLB
size in the flags of the mmap
syscall. That might require some deeper logic. But we can make the interface you propose to work with it.
We already decode some of the syscall arguments, but there are still some syscall arguments for which we don't decode the argument values although it can be useful.