Re: [uml-devel] lcall interface hunnypot issue

[Jeff D. <jd...@ka...>]

ab...@ma... said:
> ok, so if im not mistaken lcall's are done through callgates yes?,
> these call gate descriptors are located in the process'es local
> descriptor table yes?

Maybe, I'm not that familiar with the grubby details of the x86 architecture.

> ...well with the use of my favorite undocumented
> linux syscall (mostly undocumented anyways), modify_ldt(), we should
> be able to remove these descriptors from our LDT yes?

Maybe, but I want to avoid using modify_ldt in UML.  If UML uses it, then
there is some chance that it will collide with a process that's also using
it, and the code to make sure that doesn't happen isn't all that pleasant.
It would mean keeping track of which LDTs are valid in UML kernel space
and which are valid in UML user space, and they would have to be switched,
which would make the kernel<->user transition more expensive than it is now.

> ...if we replace
> them with one that has the segment not present bit set, then should it
> not generate a segment not present exception whenever the annoying
> user tries to call with that selector?...im not sure what signal a
> process will get sent when it when that happens (probably just a
> sigsegv or sigbus or something), 

You'll get a SIGSEGV.

> but if you really wanted to go all
> out you could even use do some trickery at the point it got that
> signal to deturmine where in the code the signal came from (checking
> info on that processes stack i presume

All that stuff, including the processor's notion of what the error was
is put on the stack.

				Jeff