SYSENTER/SYSEXIT_vs._SYSCALL/SYSRET
|
From: nmm1 on 18 Jan 2010 16:52 In article <jMGdnQWEBcU_TsnWnZ2dnUVZ_ridnZ2d(a)supernews.com>, Gavin Scott <gavin(a)allegro.com> wrote: >"Andy \"Krazy\" Glew" <ag-news(a)patten-glew.net> wrote: >> System calls are really just function calls. With security. They have >> to switch stacks, etc. > >Well, except when they don't. I know of one significant, successful OS >that really didn't have a kernel stack at all, and executed pretty much >everything except hardware interrupt context on top of the user's own >stack. The main thing that you cannot do with only one stack is to handle the stack overflow exception properly. I believe that the main reason that such practices went out of fashion was the fashion for making the stack pointer an ordinary register. It's clearly not easy to use that for kernel code, without risking security. Regards, Nick Maclaren.
From: Del Cecchi on 18 Jan 2010 17:00 "Noob" <root(a)127.0.0.1> wrote in message news:hj1pf6$n14$1(a)speranza.aioe.org... > Terje Mathisen wrote: > >> Anton Ertl wrote: >> >>> Andy Glew wrote: >>> >>>> I still think that both Intel and AMD missed a big opportunity, >>>> to make >>>> system calls truly >>>> as fast as function calls. Chicken and egg. >>>> Nobody wants to make the investment in hardware without a proven >>>> software benefit, >>>> but existing software is optimized to avoid expensive system call >>>> privilege level changes. >>> >>> But given that system calls have to do much more sanity checking >>> on >>> their arguments, and there is the common prelude that you >>> mentioned >>> (what is it for?), I don't see system calls ever becoming as fast >>> as >>> function calls, even with fast system call and system return >>> instructions. >> >> _Some_ system calls don't need that checking code! >> >> I.e. using a very fast syscall(), you can return an OS timestamp >> within >> a few nanoseconds, totally obviating the need for application code >> to >> develop their own timers, based on RDTSC() (single-core/single-cpu >> systems only), ACPI timers or whatever else is available. >> >> Even if this is only possible for system calls that deliver very >> simple >> result, and where the checking code is negligible, this is till an >> important subset. >> >> The best solution today is to take away all attempts on security >> and >> move all those calls into a user-level library, right? > > What about Linux VDSO / vsyscalls ? > > http://www.x86-64.org/pipermail/patches/2006-November/003498.html > http://juliusdavies.ca/posix_clocks/clock_realtime_linux_faq.html > > Regards. An interesting alternative to study would be the IBM S/38, AS400, i-series family. As I understand it most work was done by functions or commands that were imbedded in the OS. Unfortunately I have now exhausted my knowledge of said operating system. It just seemed that since this system came from a totally different heritage than x86 or linux or any of the rest that it might be informative. I don't know if any of the relevant stuff is publicly available however. I might take a browse through the ibm publications and see. It used to be pretty well guarded.
From: Gavin Scott on 18 Jan 2010 18:01 nmm1(a)cam.ac.uk wrote: > Gavin Scott <gavin(a)allegro.com> wrote: > >Well, except when they don't. I know of one significant, successful OS > >that really didn't have a kernel stack at all, and executed pretty much > >everything except hardware interrupt context on top of the user's own > >stack. > The main thing that you cannot do with only one stack is to handle > the stack overflow exception properly. I believe MPE ensured that there would be pages at the current end of the stack that would be writable only by privileged code, so the OS knew that even in the event of a user stack-overflow fault there would still be "enough" space for the OS to run. There were probably a few special cases of course. > I believe that the main > reason that such practices went out of fashion was the fashion for > making the stack pointer an ordinary register. It's clearly not > easy to use that for kernel code, without risking security. Yes, and PA-RISC had some requirements like 64-bit alignment for 64-bit loads/stores so a function that left the SP unaligned would be a surprise for a subsequent one that tried to spill FP regs to the stack. But the compilers knew what the requirements were and (most) people didn't write their own compilers or assembly code. The OS protected itself by catching traps resulting from this sort of thing before getting too far into privilegd code, but I suspect there was a lot of interesting behavior one could get by pointing SP off to somewhere interesting and then making a system call. G.
From: nmm1 on 18 Jan 2010 18:26 In article <6audnWL7e76odcnWnZ2dnUVZ_hmdnZ2d(a)supernews.com>, Gavin Scott <gavin(a)allegro.com> wrote: > >> >Well, except when they don't. I know of one significant, successful OS >> >that really didn't have a kernel stack at all, and executed pretty much >> >everything except hardware interrupt context on top of the user's own >> >stack. > >> The main thing that you cannot do with only one stack is to handle >> the stack overflow exception properly. > >I believe MPE ensured that there would be pages at the current end >of the stack that would be writable only by privileged code, so the >OS knew that even in the event of a user stack-overflow fault there >would still be "enough" space for the OS to run. There were probably >a few special cases of course. Yes, but by "properly", I mean giving the application a chance to diagnose the failure and clean up, by executing a trap handler. It's not hard to do. >> I believe that the main >> reason that such practices went out of fashion was the fashion for >> making the stack pointer an ordinary register. It's clearly not >> easy to use that for kernel code, without risking security. > >Yes, and PA-RISC had some requirements like 64-bit alignment for >64-bit loads/stores so a function that left the SP unaligned would >be a surprise for a subsequent one that tried to spill FP regs to >the stack. But the compilers knew what the requirements were and >(most) people didn't write their own compilers or assembly code. That's not the problem for security. Regards, Nick Maclaren.
From: "Andy "Krazy" Glew" on 18 Jan 2010 21:44
Del Cecchi wrote: > "Noob" <root(a)127.0.0.1> wrote in message > news:hj1pf6$n14$1(a)speranza.aioe.org... >> Terje Mathisen wrote: >> >>> Anton Ertl wrote: >>> >>>> Andy Glew wrote: >>>> >>>>> I still think that both Intel and AMD missed a big opportunity, >>>>> to make system calls truly as fast as function calls. > An interesting alternative to study would be the IBM S/38, AS400, > i-series family. As I understand it most work was done by functions > or commands that were imbedded in the OS. Unfortunately I have now > exhausted my knowledge of said operating system. > > It just seemed that since this system came from a totally different > heritage than x86 or linux or any of the rest that it might be > informative. I don't know if any of the relevant stuff is publicly > available however. I might take a browse through the ibm > publications and see. It used to be pretty well guarded. I agree with Del: the IBM S/38, AS400, i-Series family is very interesting. It is the only really successful capability machine. With proper capabilities. You can only execute code that you have been granted a capability / secure pointer to, on data that you have a capability / secure pointer to. Obviously it could run C++, since it was one of the first machines to have system software largely written in C++. Or at least according to "Inside the IBM AS/400". Its capabilities were implemented non-forgeable secure pointers. Unfortunately, they used an extra tag bit on memory locations, stolen from ECC. Good for them, unfortunate for the PC industry, where even today most machines do not have ECC. I do not know whether the secure pointers were used for all function calls, or just calls to system software. If used for all function calls, I suspect that they may have had a performance penalty compared to what could have been done, if no secure pointers were used. I suspect that IBM Rochester deserves credit for being willing to take this step, and make it run as fast as possible. I must admit that I was disappointed to learn that late in its lifetime this system added a classic UNIX user/kernel mode. Supposedly to improve security, as well as run UNIX. I look forward to Del finding more neat references. I greatly admire the IBM AS/400 series. However, I do not think that it is the last word for this style of architecture. I think there are improvements yet to be made. |