On 08/22/2011 05:03 PM, Al Viro wrote:
> On Mon, Aug 22, 2011 at 04:27:51PM -0700, Linus Torvalds wrote:
>
>> So I think the "let's fix the vdso case for sysenter" + "let's remove
>> the 32-bit syscall vdso" is the right solution. If somebody has
>> hardcoded syscall instructions, or generates them dynamically with
>> some JIT, that's their problem. We'll continue to support it as well
>> as we ever have (read: "almost nobody will ever notice").
>
> Umm... Maybe, but I really wonder if it would be better to do this:
> * check if %ecx is the right one for vdso32 entry. If it isn't,
> act as we act now (and possibly warn). If it is, increment it by 4.
> * slap 0x90, 0x90, 0xcd, 0x80 right after that syscall insn -
> i.e. nop/nop/int 0x80. Followed by what we currently do there.
>
> Those who do syscall insn in 32bit mode outside of vdso will get
> what they currently get. __kernel_vsyscall() will keep working and do
> that without restart problems. And the price is comparison + branch not
> taken + addition for that path...
Checking for SYSCALL in the vdso is cheap... the only problem is if
someone thinks that they can copy it out of the vdso and run it, having
special-cased SYSENTER already, but not SYSCALL. The recent experience
shows that that is apparently a very real possibility.
Without a SYSCALL in the vdso, anything that examines the vdso will end
up using int $0x80 and we don't have an issue.
Again, waiting for Borislav & co to tell us how much the SYSCALL
instruction actually buys us.
-hpa
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
