linux-kernel - Suggestion: LKM should be able to add system call for itself

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 7 Jul 2008 01:09:30 -0400
From:	"Jinkai Gao" <mickeygjk@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Suggestion: LKM should be able to add system call for itself

LKM(loadable kernel module) was first introduced for drivers. Users
rarely need to talk to the modules directly. If does, several methods
are available now, such as /proc file, interruption, etc. However,
these interfaces are predefined, which makes the communication between
user space and kernel space quite restricted. Although we can manage
to deliver the information or commands between them, the
implementation tends to be ugly.

Of course, for driver modules, these mechanisms are enough. But as
long as it is called Loadable Kernel Module instead of Loadable Kernel
Driver, I think it should be able to do more than that. For example,
LSM(linux security module),most of which(selinux, apparmor, etc.) use
policy files as their core. Users write policy files, LSM make access
control decision based on the files. Seems like users don't need to
talk to LSM directly. But what if user want to temporarily disable a
role or capability he is holding ? Not much he can do, isn't
it(although nothing is impossible, making a new system call makes much
more sense).

Above is to demonstrate that LKM is extension to kernel, and the
system calls should be able to extend as long as the kernel is
extending. So The LKM should be able to define its own user interface
by adding new system call for itself. And actually,  it is not hard to
implement such kind of dynamic system call table as I thought it
through.

There was time when people can modify the sys_call_table[],which has
been forbidden since it was realized as extremly dangrous operation.
But thing can be implemented in a safe way. Kernel may provide
registration function like this:

typedef int (*syscall_func_t)(struct pt_regs regs);
int syscall_register(char* name, syscall_func_t sys_call);

So that modules can add their own system call without affect the
original sys_call_table[]. And since the system call number will be
unpredictable, either we let users know the number, or we generate the
corresponding library function to make users' life easier.

This is my personal opinion, any criticism or correction is welcomed.
Thanks

---
Syracuse University
Jinkai Gao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/