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]
Message-ID: <647618.57006.qm@web55614.mail.re4.yahoo.com>
Date:	Sun, 7 Jan 2007 01:07:41 -0800 (PST)
From:	Amit Choudhary <amit2030@...oo.com>
To:	Rene Herman <rene.herman@...il.com>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [DISCUSS] Making system calls more portable.


--- Rene Herman <rene.herman@...il.com> wrote:
>
>If we're limited to Linux kernels, this seems to not be the case. Great care is taken in keeping
>this userspace ABI stable -- new system calls are given new numbers. Old system calls may
>disappear (after a long grace period) but even then I don't believe the number is ever recycled.
>
> If your discussion is not limited to Linux kernels, then sure, but being 
> portable at that (sub-libc) level is asking too much.
> 

I will come to the main issue later but I just wanted to point out that we maintain information at
two separate places - mapping between the name and the number in user space and kernel space.
Shouldn't this duplication be removed.

Now, let's say a vendor has linux_kernel_version_1 that has 300 system calls. The vendor needs to
give some extra functionality to its customers and the way chosen is to implement new system call.
 The new system call number is 301. The customer gets this custom kernel and uses number 301.
Next, he downloads another kernel (newer linux kernel version) on his system that has already
implemented the system call numbered 301. The customer now runs his program. Even if he compiles
it again he has the old header files, so that does not make a difference.

Now his program uses number 301 that refers to some other system call and so, we can see system
crash, or some very wrong behaviour. Making system calls more portable will ensure that atleast
the program gets an indication that something is wrong (error returned from the kernel that this
system call name is not matched). Or, if the vendor is actually successful in pushing its system
call to the mainline kernel, no one needs to worry about it. Everything will run happily.

However, people may say that, implementing custom system calls is not advocated by linux. And I
think it is not advocated precisely because of this reason that they are not portable.

Regards,
Amit



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-
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