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] [day] [month] [year] [list]

Date:	Mon, 7 Jul 2008 19:33:09 +0300
From:	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>
To:	Josh Boyer <jwboyer@...il.com>
Cc:	Jinkai Gao <mickeygjk@...il.com>,
	Jan Engelhardt <jengelh@...ozas.de>,
	linux-kernel@...r.kernel.org
Subject: Re: Suggestion: LKM should be able to add system call for itself

On Mon, 07 Jul 2008 10:16:51 -0400
Josh Boyer <jwboyer@...il.com> wrote:

> > 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?
> 
> So you have to search a list of strings using strcmp to determine what
> syscall is being called?  That would be horrible for performance.
> 
> josh
> 

Actually it isn't that bad if you do it like dlsym()/dlopen() do it in
userspace. That is, have the system linker fill in dynamic syscalls,
possibly in a separate ELF section. This way you could version syscalls.

Furthermore, it may make sense to implement all syscalls through glibc,
so that the burden of maintaining obsolete/modified syscalls does not
fall onto the kernel. This already happens for most syscalls, but the
rest (mostly those Linux-specific) still rely on syscall numbers
defined as macros.

But that still will _not_ solve the problem, because:
- there are users which will only use older libc versions
- there are statically linked executables
- the modified/new syscall might not provide the same behavior, even
when used through a compatibility (glibc) wrapper

IOW, this problem can be reduced to any other instance where protocols
or APIs get changed. This usually isn't a problem, but the kernel can't
afford bloat to maintain compatibility.

I hope this makes the issue more clear.

	Cheers,
	Eduard
--
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/