SYSENTER/SYSEXIT_vs._SYSCALL/SYSRET
|
From: "Andy "Krazy" Glew" on 18 Jan 2010 21:48 EricP wrote: > Secondly, the problem with SysEnter is that it assumes that > the EDX will be preloaded with the restart EIP This is not SYSENTER's assumption. This is a particular usage model for SYSENTER. Not a good usage model. One that introduces potential security holes. > but the x86 > provides no easy method load load an arbitrary offset of the > current EIP into EDX except that kludgey call +0, pop edx method. > So to use SysEnter you have to preload EDX with a constant restart > EIP and that presumes the entry sequence is at a predefined > location and that limits the utility of the SysEnter somewhat. Agreed. Note that x86 eventually got around to adding READ_EIP instruction. > What would have been nice is if there was an instruction to move > EIP to a general register and add a constant offset at the same time. Yep. It's amazing how hard it is to get simple stuff like that approved.
From: "Andy "Krazy" Glew" on 18 Jan 2010 21:53 Gavin Scott 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. > > This was MPE/XL (later MPE/iX) on PA-RISC, HP's operating system for > their HP-3000 systems. .... > Now any modern security architect would probably run screaming at > this point, and there definitely were challenges in this area > (user asynchronous unprivileged trap/event handlers being a rather > obvious one), but I'm not aware of any dramatic failures resulting > from this design. On the other hand I don't think anyone would be > likely to make such design choices again in today's world. Another problem would be multithreaded code. What if other untrusted user threads were executed at the same time on other processors, accessing this stack? As a student intern once said: "shared memory = security hole". --- Thanks for the pointer to HP MPE/XL. With your permission, I may include a note about this on my website. By the way, if you care to you can add such commentary to my website. Unfortunately, not http://semipublic.comp-arch.net/wiki/Page_name, but to the shadow page http://public.comp-arch.net/wiki/Page_name. There are cross links between the pages. By the way, HP PA RISC had a good protected entry point mechanism - IIRC called "gateways". Did MPE/XL make use of these?
From: Del Cecchi on 18 Jan 2010 23:12 "Andy "Krazy" Glew" <ag-news(a)patten-glew.net> wrote in message news:4B551C9C.1070706(a)patten-glew.net... > 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. > I came across this tome that might be of interest to some http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/QB3AUO02/CCONTENTS Title: OS/400 CL Programming V4R4 Document Number: SC41-5721-02 Build Date: 03/07/99 08:49:12 Build Version: 1.3.0 found it in http://www.ibm.com/developerworks/systems/articles/building.html Building AS/400 commands for UNIX programs (I sure hope the formatting returns to plain text. I end up with italics, bold, huge fonts....) del
From: Del Cecchi on 18 Jan 2010 23:17 "Andy "Krazy" Glew" <ag-news(a)patten-glew.net> wrote in message news:4B551C9C.1070706(a)patten-glew.net... > 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. In the bibliography of the above book there are reference to http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/QB3AVC00/CCONTENTS?DT=19970312110239 and http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/QB3AMA04/CCONTENTS?DT=19990525133816 a.. System API Programming, SC41-5800-00, This book provides information for experienced application and system programmers who want to use the OS/400 application programming interfaces (APIs). This book provides getting started examples to help the programmer use APIs. a.. System API Reference, SC41-5801-03, This book provides information for the experienced programmer on how to use the application programming interfaces (APIs) for OS/400 functions. This book also includes original program model (OPM), Integrated Language Environment (ILE), and UNIX-type APIs. >
From: EricP on 18 Jan 2010 23:17
Andy "Krazy" Glew wrote: > EricP wrote: > >> Secondly, the problem with SysEnter is that it assumes that >> the EDX will be preloaded with the restart EIP > > This is not SYSENTER's assumption. > > This is a particular usage model for SYSENTER. Not a good usage model. > One that introduces potential security holes. I don't see the potential security hole. Looking at some Linux documentation I see it uses SysExit to always return to EIP = a constant address defined by the kernel and the ESP = value passed in by the caller. But I don't see why that would be any better. >> but the x86 >> provides no easy method load load an arbitrary offset of the >> current EIP into EDX except that kludgey call +0, pop edx method. >> So to use SysEnter you have to preload EDX with a constant restart >> EIP and that presumes the entry sequence is at a predefined >> location and that limits the utility of the SysEnter somewhat. > > Agreed. > > Note that x86 eventually got around to adding READ_EIP instruction. Where is that? I find no reference to such an instruction. Eric |