I learned from the Xen SOSP paper that Xen installs a fast trap handler to allow the system calls issued by guest app direct trap into the guest os system trap handler. I guess the procedure should be as follows: Guest app issues a system call, because it runs at ring 3, the instruction will be trapped. Xem hypervisor, as a VMM, defines an exception handler for int 80. In the exception handler, there are an interrupt vector defined according to current running guest OS. That is, guest os reports its interrupt vector to vmm, and vmm save the vector for fast handling. Since VMM knows the interrupt vector of the specific guest os, it can directly jump to the right place, which is the entry of the guest os system call function, and start to process the system call. Is my understanding right? If so, I have two questions: first, when will the guest os register the system call handler with the VMM? second, if a guest os is compromised, can intruders change the handler by registering another entry point at runtime? I noticed that many people are trying to do more development on Xen. Can Xen group publish more design document? Although reading source code is usually a good way to understand Xen, it is not the fastest way, not to mention that people may misunderstand some codes. Maybe a simple flow chart of Xen will help us a lot! Thanks. Xin ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Keir Fraser
2004-Jul-19 07:15 UTC
Re: [Xen-devel] questions about the fast trap handler in Xen
> I learned from the Xen SOSP paper that Xen installs a fast trap handler to > allow the system calls issued by guest app direct trap into the guest os > system trap handler. I guess the procedure should be as follows: > > Guest app issues a system call, because it runs at ring 3, the instruction > will be trapped. Xem hypervisor, as a VMM, defines an exception handler > for int 80. In the exception handler, there are an interrupt vector > defined according to current running guest OS. That is, guest os reports > its interrupt vector to vmm, and vmm save the vector for fast handling. > Since VMM knows the interrupt vector of the specific guest os, it can > directly jump to the right place, which is the entry of the guest os > system call function, and start to process the system call.The fast trap vector is installed directly into the IDT when context-switchign between domains, so syscalls will trap directly to teh guest OS in ring 1 --- Xen is not involved in the fast-trap path.> Is my understanding right? If so, I have two questions: > first, when will the guest os register the system call handler with the > VMM?Registers it when it boots, using HYPERVISOR_set_fast_trap().> second, if a guest os is compromised, can intruders change the handler by > registering another entry point at runtime?If a guest OS root account is compromised then an intruder has full control over that OS and can do things like registering a different fast trap handler.> I noticed that many people are trying to do more development on Xen. Can > Xen group publish more design document? Although reading source code is > usually a good way to understand Xen, it is not the fastest way, not to > mention that people may misunderstand some codes. Maybe a simple flow > chart of Xen will help us a lot!More documentation is likely to appear in the future, now that the interface to Xen has stabilised. -- Keir ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel