kernel modules never have been allowed to modify system calls, so they only can
call system calls this way. (yes I know some rootkits did it anyway)
And for calling system calls: all system calls are exported functions to
modules, so this cannot be a problem..

That is not true. They are allowed to - in the current kernel.org
tree as well as in previous (7.x) RH kernel lines.
This breaks LiS, for example, which exports STREAMS msging calls. 
See http://www.gcom.com/home/linux/lis/index.html

So, this is a deviation from stock kernel source, both present and 
future.  Red Hat should fix this with a patch release immediately.

Unless this is fixed, we have little choice but to announce to our users that
Red Hat 8.0 has broken kernels and will not support LiS STREAMS.  (All other
distributions will support LiS STREAMS except RedHat 8.0.)  We will have little
choice by to exclude Red Hat 8.0 and only Red Had 8.0 from our supported
distributions.

Please respond immediately as I may be releasing the information concerning Red
Hat's lack of support for LiS STREAMS to our entire user base shortly.

Oter vendors like Ulticom use LiS in there applications for Telco industry TEMs 
and NEPS. Is RH AS not going to support that industry anymore? Most of 
the "portable" Telco apps on UNIX could port to Linux with LiS, without LiS, 
the impact to the industry would be tragic. Oh well, I guess there is always 
United Linux!!!!

The following two system calls, from line 195 of asm-i386/unistd.h in kernel 
version 2.5.38, are implemented by LiS.  LiS is a loadable module.

#define __NR_getpmsg            188
#define __NR_putpmsg            189

So it is not correct to say that loadable modules do not implement system 
calls.  LiS has been implementing these calls for years.

Also, from line 521 of kernel/ksyms.c in 2.5.38 is the following:

EXPORT_SYMBOL(sys_call_table);

Red Hat needs to bring its kernel DKI into compliance with the standard 
kernels.  The existence of this symbol in the 2.5 source shows that the kernel 
developers intend to keep this symbol visible to modules.

If you want to remove the symbol, then cook up a patch for a registration 
routine and get the kernel developers to put it into the stock kernel.  LiS 
will gladly use it.

David Grothe
LiS developer

This also makes it impossible to use the XTI library with the RH 8.0 kernel,
since this depends on LiS.
XTI is part of XNS, and thus required for Unix98 certification.
With this symbol removed, it will be impossible to get RH 8.0 anywhere near
Unix98 functionality, since several dozen Unix98-required library calls will
not work.

Also, while removing this symbol may may it harder for a rootkit to alter
syscalls, this is no real security enhancement: It is still possible to
find the address of the syscall table. I am not going to tell you how in
public - please ask your kernel security experts about this.
But if you insist on not publishing this symbol, one of the kernel modules
that no longer work might eventually include code to find the call table. If
such a module is open source, the rootkit hackers have been served a workaround
for your "security enhancement".

Best Regards,

Ole Husgaard.

Those two symbols (putmsg and getmsg) are also required by the ABI suite for
iBCS which is a loadable module.  Linux loses its iBCS compatabiility if the
system call table can not be located and writable.

It is trivial for a rootkit to find the system call table.  The exported
sys_close symbol can be used to scan lower memory for the table and index back 6
longs, or, it is possible to scan for the correct pattern of identical
sys_ni_syscall pointers, or even scan for the correct pattern of pointer
offsets.  If security was the purpose, bear in mind that a system which presumes
the stupidity of the crook is never secure--particularly when source code is
available.

Face it: it was a bad idea.

Please re-export the symbol so that legitimate uses of the system call table do
not have to go to these architecture-dependent extents to locate the call table.

http://gsyc.escet.urjc.es/mailarchive/linux-streams/2002/000482.html

how cute

I was willing to work with the LiS people to actually fix LiS to do the right
thing (and to explain why the export is removed) but this is a great way to make
me loose interest.

We have presented a number of reasons for why the removal of sys_call_table is 
both a bad idea and ineffective to its stated purpose.

So why is it that the best that you can come up with is an insult?

If you have an approved method for LiS to hook its system calls while remaining 
a loadable driver, why don't you share the information with us?

I also want to register my objection, and I hope to speak for the entire LiS 
community, to the absolute arrogance on the part of Red Hat to mark the status 
of this report as CLOSED while active dialog is going on.

Just who do you think you are that you can unilaterally make changes to 
standard kernel source in such a manner as to render the kernel non-compliant 
with UNIX98 and break any number of existing drivers?  Whatever happened to the 
concept of the Bazaar?  This is more like the Bizarre.  Or maybe Kafka.

I understand that this may not be the most interesting topic, and statements 
like "write a flame comment" don't exactly encourage collaboration, but the 
reason so many people are upset is that "we" (LiS, telco developers, and 
others) want our products to run on a stock RedHat Linux distribution, as well 
as other distributions.  We DO NOT want to exclude the stock RedHat 
distribution from our future releases compatibility lists.  I appologize for 
the "flame bugzilla.redhat.com" comment posted and request that at a minimum, 
someone from RedHat please explain the reasoning behind these changes and if 
possible, work with LiS and other developers so that "we" can continue to 
maintain stock RedHat Linux compatibility.  "We" all want this to work, each 
for our own reasons.

I will keep the Bug state as "Closed Won't fix", but make a final request that 
either within this bug's comments or on RedHat's developer network
(http://redhat.com/devnet/), someone within RedHat post more information, 
create a developer discussion forum and work with LiS and any other project 
that runs into these problems introduced by the kernel symbols that have been 
removed/omitted in a stock redhat kernel.

Thank You for your time,
Shanan Levin

Shanan: I am glad one of you is prepared to apologise for the
appalling childishness displayed by the link Arjan posted.

In your particular circumstance, probably a better solution
is to provide a simple permanent -ENOSYS hook patch to the mainline
kernel. This allows you to provide system calls correctly, without
the horrible ugliness and danger of sys_call_table hacks.

There are already spaces reserved in entry.S for your system calls.

The canonical example: sys_nfsservctl

Arjan: I suggest simply ignoring vassilii and others
"demanding" things from Red Hat in favour
of people who are prepared to act in an adult manner.

moz:

the "mainline" stable kernel exports sys_call_table, so no patch is required
to the official 2.4 kernels

nfsd module can be unloaded with clients present, LiS does not need to
be unloaded so sys_nfsservc is not completely applicable.

There is a second problem with the example of nfsservctl.  As far as I can tell,
this method won't work for LiS.

sys_nfsservctl gets itself into the kernel by having the user configure it in
with menuconfig.  If it isn't desired, sys_nfsservctl is #defined to be
sys_ni_syscall.  NFS doesn't have to put itself into the table defined in
entry.S because it is already there at compile time.

The LiS entry points are not already there at compile time, and I'm under the
impression that they never will be in the official kernel or in any kernels
provided by a vendor.  The LiS entry points are already set to sys_ni_syscall to
return -ENOSYS.

This brings us back to the original problem.  LiS needs to put itself into an
already compiled and running kernel, and the only way to do that is to modify
sys_call_table when it is loaded.

If there is another officially approved way to do this without recompiling the
kernel, then somebody please let us know.

Jared

Arjan: I was out yesterday - so let me apologize today 
for any hurt feelings. The message linked to was addressed
to a community of LiS people, and was actually a followup
on a thread. (The thread's idea was to have everybody
whose plans are hurt by this kernel deviation to write
his reasons here so that RH knows. The ones it was addressed
to - i.e. the people from the LiS mail list - took it as
intended by presenting technical reasons against the move.)
I don't mind you guys ignoring me personally, but I don't
see how this has anything to do with complete validity (IMHO)
of the others' technical issues here. Ignore my comments
if you wish, but do answer theirs - please.

I also have an interest in seeing this missing symbols fixed in Red Hat 8. We 
develope the Communications Server for Linux here in IBM and have already got 
support for Red Hat 7.2, 7.3 stock and SuSE 8. We do not want to make a 
statement that the Red Hat 8 is not supported. Will this problem also be 
expected in the next Red Hat Advanced server release? We use the LiS Streams 
code as well and we already are having alot of users migrating to Linux. This 
type of problem will not be good Press for any involved. Please keep us 
informed of where to find more discussions on this matter. 
  Thank you.

The syscall table is no longer visible in the 2.5 kernel either, since there is
no way to safely modify it on an SMP system.

If people want to support the 2.6 kernel, they will have to modify their
software in the exact same way they need to modify it in order to support recent
Red Hat systems based on the 2.4 kernel.

Asking Red Hat to export the syscall table again for 2.4 will not buy you
anything except some extra time, once 2.6 comes out the changes need to be made
anyway.

will the IBM dude that keeps adding IBM internal things to this bug please stop
doing so.

grep sys_call_table /boot/System.map

thank you for reminding us to remove this as well.

grep sys_call_table /proc/ksyms

---- Additional Comments From jefsmith.com  2005-07-11 15:00 EDT -------
Yes, please close this bug.