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:	Wed, 22 Apr 2009 18:12:07 +0400
From:	Igor Zhbanov <izh1979@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Idea: Feature information / extensions dispatcher syscall.

Hello!

System calls is a very convenient way to talk to modules. But when some modules
used locally (e.g. in one organization only) it will be to impractical
to reserve system
call number in linux kernel source for that feature forever. Usually
first free syscall
number is used. But when new system call is introduced in official kernel,
one need to rewrite all modules and libraries, since first free
syscall number is increased.

I suggest to reserve one system call to provide information about
other system calls.
This can help to build system call independent programs.

That informational / dispatcher system call can take some identifier
as argument (e.g. GUID)
and return some information about asked extension (e.g. syscall number
for that extension).

So libraries that use some additional functionality upon first call of
extension function
will ask kernel (via informational syscall), what is the number of
feature's syscall, and will
use it later directly.

Also can be useful to reserve some system call number (e.g. 8) for
such extensions,
so extension modules can use first unused number of this set.

This allow to use system calls in any extension modules without need to reserve
syscall number in kernel source and allow binaries to run correctly on
any kernel
(where that extension feature can have another syscall number).

What do you think?
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ