在某些内核版本中,可以通过更改 sys_call_table 来添加或修改系统调用。但由于该表不打算在运行时更改,因此它没有保护。更改表将导致竞争条件。即使没有竞争条件,在使用或堆叠模块时移除模块也会出现问题。由于从模块更改 sys_call_table 时出现问题,该符号不再在新内核中导出。换句话说,如果在尝试加载模块时收到“unresolved symbol sys_call_table”,则意味着该模块中存在错误,并且内核不再接受此类有错误的模块。
In some kernel versions it is possible to add or modify a systemcall by changing the sys_call_table. But because this table is not intended to be changed at runtime, it has no protection. Changing the table will lead to race conditions. Even without the race conditions, there are problems related to removing the modules while they are in use or stacked. Because of the problems with changing sys_call_table from modules, the symbol is no longer exported in new kernels. In other words if you get "unresolved symbol sys_call_table" when trying to load a module, it means there is a bug in the module, and the kernel does no longer accept such buggy modules.
Sounds like a really bad idea, regardless of whether you can. If your new system call will operate on files/devices, perhaps you could make it an ioctl or something similar rather than making it its own syscall?
在某些内核版本中,可以通过更改 sys_call_table 来添加或修改
系统调用
。但由于该表不打算在运行时更改,因此它没有保护。更改表将导致竞争条件。即使没有竞争条件,在使用或堆叠模块时移除模块也会出现问题。由于从模块更改 sys_call_table 时出现问题,该符号不再在新内核中导出。换句话说,如果在尝试加载模块时收到“unresolved symbol sys_call_table”,则意味着该模块中存在错误,并且内核不再接受此类有错误的模块。In some kernel versions it is possible to add or modify a
systemcall
by changing the sys_call_table. But because this table is not intended to be changed at runtime, it has no protection. Changing the table will lead to race conditions. Even without the race conditions, there are problems related to removing the modules while they are in use or stacked. Because of the problems with changingsys_call_table
from modules, the symbol is no longer exported in new kernels. In other words if you get"unresolved symbol sys_call_table"
when trying to load a module, it means there is a bug in the module, and the kernel does no longer accept such buggy modules.