This seems like conveniently good news. Combining all the ideas:
Hide CPUID.SYSCALL to force 32-bit OSes to use 32-bit legacy SYSENTER, which is available on AMD and Intel. 64-bit OSes will use SYSCALL for 64-bit code. CPUID name string should be "FakeCPUFakeCPU" or some such so a 64-bit OS will avoid SYSCALL and SYSENTER for 32-bit code. A 64-bit Linux will use int80 for its 32-bit code, by Alex's observation. A 64-bit Windows will use a thunk that gets to long mode before using SYSCALL, by Skywing's observation. Intercept #UD and emulate any of the SYSENTER, SYSCALL, SYSRET, SYSEXIT instructions that fall through the cracks. I think this addresses Alex's observations about MacOS/Darwin's use of SYSENTER. This leaves you with a hypervisor that doesn't have to know a priori what the guest is going to do and can do nearly all its tricks through CPUID control. The only unsatisfying piece is anything high-frequency that the hypervisor ends up having to emulate. Maybe in-guest patching works on Darwin if it doesn't have any intrusion detection going on? Ben -----Original Message----- From: Skywing [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2008 4:02 PM To: Alexander Graf; Anthony Liguori Cc: [email protected] list; Amit Shah; Avi Kivity; Wahlig, Elsie; Serebrin, Benjamin (Calendar); Nakajima, Jun Subject: RE: Cross vendor migration ideas Hi, -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Graf Sent: Wednesday, November 12, 2008 10:50 AM To: Anthony Liguori Cc: [email protected] list; Amit Shah; Avi Kivity; Elsie Wahlig; Serebrin, Benjamin (Calendar); Nakajima, Jun > Windows does have background daemons that check code in runtime and > compares that to checksums. So binary patching might break Windows > pretty easily. I'm really wondering why the CR8 patching still works - > maybe even that'll break with Windows 7. > Alex If you're thinking of PatchGuard, that's only there on amd64 Windows, not 32-bit x86. However, I think that patching is likely to cause other issues in general and should be avoided. BTW, 32-bit [x86] programs on amd64 Windows will all eventually get thunked through the 64-bit system call interface, which is always (hardcoded) syscall for amd64 Windows. It is only if you are running a 32-bit (x86) Windows kernel that you may optionally use one of [sysenter, syscall, int 2e]. In other words, if you are running a 64-bit Windows kernel, even the 32-bit parts will always pick syscall regardless of the reported processor feature set. The 32-bit binaries that make the system call transitions to kernel mode are different if you are running a 64-bit Windows kernel versus a 32-bit kernel; the code to differentiate which mechanism to use is removed. (In fact, to be specific, it is always 64-bit code that issues the actual syscall instruction, as the call path in the Wow64 [32-bit Windows program running under an amd64 Windows kernel] case is 32-bit program code -> 32-bit ntdll.dll -> 64-bit wow64.dll -> 64-bit ntdll.dll, where 64-bit ntdll.dll is the system-supplied binary that makes the actual system service calls. The switch from 32-bit mode to 64-bit mode in amd64 Windows is done in user mode. All system call transitions are thus done from 64-bit mode in the 64-bit Windows case. This sequence is independent of CPU vendor.) You could probably get away with not claiming support for sysenter/syscall for 32-bit guests, as Windows will degrade gracefully to int 2e in that case for guests running a 32-bit kernel. Performance implications for that still apply of course. - S -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
