> Well, while I agree with the general sentiment, this is technically not
> quite right. In i386 protected mode, you cannot jump directly to code with
> a different privilege level (it'd cause a GPF/SIGSEGV to try), it must be
> done through a "gate" (typically an interrupt). Passing through such a
> privilege-transition gate also implies switching to a similarly-privileged
> stack (before the return address is pushed), so you cannot push your own
> return address onto the kernel's privileged stack. And you probably can't
> even get the address of the kernel interrupt handler (the IDT can be
> protected from being read). This doesn't make Wine any more secure though,
> of course...
I wasn't talking about jumping directly into the kernel
I was referring to the trusted/untrusted DLL part.
the int 80h instruction was in trusted code. I was trying to show that
"trusting" DLLs (or code pages) to allow/disallow syscalls could be
rather easily circumvented and was offering no protection ("trusted" int
80h insn in trusted code could be used easily by untrusted code)
A+
_______________________________________________
wine-users mailing list
wine-users@winehq.com
http://www.winehq.com/mailman/listinfo/wine-users
