For now, this issue can be solved by enrolling our kernel module into the customer's system. We can identify that the Secure Boot is enabled in their system if the following log messages can be seen in ds_agent.log:
2023-03-10 09:17:20.502184 [+0400]: [Info/5] | Secure Boot enabled: true | dsa/SecureBoot.lua:160:LogSecureBootStatus | 683:7F8512FFF700:dsa.Scheduler_0001 2023-03-10 09:17:20.502286 [+0400]: [Warning/2] | Key not enrolled: /opt/ds_agent/DS20.der, detail might be logged when Agent is just started | dsa/SecureBoot.lua:170:LogSecureBootStatus | 683:7F8512FFF700:dsa.Scheduler_0001 2023-03-10 09:17:20.502360 [+0400]: [Warning/2] | Key not enrolled: /opt/ds_agent/secureboot/DS20_v2.der, detail might be logged when Agent is just started | dsa/SecureBoot.lua:170:LogSecureBootStatus | 683:7F8512FFF700:dsa.Scheduler_0001
Secure Boot is a feature in the BIOS that does not allow third-party kernel modules from loading into the system. As our kernel module is not trusted by the system by default, the customer needs to enroll Trend Micro's public key into their system first, then our kernel module should be able to be loaded into the customer's system.
To enroll a Trend Micro public key into the system, you can refer to this article.
It is recommended to contact Trend Micro Technical Support if you encounter the system hang issue, and see the following entry in the ds_agent.log file:
2023-03-10 09:17:20.502184 [+0400]: [Info/5] | Secure Boot enabled: false | dsa/SecureBoot.lua:160:LogSecureBootStatus | 683:7F8512FFF700:dsa.Scheduler_0001