Re: komd issues - was [Re: [openMosix-general] openmosix 2.4.26 in 2.4.31?]

On Thu, 2006-09-21 at 20:33 +0000, Vincent Hanquez  wrote:
> On Thu, Sep 21, 2006 at 01:27:05PM -0600, Matt Dew wrote:
> > From what I understand so far:
> > One of LD_ASSUME_KERNEL's functions is to tell glibc how to handle
> > system calls.  In linux 2.4, system calls use int 0x80 so we could
> > modify arch/i386/kernel/entry.S to check for migrated processes and
then
> > handle the system call differently if need be. 
> 
> It's doing the same on 2.6.

Yes, which is where the problem appears to lie.  2.4 only called int
0x80, whereas 2.6 has options we don't account for.

> 
> > As of 2.6, system calls can be called other ways as well such as
jumping
> > straight to the syscall handler address.  Trapping 0x80 won't work
all
> > the time. We have to change the interrupt table, rather than trying
to
> > conditionally use our own.
> 
> We *never* trapped interrupt 0x80. neither do we need to change the
> interrupt table, which we never did anyway.

In entry.S we check the om_dflags to see if DREMOTE is set. If it is we
run remote_sys_call_table, otherwise continue normally with
sys_call_table.  I consider that trapping.

> > Apparently 2.6.18 also changes the way it handles system calls.
> 
> No, it doesn't change the way it handle system calls, it's just
> randomizing where the VDSO is. which, the ABI is perfectly entitled
to.
> So far we relied on the fact that the VDSO was constant across
kernels,
> which is not going to be the case anymore...

Yes, it changes the way it handles the syscall but not the syscall
itself.
>From kerneltrap: "executables ask for the address to call and jump
there
to make a syscall, in 2.6.18 it was changed to have a non-constant
location"  

> 
> There's 2 solutions:
> - the easy one consist in just desactivating the randomization, which
>   is not useful to anything anyway. It seems the security protection
>   that it gives are absolutely extremely tiny and just security by
>   obscurity.

But that doesn't fix our current problem.  the segfaults occur on every
version, the vdso randomization has nothing to do with the current
segfault problem.

I'm also not in favor of disabling anything in the kernel to make our
stuff work. We need to work with the kernel not the other way around.
Otherwise that starts a list of things people need to be wary of when
using openmosix.


> - the hard one could be done in multiple way. not totally sure, since
I
>   didn't look the code, but gs segment fixup could probably solve the
>   problem. it doesn't seems to be worst it at all.

How would do we do this?

> 

Matt


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV