Ksplice will not modify any hooked functions, as it ensures that patching does not happen unless the function's code exactly matches what Ksplice expects (the original compiled code). Since an interception code hook overwrites the start of the function, Ksplice will notice this and abort application of that patch as a safety measure.
Oracle is currently looking into providing a way for add-on kernel products to communicate with Ksplice tools and automate everything to make coexistence more user-friendly. In the short term, the following actions will ensure that the products coexist together.
1. Disable the product's kernel components with <command>
2. Perform the Ksplice kernel patching commands provided by the operating system
3. Re-enable the product with <command>
Once Ksplice does additional live patching, the function address list (kallsyms) is updated for the patched function(s), so the product should be able to patch the fixed version of the function fine, just as it did for the original version. The disable/enable commands only need to do what's necessary to restore the function code that was modified with the interception hooks.
In Deep Security perform the following action.
1. Stop the Deep Security Agent service.
- service ds_agent stop
Run these commands to confirm the following kernel modules have been unloaded. We should no longer see these kernel drivers in a loaded state. (gsch, redirfs, tmhook, dsa_filter)
- lsmod | grep gsch
- lsmod | grep ds
2. Perform the Ksplice kernel patching commands.
3. Start the Deep Security Agent service.
- service ds_agent start