export of sys_call_table

I see that RH, in their infinite wisdom, have seen fit to remove the export of sys_call_table in 8.0 kernels breaking any loadable modules that wish to implement non-implemented system calls such as LiS's or iBCS implementation of putmsg/getmsg.

sys_call_table is exported in current 2.4 and 2.5 kernels.

Until now, loadable modules have been able to just overwrite the non implemented point in the sys_call_table when they load and putting it back when they unload. There is no mechanism for registering system calls.

What is the kernel.org take on this?

--brian

Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email protected]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

Overwriting syscall table entries is not safe. Its not safe because there is no locking mechanism, and its not safe because of the pentium III errata.

Not actually safely implementable. The right way to do this is a relevant 2.5 question. In general however you shouldnt need to register syscalls because the upper layer interfaces already exist (the LiS stuff is an example otherwise I grant).

Alan

Alan,

Would it be possible to put a secondary call table behind the call gate wrappered in sys_ni_syscall that a module could register against. Is it merely the fact that the call gate table itself must be static? A secondary table and a mechanism to register against the secondary table with kernel locks taken behind the call gate would be trivial, I think.

Does that sound like the best way to go about it?

--brian

Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email protected]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

Why ?
Adding "unknown" syscalls is I doubt EVER a good idea. LiS has *known* and *official* syscalls, they can easily live with a stub like nfsd uses.... few lines of code and it's safe.

Greetings,
Arjan van de Ven

Arjan,

Well, nfsd does something like this:

	struct nfsd_linkage *nfsd_linkage = NULL;

	long
	asmlinkage sys_nfsservctl(int cmd, void *argp, void *resp)
	{
		int ret = -ENOSYS;
		
		lock_kernel();

		if (nfsd_linkage ||
		    (request_module ("nfsd") == 0 && nfsd_linkage))
			ret = nfsd_linkage->do_nfsservctl(cmd, argp, resp);

		unlock_kernel();
		return ret;
	}
	EXPORT_SYMBOL(nfsd_linkage);

I take it that this system call is not in nsfd's main data flow (probably write() and read are()). Taking the big kernel lock is excessive across every putpmsg() and getpmsg() operation and would seriously impact LiS performance on multiple processors. In effect, only one processor would run for LiS. A reader/write lock would be better.

Also, LiS does not require module loading on system call, but (questionably) needs unloading protection -- LiS does not really need to unload once loaded. This turns into something more like:

	static int (*do_putpmsg) (int, void *, void *, int, int) = NULL;
	static int (*do_getpmsg) (int, void *, void *, int, int) = NULL;
	static int (*do_spipe) (int *) = NULL;
	static int (*do_fattach) (int, const char *) = NULL;
	static int (*do_fdetach) (const char *) = NULL;

	static rwlock_t streams_call_lock = RW_LOCK_UNLOCKED;

	static long asmlinkage sys_putpmsg(int fd, void *ctlptr,
					   void *dataptr, int band, int flags)
	{
		int ret = -ENOSYS;
		read_lock(&streams_call_lock);
		if (do_putpmsg)
			ret = do_putpmsg(fd, ctrptr, dataptr, band, flags);
		read_unlock(&streams_call_lock);
		return ret;
	}

	static long asmlinkage sys_getpmsg(int fd, void *ctlptr,
					   void *dataptr, int band, int flags)
	{
		int ret = -ENOSYS;
		read_lock(&streams_call_lock);
		if (do_getpmsg)
			ret = do_getpmsg(fd, ctrptr, dataptr, band, flags);
		read_unlock(&streams_call_lock);
		return ret;
	}

	static long asmlinkage sys_spipe(int *fd)
	{
		int ret = -ENOSYS;
		read_lock(&streams_call_lock);
		if (do_spipe)
			ret = do_spipe(fd);
		read_unlock(&streams_call_lock);
		return ret;
	}

	static long asmlinkage sys_fattach(int fd, const char *path)
	{
		int ret = -ENOSYS;
		read_lock(&streams_call_lock);
		if (do_fattach)
			ret = do_fattach(fd, path);
		read_unlock(&streams_call_lock);
		return ret;
	}

	static long asmlinkage sys_fdetach(const char *path)
	{
		int ret = -ENOSYS;
		read_lock(&streams_call_lock);
		if (do_fdetach)
			ret = do_fdetach(path);
		read_unlock(&streams_call_lock);
		return ret;
	}

	void register_streams_calls(int (*putpmsg) (int, void *, void *, int, int),
				    int (*getpmsg) (int, void *, void *, int, int),
				    int (*spipe) (int *),
				    int (*fattach) (int, const char *),
				    int (*fdetach) (const char *))
	{
		write_lock(&streams_call_lock);
		do_putpmsg = putpmsg;
		do_getpmsg = getpmsg;
		do_spipe = spipe;
		do_fattach = fattach;
		do_fdetach = fdetach;
		write_unlock(&streams_call_lock);
	}
	void unregister_streams_calls(void)
	{
		register_streams_calls(NULL, NULL, NULL, NULL, NULL);
	}

	EXPORT_SYMBOL(register_streams_calls);
	EXPORT_SYMBOL(unregister_streams_calls);

The module (LiS or iBCS) calls register_streams_calls after it loads and calls unregister_streams_calls before it unloads.

But this is repetative and doesn't solve replacement of existing system calls for profilers and such. Having a single secondary call table approch such as:

	struct sys_secondary_call {
		rwlock_t lock;
		long asmlinkage(*call) (void);
	} sys_secondary_call_table[256];

	void *replace_syscall(__u8 nr, void *newcall)
	{
		void *oldcall;
		write_lock(&sys_secondary_call_table[nr].lock);
		oldcall = xchg(&sys_secondary_call_table[nr].call, newcall);
		write_unlock(&sys_secondary_call_table[nr].lock);
		return (oldcall);
	}
	EXPORT_SYMBOL(replace_syscall);

	#define SYSCALL_STUB(num) \
	long asmlinkage sys_call_ # num (void) { \
		int ret = -ENOSYS; \
		read_lock(&sys_secondary_call_table[num].lock); \
		if (sys_secondary_call_table[num].call) { \
			ret = (*sys_secondary_call_table.call) (); \
		read_unlock(&sys_secondary_call_table[num].lock); \
		return (ret); \
	}

	SYSCALL_STUB(__NR_setup);
	SYSCALL_STUB(__NR_exit);
	SYSCALL_STUB(__NR_fork);
		.
		.
		.
	       etc.

With entry.S looking like:

	.data
	ENTRY(sys_call_table)
		.long SYMBOL_NAME(sys_call_0)
		.long SYMBOL_NAME(sys_call_1)
				.
				.
				.
		.long SYMBOL_NAME(sys_call_255)

Then any module could both replace or implement otherwise non-implemented system calls. It just seems that the general purpose approach could work better for most things (even nfsd).

--brian

Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email protected]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

The kernel has such locks too, no big deal

not to bad...

ehm sys_spipe doesn't exist, neither do all but 2 of the others you showed.

iBCS is dead. It's called linux-abi nowadays.....

Profilers don't actually NEED this.... OProfile is fixed for this for example in the 2.5 branch.

Taking over "random" unimplemented system calls really sounds bad..... I mean, for the next minor release of the kernel Linus can assign that number to something official and different......

Greetings,
Arjan van de Ven

Arjan,

spipe, fattach, fdetach can sometimes be faked with ioctl(). Perhaps we can reserve these while we're at it.

AFAIK it lives on as socksys under sparc architecture. See for example solaris_putmsg and solaris_getmsg in 2.4.18 arch/sparc64/solaris/systbl.S and arch/sparc64/solaris/timod.c

Fair enough. I only really care about the STREAMS system calls...

--brian

Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email protected]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

Which ends up looking suspiciously like an overcomplicated way to implement "ioctl", and wrap the message stuff up as ioctls. Getting getmsg/putmsg loadable interfaces right looks a good thing for 2.5 though

...

Hm, IIRC bproc stuff (Beowulf support) also relies on this ability. Or at least "kmonte" trick to load and switch to a new kernel.

Michal

The last kmonte that I worked with would preserve, then overwrite, sys_call_table[__NT_reboot] with a pointer to it's version of reboot() when the kmonte module was loaded.

If asked to unload, the original version of reboot() was restored prior to being unloaded.

Andy

On Fri, 2002-10-04 at 02:32, Andy Pfiffer wrote:
(Beowulf support) also relies on this ability.

this actually gets very messy if you have ANOTHER module that tries to do the same at the same time....

I wonder why kmonte can't just use a reboot notifier.... existing infrastructure already ;(

Because it doesn't hook sys_reboot to get notified about reboots. It hooks sys_reboot to add new calls, it could have been a new system call, but what monte does is slightly related to a reboot.

I have myself added a feature to monte where it was essential to hook the sys_reboot call and do something else when a reboot was requested. Maybe I could have used a reboot notifier.

What really bothers me about monte is:
1) Doesn't work on SMP
2) Doesn't seem to be maintened (does it even work on 2.5)?
3) Is not completely stable
4) Only available as a module, cannot be compiled in kernel.
5) I couldn't get my additional feature working with the latest version of monte.

Perhaps there is some better alternative which I don't know?

Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:[email protected]
or mailto:[email protected]

kexec...
It was an inch from being accepted into 2.5 last time I looked.

Eric

From: Alan Cox <[email protected]>
Date: 03 Oct 2002 23:02:40 +0100

Overwriting syscall table entries is not safe. Its not safe because there is no locking mechanism, and its not safe because of the pentium III errata.

It is also non-portable, such syscall overwriting requires knowledge of the layout of the table on every architecture. On some platforms it is a list of pointers + argument count, on some 64-bit platforms it is a list of 32-bit truncated pointers to save space.

There is simply no portable way to make changes to the system call table, so exporting it makes zero sense.

David,

How many other architecture-specific exported symbols are there?

It appears to me that many of the system calls themselves are architecture-specific, particularly so where 64-bit machines are involved. Is that a reason to not make them accessible?

--brian

Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email protected]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

I think, upon reading this entire conversation so far, that the functionality is just about useless (ie, any programs that have taken advantage of sys_call_table have been patched to not necessarily do so) .. but if it were necessary, there could quite probably relatively easily be a "addto_syscall_table" function or some such. hmm.

It is not safe.

I do not think it matters what our opinion is. Red Hat is free to do whatever they wish. They certainly give enough back to kernel development that they are able to. In this case, however, I see good reason for it - overwriting syscall table entries has a number of sticky points...

Robert Love

I'm not sure if kernel.org has an opinion. ;)

But, Linus appears to be open to the notion, since it's now in his BK tree:

http://linus.bkbits.net:8080/linux-2.5/[email protected]?nav=index.html|ChangeSet@-1d

-pat

And if it does, it looks like as-of cset 1.692 2.5 no longer exports the table either.

Robert Love

As of 2.5.40bk it is now also not exported, which is a good thing.

That's a racy, easily breakable thing to do. Don't do it.

It is a good thing that the sys_call_table is now not exported.

thanks,

greg k-h

Hmm, I guess this means oprofile has no chance of working on Red Hat's kernels ? Bummer.

| Dave Jones.        http://www.codemonkey.org.uk

Newer oprofile does not need the exported syscall table.

I believe Red Hat 8.0 even ships with oprofile :)

Robert Love

Right. Assuming Linus is interested in merging the patch. I've yet to see any kind of comment from him.

Sort of. They've broken IA64 oprofile, and they seem not to care.

I'm pretty disgusted Arjan sent this patch without even the courtesy of a Cc: to lkml (apologies if I just missed it).

regards
john

"Me and my friends are so smart, we invented this new kind of art:
 Post-modernist throwing darts"
	- the Moldy Peaches

More or less off-topic, but could the persons who'd invented that name stand up and tell what the hell were they thinking about?

Al, who can't help misreading that name 10 times out of 10. The worst thing being, coprofile sounds like a very apt description of way too many files in drivers/*...

Guilty. You would prefer "Turdometer" ?

heh :)

It's not my fault you find yourself adding an extra 'c'

The [a-z]profile namespace is pretty crowded ... as it is, I share name with some Windows "tool"

regards
john

"Me and my friends are so smart, we invented this new kind of art:
 Post-modernist throwing darts"
	- the Moldy Peaches

They've also broken syscalltrack, and I'll be surprised if they care.

Would someone please explain to me why a mechanism which *is* safe under certain circumstances[1] is removed *without any suitable alternative for modules*[2], just because it's "ugly"? We've had this discussion before, numerous times. Ref:
http://marc.theaimsgroup.com/?l=linux-kernel&m=101820103913072&w=2

I agree that it should not be done. I maintain that sometimes, if you want to keep your code as a module only (because forcing users to recompile their kernel is not a viable solution) it can be done safely if you observe certain precautions and your architecture supports it[3]. So why remove it?

[1]
http://marc.theaimsgroup.com/?l=kernelnewbies&m=102267164910800&w=2,
http://marc.theaimsgroup.com/?l=linux-kernel&m=101821127019203&w=2

[2] Can the LSM hooks be used for notification and modification on every system call's entry and exit?

[3] I'd like to know if I'm wrong, of course.

Muli Ben-Yehuda					http://www.mulix.org/	
[email protected]:~$ sctrace strace /bin/foo 	http://syscalltrack.sf.net/
Quis custodes ipsos custodiet?

You didn't read my post to that same thread did you:

	http://marc.theaimsgroup.com/?l=kernelnewbies&m=102130770415962

And for the most part, the people on kernelnewbies have given up on trying to explain to new people why this does not work. I know I sure have :)

No. See the LSM mailing list archives for why we did not decide to do this. (hint, you don't really achieve what you want to by doing this.)

If you _really_ want to hook things like this, look at LTT or dprobes. They should work just fine for you.

thanks,

greg k-h

I did, and considered using LSM, but decided not to since, as you mention below, it doesn't give me the capabilities I need.

As I've written, I maintain that it does work on *some* archs (atomic pointer updates are required) and with certain precautions (no module unload).

Well, since I want to hook every system call, I get exactly what I want ;-)

I'm not doing access policies or security. I'm doing "who is deleting my file?" and "who is calling settimeoday on my router once in a blue moon.", and even "if process foo calls getpid(), tell it's actually process bar".

Neither is in the core kernel (AFAIK), and I'm not sure how useful they are for a module only solution. I'll take a look, though.

Thanks,
Muli.

Muli Ben-Yehuda					http://www.mulix.org/	
[email protected]:~$ sctrace strace /bin/foo 	http://syscalltrack.sf.net/
Quis custodes ipsos custodiet?

Hrmmm, HEAD CVS from a few minutes ago still does. John's work on getting things done correctly for 2.6 doesn't change the fact that it's buggered on Red Hat's 2.4 kernel. Or does it ?

Interesting. Maybe I'll download a copy sometime 8)

Dave

| Dave Jones.        http://www.codemonkey.org.uk

Right, it's buggered on Red Hat's kernel. Not really a problem; they have a bugzilla and it's not big deal to redirect users there.

Actually what I'd really like is for the Red Hat people to backport the patch. It shouldn't be too hard.

This doesn't change the situation for users on other 2.4 kernels, of course. But sys_call_table is still there for them.

regards
john

"Me and my friends are so smart, we invented this new kind of art:
 Post-modernist throwing darts"
	- the Moldy Peaches

John,

Been there, done that:

	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74902

Interested parties are welcome to join the fray.

--brian

Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email protected]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

Bugzilla is not a place for "fray". If you want to get flamed, I can oblige without screwing Bugzilla.

Also, if you are a provider of a binary-only crapware which wants to override syscalls, there's one very important document for you to see: it's called Fig.1.

GPLed code has no problem linking with sys_call_table.

-- Pete

Pete,

The code in question (LiS) is LGPL and open source. The iBCS packge is GPL and open source.

You do know that there *is* open source code which is not contained in the Linux kernel ;)

So, in this case, GPL and LGPL modules do have a problem linking with the sys_call_table (on RH 8.0 and I suppose some development kernels only), because the symbol is no longer exported and no registration procedure was provided for registering otherwise non-implemented system calls (in particular the UNIX98 and iBCS/ABI standard putmsg/getmsg calls).

And what about AFS? I see that it uses a sys_ni_syscall slot as well...

In fact all these components are opensource.

--brian

Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email protected]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

I think the fact that downloading the kernel source, applying a patch, fixing the conflicts, and rebooting, can be a significant PITA for admin/developers has completely passed them by.

Look, why don't you submit the module-loading patch for LiS already ?

Btw, anybody know what the BKL is actually protecting against in sys_nfsservctl ?

I thought it got fixed last time round.

regards
john

"Me and my friends are so smart, we invented this new kind of art:
 Post-modernist throwing darts"
	- the Moldy Peaches

John,

Start of one earlier on thread without the BKL.

--brian

Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email protected]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

rmmod while executing an nfs call

I looked at the code scene a little here, and I do not think there's anything that needs the syscall table.

The oprofile author seems to have things fixed already, though the change did not filter down yet. He's also thin skinned and was fuming a little, but I expect technical merit to take the upper hand in his clueful head. I remember being seriously rattled by DaveM in similar circumstances, and coming out just fine.

LiS is crap and has to die, so it's not a problem. We actually had a *very* big customer who used it, got a relatively decent performance too (as much as could be expected from, ahem, the framework :-), but it kept crashing all the time. Took a little work to move them off LiS, but it was worth it.

iBCS is interesting for vendors, which I think, are cool with shipping a patch. That's something SCO will happily sell to you if you want to run old binaries casually. A standalone person who risks running complicated UNIX binaries and debugs when they fail can do the patch too, there's no chilling effect.

This leaves syscalltrack, which is pretty interesting in general, but I think Mulix suffers from CVS mentality a little here. He should aim at getting the hooking mechanism into the kernel. I do not think his attempts to act remora and make it transparent are safe. Anyway, it's a code which needs to mature and sort it out with other hooking mechanisms, we already have dozens of them. Let the Darwinean process to work here a little, then we'll see.

Dhowell's kafs will take care of it. It should not need to overwrite syscalls anyway.

-- Pete

Simple I find it a little poor form to change the kernel API significantly, without taking the courtesy to notify people. I do not classify this as "thin-skinned".

It's no big deal and is entirely irrelevant to the technical issues involved.

I believe I shall survive ;)

regards
john

"Me and my friends are so smart, we invented this new kind of art:
 Post-modernist throwing darts"
	- the Moldy Peaches

There is no such thing as iBCS for 2.4+. iBCS/Linux-ABI are for foreign personalities only anyway and don't need to touch sys_call_table.

Christoph,

iBCS is right there in arch/sparc64/solaris/socksys.c, timod.c, systbl.S

--brian

No that's not iBCS. Even if some code is derivaed it's ceratainly something different.

Christoph,

If you consider 99% some...

--brian

Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email protected]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

Please try to actually read the code instead of spreading fud.

*plonk*