PAE support

[GoogleCodeExporter]

HyperDbg doesn't support systems using PAE (physical address extension) 
yet. Since almost all modern OS's now operate in PAE mode by default, it's 
desirable to support it. The work done for this will also help pave the way 
towards support for 64 bit OS's.

Here's a short list of things I know need fixed:

1. For the sake of platform independence, move any Windows-specific code to 
vmx-windows.c (also see issue #1 about multiprocessor support)
2. Replace the PHYSICAL_ADDRESS members of VMX_INIT_STATE with a platform 
independent 64bit value. Maybe redefine it as LARGE_INTEGER and define 
LARGE_INTEGER in some other header file so vmx.c doesn't need to include 
ntddk.h
3. Fix VmcVmcsInitialize() in vmx.c to handle large physical addresses from 
#2 - not passing 0 as the high part of the address in calls to VmxClear, 
VmxPtrld, etc. 
4. Fix the functions in mmu.c to handle 64 bit physical addresses and deal 
with the 3 level PAE address translation. This is probably the most work... 
Right now it looks like the only functions actually used are the ones 
needed to read from a process's virtual memory space, used in winxp.c. We 
could start out by making that work and then fixing the rest of the 
functions.
5. I'm sure there are other things that will need fixed.

There is one other thing to consider: should the same driver binary work 
with or without PAE, or should HyperDbg require a compiler switch to build 
the driver for PAE mode? I think it should require a compiler switch. 
Windows has separate kernels for PAE and non-PAE mode, so it should be 
acceptable for HyperDbg to do the same. Most Windows drivers don't need 
specifically built for PAE because they use kernel API's to access memory, 
but HyperDbg doesn't have that luxury. Doing a check for PAE before each 
memory translation would be a performance hit, which isn't important now 
but may be important later.

Original issue reported on code.google.com by jlari...@gmail.com on 31 May 2010 at 3:33

[GoogleCodeExporter]

I think it is better to have only one version that supports PAE and non-PAE, so 
it is 
not confused to users (who dont care about PAE or not), and easier to maintain.

There is no reason to doing check for PAE before every translation: you can do 
that 
once at initialization time, and use the result to avoid later check.

Original comment by junkoi2...@gmail.com on 1 Jun 2010 at 1:54

[GoogleCodeExporter]

It would be very nice to have a version of HyperDbg that is able to adapt to 
the 
guest and to switch PAE support "on" and "off" on demand. 

However, I think it is better to start with a very basic support for PAE (i.e., 
a 
compiler switch that enables/disables PAE). Then, when it will be clear which 
kind of 
changes are needed to support PAE, we can develop a better version of the core 
that 
enables PAE on demand.

As I said to Jon on the mailing list, PAE is currently at the top of our TODO 
list ;-
)

Original comment by roberto.paleari@gmail.com on 4 Jun 2010 at 7:18

[GoogleCodeExporter]

Original comment by roberto.paleari@gmail.com on 15 Jun 2010 at 1:49

• Changed state: Fixed