Message-ID: <3FF602C9.4080100@conet.cz>
Date: Sat, 03 Jan 2004 00:46:17 +0100
From: Libor Vanek <libor@conet.cz>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030
MIME-Version: 1.0
To: Anton Blanchard <anton@samba.org>
CC: linux-kernel@vger.kernel.org
Subject: Re: Syscall table AKA hijacking syscalls
References: <3FF56B1C.1040308@conet.cz> <20040102233542.GW28023@krispykreme>
In-Reply-To: <20040102233542.GW28023@krispykreme>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1114
Lines: 28

>>I'm writing some project which needs to hijack some syscalls in VFS 
>>layer. AFAIK in 2.6 is this "not-wanted" solution (even that there are 
>>some very nasty ways of doing it - see 
>>http://mail.nl.linux.org/kernelnewbies/2002-12/msg00266.html )
> 
> 
> And it will fail miserably on many non x86 architectures for
> various reasons:
> 
> 1. ppc64 and ia64 use function descriptors
> 2. sparc64 uses a 32bit call out table
> 
> In short its not only an awful hack, its horribly non portable :)

But in short you always get some syscall from userspace and have some table with function vectors assigned to each syscall, don't you?

So you can have something like "append_this_function_before_syscall_sys_open" and "append_this_function_after_syscall_sys_open" which would be platform independent but will have platform dependent implementation.


-- 

Libor Vanek

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/