Views:
 
For information on platforms and kernel versions affected by BHI, refer directly to the Deep Security 20.0 Supported Linux Kernels document. Look for entries marked with a Δ symbol (delta).

For more information on the BHI Issue, please refer to: Branch History Injection (BHI) changes since Linux Kernel 6.9-rc4+ in Deep Security

Limitations

  • ds_am unloads tmhook when the Deep Security Agent (DSA) is shut down, restart, all related features (AM/AC/IM/AcM) are disabled, or the user-mode solution is applied. However, if tmhook live-patch is applied, unloading is restricted in the following cases:
    1. Legacy Agent Versions: For DSA versions prior to 20.0.1-17380, the agent does not automatically unpatch, so the tmhook doesn't be unload.
    2. Oracle UEK Constraints: On Oracle UEK, only patching is supported. Unpatching is restricted to prevent kernel panics due to synchronous handling requirements.
      A system reboot is required to unpatch tmhook. However, the DSA starts automatically during boot and would normally reload the drivers. To prevent the tmhook live-patch from being reapplied by the DSA during startup, please switch to user mode before performing the reboot.
  • Coexistence Conflicts with Kernel Hooking: Conflicts occur if multiple modules attempt to hook the same kernel entry point.
    • If another module hooks the entry point first, the tmhook live-patch will fail. Conversely, if tmhook has already patched the kernel, subsequent hooking attempts by other modules may be blocked or fail to deploy.

How to Verify Whether tmhook Uses Live-Patch

After tmhook is loaded, check dmesg logs for the following string: 

tmhook: tmhook 1.2.2103 loaded
livepatch: 'tmhook': patching complete

If present, this indicates that the tmhook live-patch solution is active.

Related Issues and Workarounds

Ksplice/KLP reject patching when the kernel is “salted”

Most Linux distributions rely on native kernel live-patching, except Oracle and SUSE, which use their own solutions (Oracle Ksplice and SUSE KLP). These tools requires the kernel to be clean. If the kernel is already patched (i.e., “salted”), they will reject the patching request.

If any one of the AM, AC, IM, or AcM features is enabled before executing Ksplice/KLP, tmhook will patch the kernel first. This "salts" the kernel, causing Ksplice/KLP to reject their own patching attempts.

If you need to apply kernel updates via Ksplice or KLP, follow these steps:

  1. Switch to user mode in Trend Vision One Workload & Server Protection / Deep Security
  2. Reboot machine in UEK environment
    • In oracle UEK kernel, since unpatching is not supported, removing the tmhook live-patch requires rebooting.
  3. Apply Ksplice/KLP patches
  4. Switch to kernel mode (auto mode) or Not
     
    Be aware of the feature differences between User Mode and Kernel Mode. Refer to the documentation links below for details.

If tmhook live-patching fails

Due to architectural limits, tmhook cannot coexist with other modules patching the same hook points. If another module hooks the kernel first, the tmhook live-patch will fail.

In this scenario, the AM/AcM triggers an alert and automatically falls back to Basic Function Mode ( a user mode solution) by default, but AC/IM will be offline(as user-mode solutions are not yet available for these modules). To resolve this, please choose one of the following actions:

  • Switch to User Mode solution by configuration (For AM/AcM): This clears the alert while continuing to use the user mode solution for protection.
  • Ensure no conflicting kernel modules are active: Disable other modules that hook the kernel to allow tmhook to patch the kernel first.

Other References

Trend Vision One

Deep Security

Keywords: Deep Security Update,BHI,KSP,Unexpected Behavior,TMhook Driver, branch history injection, solution and limitations, tmhook