linux-kernel - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 7 Jul 2008 10:00:50 -0400
From:	"Jinkai Gao" <mickeygjk@...il.com>
To:	"Jan Engelhardt" <jengelh@...ozas.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Suggestion: LKM should be able to add system call for itself

On Mon, Jul 7, 2008 at 5:35 AM, Jan Engelhardt <jengelh@...ozas.de> wrote:
>
> On Monday 2008-07-07 07:09, Jinkai Gao wrote:
>
>>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.
>
> And that is good -- I certainly do not want something to step out of
> bounds by accident or intention.
>
>>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).
>
> I do not see what a syscall will buy over a "switch file" in procfs or
> sysfs.
>
>>So The LKM should be able to define its own user interface
>>by adding new system call for itself.
>
> And the point is? Why cannot it use, say, a character device?

Please refer to my reply to Bart.

>>And actually,  it is not hard to
>>implement such kind of dynamic system call table as I thought it
>>through.
>
> It is. You do not know what number your syscall will get. And if
> you knew, it might just happen that this specific number is taken
> in the next iteration in the Linux kernel.

You are right. So we can use ascii name instead of number to identify
the system call. Kernel will match the function with the name.To have
backward compatibility, number should still be supported. Yes, it is
not as easy as I thought, but as long as it is valuable and doable, we
should have a try, right?

>>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,
>
> Letting the user know does not help you. Binaries are already compiled
> with the syscall numbers in, and recompiling is not feasible even
> if you could.

I was wrong, number is useless here.

> It is pointless.
>



-- 
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/