I've finially got the time to look at the problem of a user modifying the
selectors through the sigreturn() channel.

From what I can tell from the i386 manual, the cpu will check many of
the things that need to be done upon exit from the kernel in the "iret".
The checks are based on the DPL of the CS selector's descriptor. As
long as this is a DPL==3 then a priv level change will occur at the
"iret" in doreti().

If there are selectors (ds, es, fs, gs) containing bad privs they are
changed to a null selector. This will cause any accesses made with them
to generate a GP, which will be caught and reflected as a signal.

There are also a bunch of sanity checks made to the CS and SS. I'm not sure
if the exception will be made in the kernel or user mode if these fail.

What may be the right thing to do in sigreturn() is to check the validity of
CS and SS. The other selectors should be checked by the CPU as long as these
2 are rational for a PL 3 user process.

Does this make sense ? Is this how you read it ? I'll probably make a few
test programs to check these assertions out.





=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 John Brezak                    UUCP:     uunet!apollo.hp!brezak
 Hewlett Packard/Apollo         Internet: brezak@ch.hp.com
 300 Apollo Drive               Phone:    (508) 436-4915
 Chelmsford, Massachusetts      Fax:      (508) 436-5103

------------------------------------------------------------------------------