falco-driver-loader improvements (custom driver name + clean previous drivers functionality)

[leodido]

What type of PR is this?

/kind documentation

/kind feature

Any specific area of the project related to this PR?

NONE

What this PR does / why we need it:

It lets users specify a custom DRIVER_NAME getting it from the environment. It can be useful when the user has a Falco kernel-module with a different name (eg., falco_probe) from the current default one (ie., falco).

This way (DRIVER_NAME=falco_probe falco-driver-loader module) it will look for a kernel module (via lsmod) named falco_probe and remove it (rmmod).

Furthermore, the module should also be removed from dkms. WIP for this reason.

Last but not least, for debugging and clarity purposes, this PR make the falco-driver-loader script aware of the Falco version it has been built for.

And outputs it at:

• runtime time
• help/usage time

Which issue(s) this PR fixes:

Fixes #1486

Special notes for your reviewer:

/cc @leogr
/cc @fntlnz

Does this PR introduce a user-facing change?:

new: falco-driver-loader script can get a custom driver name from DRIVER_NAME env variable
new: falco-driver-loader know the Falco version

[leodido]

/milestone 0.27.0

[leogr]

Thank you for this PR. We definitely need that 👍

Although specifying a custom DRIVER_NAME can be useful for various reasons, I believe it's not the best way to clean up old drivers since:

• the script will then try to insmod/modprobe with the given DRIVER_NAME
• the script does not have action only to remove the driver

Thus, as discussed privately, I believe it worth adds just a specific cleanup command for the old falco_probe that we don't use anymore. I will investigate on that.

[leodido]

Yep, that's the reason this PR is WIP @leogr :)

As discussed privately, we probably need to add 3rd action for the script (eg., falco-driver-loader clean)

[leogr]

Yep, that's the reason this PR is WIP @leogr :)

As discussed privately, we probably need to add 3rd action to the script (eg., falco-driver-loader clean)

That's ok for me too. But, do we still want a simple clean-up for falco_probe that runs always (I mean, before installing the kernel module)?

[leodido]

That's up to us to decide.

My personal vote is to leave the behaviour as it currently is and just add a clean command to the script to be run for special use cases - ie., user want to remove a old/different kernel module (falco_probe.ko, even from dkms, not only rmmodding it) but then wants to install a new one (eg., falco.ko)

[leogr]

Ok, let's do this step-by-step.

So I can work on the clean action since I believe we all agree on that.

[leodido]

Yes, we all agree on that. As also discussed privately. :)

Then, we could also think about how to make the upgrade process straightforward even if the driver name changes again.
And, given that a new kernel module name change is very unlikely: if it's worth.

[leogr]

Yes, we all agree on that. As also discussed privately. :)

Done by aa892e4 :)
It's the first draft anyway, so PTAL.

Then, we could also think about how to make the upgrade process straightforward even if the driver name changes again.
And, given that a new kernel module name change is very unlikely: if it's worth.

👍

[poiana]

LGTM label has been added.

Git tree hash: c7883d2b3b5513cff0688e4579695580d2e57cb7

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fntlnz, leogr

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 [fntlnz,leogr]

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