Feature/fetch system info #945
Conversation
|
@AlonZivony , would you mind rebasing this interactively and drop the 2 commits you reverted, so history is not poluted ? Could you also rebase onto origin/main so the conflict is solved ? |
|
Alright, I have squashed all the commits into a single one so I could better understand what was being proposed. Maybe you should do the same ? Squash everything and explain in the commit log what is being done and why ? I think this is the first time a 'userland' event is being emulated through the EventConfig / EventsIDToParams logic. I like the approach. @yanivagman are you okay with that approach (likely you are even more into this than I am) ? Question: do we want to have this as a possible event driven interface for userland events ? Example: Another task 'requests' events to be printed from a new event channel (it could even be based in bpf maps since 2 userland tasks can 'talk' through the maps). Question: Can we ellaborate a little further what problem this is solving ? Perhaps document it together with a signature example using it ? |
|
About the squash, I usually want the history to represent exactly what was done so nothing would be missing if the approach taken is changed in the end. This is why I used 'revert' and not 'fixup' approach, so the history will remain linear. Squashing commits will make it harder to maintain the changes, but I saw that in large projects it is a common practice to squash commits when merging PRs. We can take this approach if you think it is the best practice for our case. About the documentation I will do it, I think that this is a good idea. Currently the event brings information I need for signature I write, but maybe I can create some small example. I doesn't need to be a real signature after all, just example. |
2cca659 to
e40d772
Compare
|
I noticed now that currently the event I creates cannot be unchosen by the -t flag. |
If you ask me, its weird to get an initial event out of nothing. At the same time... the name is 'system_info_fetch', so it kind of gives us an idea that it was automatically generated for a specific purpose. Now, thinking out loud:
Thinking a bit more:
What I don't know:
|
|
I see the main issue in what you wrote is the question if we want these user-mode events to be triggered by tracee-rules. What I think Counter argument About the current PR
|
I imagine that 'having both in the same tool' would be the option of running tracee as a library (idea that is already being worked on, right ?). I see pros and cons now, thank you.
Yep, I like the idea of 'event emulation' of this merge. Just wanted to antecipate if we would have to make it generic for other events - during runtime, per request - as well.
Yep, +1 here. I'll be happy to +1 this after you push this with that change.
Nah, we're good. I was catching up with the entire need/idea. Thanks for all the info. |
c8f575e to
078c442
Compare
|
Alright, the test looks good: and all the code seems like we've discussed previously. I would recommend that before merging this is squashed and the git log is similar to:
@itaysk you have subscribed as reviewer so I suppose you want to have the final word on this. I'm +1 as is with a single doubt: should we have the event default or make it available only by request ? |
0854c36 to
e3b839a
Compare
|
If you can enable the option for "squash merging" it would be great :) |
e3b839a to
0de5e44
Compare
0de5e44 to
6e62ea5
Compare
|
After a talk with Yaniv we decided to postpone the extraction of the consts package and as a result of the user-mode-events package that has to import it. |
There was a problem hiding this comment.
Two small comments.
Also not sure about the name system_info - as @itaysk suggeted - maybe we should call it init_namespaces instead (and if there will be other system info in the future, make other events as required)
e1064c3 to
aadc6cf
Compare
|
@AlonZivony please resolve conflicts so we will be able to merge |
cfbebc8 to
316a317
Compare
316a317 to
6843f1c
Compare
Created an event at the start of tracee-ebpf run that collect system information for the use of signatures that need it.