Skip to content

Multiprocessor support #1

@GoogleCodeExporter

Description

@GoogleCodeExporter
Currently, HyperDbg only puts a single logical CPU into VMX mode. HyperDbg 
will still run on a machine with multiple logical processors, but not very 
well - pressing F12 to break into HyperDbg will only break 25% of the time 
on a 4 CPU box, since the keyboard I/O is only getting intercepted on one 
CPU. 

(Note: When I say processor or CPU below, I mean a logical processor, not a 
physical one. A dual-core processor with HT enabled has 4 logical 
processors).

These changes will need to be made to HyperDbg to support multiple 
processors:

1. Each CPU needs its own vmxInitState and associated memory regions (VMXON 
region, VMCS region, VMEXIT handler stack memory, I/O bitmap, IDT, etc), 
2. VMXON needs called on each processor
3. Each CPU needs its own guest context (CPU_CONTEXT) structure, and any 
function that references the context needs to be able to get the right 
context for the CPU it's running on.
4. Any global structures that can be modified by more than one processor 
will need a lock
5. The cleanup/exit code needs to take all of this into account
6. I'm sure there are other issues 

It's possible to count the logical processors and get the ID of the current 
processor in a OS-independent way with CPUID(1). Getting code to run on a 
specific processor is something that is OS-specific though - you have to 
ask the OS to run a thread on a certain processor by setting the affinity 
mask. In Windows this can be done with ZwSetInformationThread(2). 

Since a major goal of HyperDbg is to have a platform independent core, I 
don't want to muddy up vmx.c with a bunch of Windows-specific API calls 
(although it already makes calls to the Windows kernel's Mm* functions to 
allocate memory...).

With that in mind, here's what I propose:

1. Move any code that requires Windows APIs in vmx.c to a file that 
identifies it as platform-dependent, maybe "vmx-windows.c". Most of 
VmxInitialize() and VmxFinalize() will need to implemented in a platform-
dependent way. #ifdef's can be used to call the right code for the platform 
HyperDbg is built on. Anyone who wants to implement support for other OS's 
can add a vmx-linux.c or vmx-freebsd.c or whatever.
2. Add a function that can identify the current processor and get the 
correct guest context for it. This will be needed by many functions in 
vmx.c and vmhandlers.c. This should be done platform-independently.
3. Review the code to see if there are any other issues that need taken 
into account for multiple processors.

References:

(1): Intel Processor Identification and the CPUID Instruction - 
http://www.intel.com/assets/pdf/appnote/241618.pdf
(2): Processor Affinity in a driver - 
http://www.osronline.com/showThread.cfm?link=26006

Original issue reported on code.google.com by [email protected] on 31 May 2010 at 2:17

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions