Re: Saving %gs and %fs over interrupts and syscalls

[Nicolas Joly <njoly%pasteur.fr@localhost>]

On Thu, Jan 21, 2010 at 10:01:42PM +0000, David Laight wrote:
> Having fixed the i386 'trap during return to user' I looked at the
> amd64 code - I shouldn't have!
[...]
> The NetBSD kernel only ever saves the %fs and %gs segment registers.
> It doesn't save either of the FS.Base or GS.Base registers that might
> need to be set by userspace.  I don't think anything 'normal' in NetBSD
> tries to set these values, but they are probably used by Linux for
> thread specific data - and NetBSD will probably need to do something similar.

Yep.

> It is possible that things like the JVM are trying to use Linux syscalls
> to set these values - the fact that NetBSD fails to save/restore them
> may be relevant to the failure of the JVM in NetBSD amd64.

This really affects all compat linux programs that calls arch_prctl(2).
Which means about 99% of linux binaries ...

> I think it is necessary to save and restore values of %fs, %gs, FS.Base
> and GS.Base on system calls and interrupts.  This is rather problematical
> but restoring FS.Base after %fs while ensuring that if the kernel
> changes the %fs that a process would restore will also modify the saved
> Fs.Base might work!

That's AFAIK the current problem on Intel CPUs. Restoring the %fs
value nukes the FS.Base ... I tested it by nuking all `movw XX,%fs'
along the way (made the nop), and then basic compat linux programs
started working (but this indeed broke compat linux32).

> Alternatively perhaps FS.Base sould only be saved/restored when %fs is zero.
> There may be some info in the Linux kernel or open solaris.

I'll try to experiment some more ...

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.