Hi all,
I know it’s probably not recommeded by anyone, but I really really need to
call some real mode code in a driver. I found some info about how to do it
on x86 processor, looks like it’s doable from x86 driver. but I cannot find
any info on how to call real mode code from x64 driver, anyone can give me
some ideas? Or is it completely not possible?
Thanks in advance.
Michael
Michael Huang wrote:
Hi all,
I know it’s probably not recommeded by anyone, but I really really need to
call some real mode code in a driver. I found some info about how to do it
on x86 processor, looks like it’s doable from x86 driver. but I cannot find
any info on how to call real mode code from x64 driver, anyone can give me
some ideas? Or is it completely not possible?Thanks in advance.
It may not be possible. 64bit Windows uses the CPU in IA-32e mode, some
of the time in its 64bit submode, and some of the time in compatibility
mode. Compatibility mode behaves like 32bit protected mode, and allows
32bit apps to run.
The trouble is compatibility mode doesn’t include Virtual 8086 submode
(subsubmode maybe). It was Virtual 8086 that allowed for the running
of realmode code from 32bit protected mode. Its not there. The CPU
can’t do it, not while in IA-32e mode.
You might be able to use the VM extensions to provide a way to jump
out of IA-32e mode, but I think it would be very hard.
I’ve been looking for a way to do something not quite as hard as
you. I want to run 32 bit code with non-zero based segments, but
I haven’t yet found a way to do that on 64bit windows; there is no easy
way to use the LDT.
If you do get anywhere with this, pleased let me know.
Cheers,
Paul.
I can’t say that this is something I’ve ever considered doing, but as
virtual 86 mode is history with amd64/emt64/intel 64/ia32e/x64, and you
can’t run in compatibility mode in the kernel, at least as far as I
know, the only way that I know of that would work at least in some way,
shape or form, would be to use SMM. This, however, would probably be a
serious undertaking, as it might already be in use, and unless you are
willing to do some esoteric things like changing operating modes while
in SMM, you would be limited to an essentially a 32 bit physical address
space, so you would have to do any translations between any Windows
virtual address you may need and its 32 bit physical SMM equivalent.
Also, debugging this sort of thing would be very difficult without some
sort of hardware assistance in the form of a JTAG emulator like an Arium
ECM-50. Without such hardware, the best thing you could that I’m aware
of would be to read up on your chipset and figure out how to cause SMRAM
to be visible while not in SMM.
All in all, these are just the tip of the proverbial iceberg. If you
really need to do this, this is the best idea I have, but you’re looking
at an uphill battle. It’s totally possible, however, that there are
better ones.
mm
>> xxxxx@emboot.com 2007-05-15 10:04:45 >>>
Hi all,
I know it’s probably not recommeded by anyone, but I really really need
to
call some real mode code in a driver. I found some info about how to do
it
on x86 processor, looks like it’s doable from x86 driver. but I cannot
find
any info on how to call real mode code from x64 driver, anyone can give
me
some ideas? Or is it completely not possible?
Thanks in advance.
Michael
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Thanks for the reply. Looks like I have to find an alternative.
Michael
“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
>I can’t say that this is something I’ve ever considered doing, but as
> virtual 86 mode is history with amd64/emt64/intel 64/ia32e/x64, and you
> can’t run in compatibility mode in the kernel, at least as far as I
> know, the only way that I know of that would work at least in some way,
> shape or form, would be to use SMM. This, however, would probably be a
> serious undertaking, as it might already be in use, and unless you are
> willing to do some esoteric things like changing operating modes while
> in SMM, you would be limited to an essentially a 32 bit physical address
> space, so you would have to do any translations between any Windows
> virtual address you may need and its 32 bit physical SMM equivalent.
> Also, debugging this sort of thing would be very difficult without some
> sort of hardware assistance in the form of a JTAG emulator like an Arium
> ECM-50. Without such hardware, the best thing you could that I’m aware
> of would be to read up on your chipset and figure out how to cause SMRAM
> to be visible while not in SMM.
>
> All in all, these are just the tip of the proverbial iceberg. If you
> really need to do this, this is the best idea I have, but you’re looking
> at an uphill battle. It’s totally possible, however, that there are
> better ones.
>
> mm
>
>>>> xxxxx@emboot.com 2007-05-15 10:04:45 >>>
> Hi all,
>
> I know it’s probably not recommeded by anyone, but I really really need
> to
> call some real mode code in a driver. I found some info about how to do
> it
> on x86 processor, looks like it’s doable from x86 driver. but I cannot
> find
> any info on how to call real mode code from x64 driver, anyone can give
> me
> some ideas? Or is it completely not possible?
>
> Thanks in advance.
>
> Michael
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Thanks for the reply. Looks like I have to find an alternative.
Michael
“Paul Gardiner” wrote in message news:xxxxx@ntdev…
> Michael Huang wrote:
>> Hi all,
>>
>> I know it’s probably not recommeded by anyone, but I really really need
>> to call some real mode code in a driver. I found some info about how to
>> do it on x86 processor, looks like it’s doable from x86 driver. but I
>> cannot find any info on how to call real mode code from x64 driver,
>> anyone can give me some ideas? Or is it completely not possible?
>>
>> Thanks in advance.
>
> It may not be possible. 64bit Windows uses the CPU in IA-32e mode, some
> of the time in its 64bit submode, and some of the time in compatibility
> mode. Compatibility mode behaves like 32bit protected mode, and allows
> 32bit apps to run.
>
> The trouble is compatibility mode doesn’t include Virtual 8086 submode
> (subsubmode maybe). It was Virtual 8086 that allowed for the running
> of realmode code from 32bit protected mode. Its not there. The CPU
> can’t do it, not while in IA-32e mode.
>
> You might be able to use the VM extensions to provide a way to jump
> out of IA-32e mode, but I think it would be very hard.
>
> I’ve been looking for a way to do something not quite as hard as
> you. I want to run 32 bit code with non-zero based segments, but
> I haven’t yet found a way to do that on 64bit windows; there is no easy
> way to use the LDT.
>
> If you do get anywhere with this, pleased let me know.
>
> Cheers,
> Paul.
>
Mucking with SMM is a Very Bad Idea. I am less familiar with the
desktop world but in the server space I can tell you that there is a lot
going on behind the scenes that uses SMM. Generally speaking anything
involving system or processor power states probably uses SMM, and there
are a lot of complexities involved. IMHO 99% OS driver developers
should stay clear, the remaining 1% have email addy’s that end in
microsoft.com, intel.com, amd.com, etc…
Why do you need the real-mode code? Is it a legacy codebase or is there
some intrinsic necessity? I wonder if there is a real-mode emulator
that you could embed in a DLL and use as a sandbox for your real-mode
code?
-Zach
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-286804-
xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Tuesday, May 15, 2007 8:32 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Call real mode code x64I can’t say that this is something I’ve ever considered doing, but as
virtual 86 mode is history with amd64/emt64/intel 64/ia32e/x64, and you
can’t run in compatibility mode in the kernel, at least as far as I
know, the only way that I know of that would work at least in some way,
shape or form, would be to use SMM. This, however, would probably be a
serious undertaking, as it might already be in use, and unless you are
willing to do some esoteric things like changing operating modes while
in SMM, you would be limited to an essentially a 32 bit physical
address
space, so you would have to do any translations between any Windows
virtual address you may need and its 32 bit physical SMM equivalent.
Also, debugging this sort of thing would be very difficult without some
sort of hardware assistance in the form of a JTAG emulator like an
Arium
ECM-50. Without such hardware, the best thing you could that I’m aware
of would be to read up on your chipset and figure out how to cause
SMRAM
to be visible while not in SMM.All in all, these are just the tip of the proverbial iceberg. If you
really need to do this, this is the best idea I have, but you’re
looking
at an uphill battle. It’s totally possible, however, that there are
better ones.mm
>>> xxxxx@emboot.com 2007-05-15 10:04:45 >>>
Hi all,I know it’s probably not recommeded by anyone, but I really really need
to
call some real mode code in a driver. I found some info about how to do
it
on x86 processor, looks like it’s doable from x86 driver. but I cannot
find
any info on how to call real mode code from x64 driver, anyone can give
me
some ideas? Or is it completely not possible?Thanks in advance.
Michael
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Thanks. A real-mode emulator is one of the altenatives I’m considering.
Michael
“Gray, Zachary C” wrote in message
news:xxxxx@ntdev…
Mucking with SMM is a Very Bad Idea. I am less familiar with the
desktop world but in the server space I can tell you that there is a lot
going on behind the scenes that uses SMM. Generally speaking anything
involving system or processor power states probably uses SMM, and there
are a lot of complexities involved. IMHO 99% OS driver developers
should stay clear, the remaining 1% have email addy’s that end in
microsoft.com, intel.com, amd.com, etc…
Why do you need the real-mode code? Is it a legacy codebase or is there
some intrinsic necessity? I wonder if there is a real-mode emulator
that you could embed in a DLL and use as a sandbox for your real-mode
code?
-Zach
>-----Original Message-----
>From: xxxxx@lists.osr.com [mailto:bounce-286804-
>xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
>Sent: Tuesday, May 15, 2007 8:32 AM
>To: Windows System Software Devs Interest List
>Subject: Re: [ntdev] Call real mode code x64
>
>I can’t say that this is something I’ve ever considered doing, but as
>virtual 86 mode is history with amd64/emt64/intel 64/ia32e/x64, and you
>can’t run in compatibility mode in the kernel, at least as far as I
>know, the only way that I know of that would work at least in some way,
>shape or form, would be to use SMM. This, however, would probably be a
>serious undertaking, as it might already be in use, and unless you are
>willing to do some esoteric things like changing operating modes while
>in SMM, you would be limited to an essentially a 32 bit physical
address
>space, so you would have to do any translations between any Windows
>virtual address you may need and its 32 bit physical SMM equivalent.
>Also, debugging this sort of thing would be very difficult without some
>sort of hardware assistance in the form of a JTAG emulator like an
Arium
>ECM-50. Without such hardware, the best thing you could that I’m aware
>of would be to read up on your chipset and figure out how to cause
SMRAM
>to be visible while not in SMM.
>
>All in all, these are just the tip of the proverbial iceberg. If you
>really need to do this, this is the best idea I have, but you’re
looking
>at an uphill battle. It’s totally possible, however, that there are
>better ones.
>
>mm
>
>>>> xxxxx@emboot.com 2007-05-15 10:04:45 >>>
>Hi all,
>
>I know it’s probably not recommeded by anyone, but I really really need
>to
>call some real mode code in a driver. I found some info about how to do
>it
>on x86 processor, looks like it’s doable from x86 driver. but I cannot
>find
>any info on how to call real mode code from x64 driver, anyone can give
>me
>some ideas? Or is it completely not possible?
>
>Thanks in advance.
>
>Michael
>
>
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer
Here’s my totally off-the-wall pair of approaches (which are unlikely to be economically unviable, unless the code you are talking about is well-contained and understood, in which case one wonders about rewrite/recompile- or even reverse translate/recompile…):
(1) write or procure a real mode emulator and let it interpret the real mode code.
(2) write or procure a translator for real mode code to 32-bit protect mode, let it translate the code and execute that [yup, that’d be even worse].
I assume you know the address for the real mode code segment, so just map it as data and pass it off to one of the above two. Emulation might not be as crazy as it sounds, if you resort to machine-level code- all those extra registers could let you use the x86 registers almost directly- maintain the emulated pointers in the extended set.
Seriously, though- at least you have a chance of debugging either approach with tools readily available to you [although you wouldn’t have useful symbols in the latter case- but then again, you wouldn’t have those anyway, would you?].
Whoops- you mentioned “Driver”, so if you meant kernel, any translator for the second case would have to be to 64-bit code, not 32-bit.
-----Original Message-----
From: Bob Kjelgaard
Sent: Tuesday, May 15, 2007 9:15 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Call real mode code x64
Here’s my totally off-the-wall pair of approaches (which are unlikely to be economically unviable, unless the code you are talking about is well-contained and understood, in which case one wonders about rewrite/recompile- or even reverse translate/recompile…):
(1) write or procure a real mode emulator and let it interpret the real mode code.
(2) write or procure a translator for real mode code to 32-bit protect mode, let it translate the code and execute that [yup, that’d be even worse].
I assume you know the address for the real mode code segment, so just map it as data and pass it off to one of the above two. Emulation might not be as crazy as it sounds, if you resort to machine-level code- all those extra registers could let you use the x86 registers almost directly- maintain the emulated pointers in the extended set.
Seriously, though- at least you have a chance of debugging either approach with tools readily available to you [although you wouldn’t have useful symbols in the latter case- but then again, you wouldn’t have those anyway, would you?].
Paul Gardiner wrote:
Michael Huang wrote:
>
> I know it’s probably not recommeded by anyone, but I really really
> need to call some real mode code in a driver. I found some info about
> how to do it on x86 processor, looks like it’s doable from x86
> driver. but I cannot find any info on how to call real mode code from
> x64 driver, anyone can give me some ideas? Or is it completely not
> possible?
>
> Thanks in advance.It may not be possible. 64bit Windows uses the CPU in IA-32e mode, some
of the time in its 64bit submode, and some of the time in compatibility
mode. Compatibility mode behaves like 32bit protected mode, and allows
32bit apps to run.The trouble is compatibility mode doesn’t include Virtual 8086 submode
(subsubmode maybe). It was Virtual 8086 that allowed for the running
of realmode code from 32bit protected mode. Its not there. The CPU
can’t do it, not while in IA-32e mode.
I admit that I haven’t read about the details here, but it’s a fact that
MANY pre-Vista display drivers use INT 10 to call into the video BIOS
for setting the video mode, using APIs like Ke386CallBios. I guess I
would be extremely surprised to learn that display driver writers had to
rewrite their mode set routines in order to make their display drivers
Win64-compatible.
And, in fact, there’s a hint here. If you do “link /dump /imports
videoprt.sys” on a Vista 64 system and it still shows Ke386CallBios,
then a disassembly of ntoskrnl.exe might prove to be very enlightening.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I believe the hal (at least on Vista) does some of this. Look at x
hal!Xm*.
mm
>> xxxxx@microsoft.com 2007-05-15 12:14:57 >>>
Here’s my totally off-the-wall pair of approaches (which are unlikely
to be economically unviable, unless the code you are talking about is
well-contained and understood, in which case one wonders about
rewrite/recompile- or even reverse translate/recompile…):
(1) write or procure a real mode emulator and let it interpret the real
mode code.
(2) write or procure a translator for real mode code to 32-bit protect
mode, let it translate the code and execute that [yup, that’d be even
worse].
I assume you know the address for the real mode code segment, so just
map it as data and pass it off to one of the above two. Emulation might
not be as crazy as it sounds, if you resort to machine-level code- all
those extra registers could let you use the x86 registers almost
directly- maintain the emulated pointers in the extended set.
Seriously, though- at least you have a chance of debugging either
approach with tools readily available to you [although you wouldn’t have
useful symbols in the latter case- but then again, you wouldn’t have
those anyway, would you?].
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Bob Kjelgaard wrote:
I assume you know the address for the real mode code segment, so just map it as data and pass it off to one of the above two. Emulation might not be as crazy as it sounds, if you resort to machine-level code- all those extra registers could let you use the x86 registers almost directly- maintain the emulated pointers in the extended set.
This is quite true. Those who are comfortably ensconced in the womb of
Windows might not realize that the XFree86 and X.org X servers on Linux,
which are roughly the equivalent of GDI and the display driver on
Windows, use an x86 emulator to let drivers call into the video BIOS on
non-x86 platforms for mode setting, DDC access, and I2C access. This is
important for Linux, which supports many non-x86 platforms.
It isn’t lightning fast, of course, but since those functions are only
required at initialization time, performance isn’t terribly important.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I looked for this on one of my Vista targets. Unless I’m missing
something, Ke386CallBios is no longer an export. I don’t know much
about videoprt.sys, but it looks like it might now use x86BiosCall
instead, but I looked casually at that and it looks like it emulates the
stream (hal!XmEmulateStream). It may actually execute it directly; I
really don’t know, there does not seem to be anything in nt!*386*, at
least on the 6001-x64-CHK target at which I looked.
Microsoft (R) COFF/PE Dumper Version 8.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file l:\videoprt.sys
File Type: EXECUTABLE IMAGE
Section contains the following imports:
ntoskrnl.exe
19050 Import Address Table
38050 Import Name Table
0 time date stamp
0 Index of first forwarder reference
6EC ZwSetValueKey
2E1 KeReleaseSpinLock
9B ExQueueWorkItem
417 PoRequestPowerIrp
90 ExInterlockedInsertTailList
BA ExUnregisterCallback
67 ExAllocatePoolWithTag
28D KeClearEvent
193 IoBuildDeviceIoControlRequest
65D ZwClose
668 ZwCreateKey
7D ExFreePoolWithTag
219 IoRegisterPlugPlayNotification
A3 ExRegisterCallback
1D5 IoGetAttachedDeviceReference
49A RtlAppendStringToString
406 ObfReferenceObject
1D4 IoGetAttachedDevice
405 ObfDereferenceObject
202 IoOpenDeviceRegistryKey
195 IoBuildSynchronousFsdRequest
6A ExCreateCallback
3FA ObOpenObjectByPointer
648 ZwAllocateVirtualMemory
37C MmUnmapLockedPages
68D ZwMapViewOfSection
37B MmUnmapIoSpace
292 KeDetachProcess
35D MmMapLockedPagesSpecifyCache
6F4 ZwUnmapViewOfSection
1DA IoGetCurrentProcess
682 ZwFreeVirtualMemory
35B MmMapIoSpace
33E MmCreateMdl
288 KeAttachProcess
1E3 IoGetDmaAdapter
1D0 IoFreeMdl
369 MmProbeAndLockPages
37A MmUnlockPages
187 IoAllocateMdl
332 MmAllocateContiguousMemory
391 NtBuildNumber
5DF SeExports
57F RtlSetDaclSecurityDescriptor
6F7 ZwWriteFile
4C0 RtlCreateRegistryKey
544 RtlLengthSid
4A5 RtlCheckRegistryKey
4C1 RtlCreateSecurityDescriptor
1AB IoCreateFile
20D IoRaiseInformationalHardError
185 IoAllocateErrorLogEntry
490 RtlAddAccessAllowedAce
28C KeCapturePersistentThreadState
438 PsGetCurrentThread
265 IoWriteErrorLogEntry
4A2 RtlCaptureContext
5BC RtlWriteRegistryValue
4BD RtlCreateAcl
1F4 IoInitializeRemoveLockEx
1A8 IoCreateDevice
2A9 KeInitializeMutex
498 RtlAnsiStringToUnicodeString
1BC IoDeleteDevice
41B PoSetPowerState
70E _vsnwprintf
5B9 RtlVirtualUnwind
2B3 KeInsertQueueApc
56A RtlQueryRegistryValues
2C9 KeQueryPriorityThread
432 PsGetContextThread
3D DbgPrintEx
28E KeDelayExecutionThread
42C PsCreateSystemThread
38 DbgBreakPoint
26D KdDebuggerEnabled
47C PsSetContextThread
A0 ExRaiseStatus
54D RtlLookupFunctionEntry
26E KdDebuggerNotPresent
394 NtClose
2CB KeQueryTimeIncrement
2FB KeSetPriorityThread
2A1 KeInitializeApc
3FD ObReferenceObjectByHandle
2F6 KeSetEvent
511 RtlInitAnsiString
37D MmUnmapReservedMapping
33A MmBuildMdlForNonPagedPool
347 MmFreeMappingAddress
35E MmMapLockedPagesWithReservedMapping
335 MmAllocateMappingAddress
316 KiBugCheckData
2B4 KeInsertQueueDpc
26B IofCompleteRequest
21C IoReleaseRemoveLockAndWaitEx
40D PoCallDriver
17F IoAcquireRemoveLockEx
1E4 IoGetDriverObjectExtension
1DF IoGetDeviceProperty
305 KeStackAttachProcess
21D IoReleaseRemoveLockEx
1BF IoDetachDevice
30E KeUnstackDetachProcess
41F PoStartNextPowerIrp
222 IoReportResourceForDetection
223 IoReportResourceUsage
18D IoAssignResources
712 _wcsnicmp
2CE KeReadStateEvent
2E3 KeReleaseSpinLockFromDpcLevel
27F KeAcquireSpinLockAtDpcLevel
1BE IoDeleteSymbolicLink
337 MmAllocatePagesForMdl
205 IoQueryDeviceDescription
680 ZwFlushKey
67B ZwEnumerateKey
21A IoRegisterShutdownNotification
49 EmProviderRegister
171 InbvCheckDisplayOwnership
5AB RtlUpcaseUnicodeString
1F8 IoInvalidateDeviceState
190 IoAttachDeviceToDeviceStack
4F6 RtlFreeUnicodeString
2D5 KeRegisterBugCheckReasonCallback
214 IoRegisterDeviceInterface
3FB ObQueryNameString
1DD IoGetDeviceInterfaces
697 ZwOpenKey
748 wcsrchr
74A wcsstr
22B IoSetDeviceInterfaceState
16B HalDispatchTable
6C5 ZwQueryValueKey
374 MmSetBankedSection
1B2 IoCreateSymbolicLink
290 KeDeregisterBugCheckReasonCallback
6C8 ZwReadFile
4BC RtlCopyUnicodeString
245 IoStopTimer
184 IoAllocateDriverObjectExtension
47 EmProviderDeregister
243 IoStartTimer
177 InbvNotifyDisplayOwnershipLost
525 RtlIntegerToUnicodeString
73C vDbgPrintEx
1C3 IoDisconnectInterrupt
695 ZwOpenFile
173 InbvEnableBootDriver
746 wcsncmp
49C RtlAppendUnicodeToString
740 wcschr
67D ZwEnumerateValueKey
6B5 ZwQueryInformationFile
1F5 IoInitializeTimer
50A RtlGetVersion
24D IoUnregisterPlugPlayNotification
435 PsGetCurrentProcessSessionId
49B RtlAppendUnicodeStringToString
2A4 KeInitializeDpc
589 RtlStringFromGUID
220 IoReportDetectedDevice
6C4 ZwQuerySystemInformation
69D ZwOpenSection
1F7 IoInvalidateDeviceRelations
1A4 IoConnectInterrupt
307 KeSynchronizeExecution
BC ExUuidCreate
25E IoWMIRegistrationControl
263 IoWMIWriteEvent
2A5 KeInitializeEvent
281 KeAcquireSpinLockRaiseToDpc
26A IofCallDriver
515 RtlInitUnicodeString
3C DbgPrint
4A1 RtlAssert
314 KeWaitForSingleObject
2DE KeReleaseMutex
28A KeBugCheckEx
5FE SeSinglePrivilegeCheck
6F9 __C_specific_handler
HAL.dll
19000 Import Address Table
38000 Import Name Table
0 time date stamp
0 Index of first forwarder reference
46 KeQueryPerformanceCounter
15 HalGetBusDataByOffset
47 KeStallExecutionProcessor
4C x86BiosWriteMemory
49 x86BiosCall
4A x86BiosFreeBuffer
4B x86BiosReadMemory
48 x86BiosAllocateBuffer
3B HalTranslateBusAddress
watchdog.sys
19600 Import Address Table
38600 Import Name Table
0 time date stamp
0 Index of first forwarder reference
2A WdDiagShutdown
27 WdDiagInit
29 WdDiagNotifyUser
31 WdGetLowestDeviceObject
2F WdGetDeviceObject
30 WdGetLastEvent
1B WdCompleteEvent
36 WdMadeAnyProgress
13 SMgrGetActiveSessionProcess
5 DMgrReleaseDisplayOwnership
6 DMgrReleaseGdiViewId
0 DMgrAcquireDisplayOwnership
2 DMgrGetDisplayOwnership
1 DMgrAcquireGdiViewId
7 DMgrWriteDeviceCountToRegistry
12 SMgrGdiCallout
Summary
1000 .data
2000 .edata
1000 .pdata
2000 .rdata
1000 .reloc
1000 .rsrc
8000 .text
3000 INIT
17000 PAGE
1000 PAGE_DAT
>> xxxxx@probo.com 2007-05-15 12:43:31 >>>
Paul Gardiner wrote:
Michael Huang wrote:
>
> I know it’s probably not recommeded by anyone, but I really really
> need to call some real mode code in a driver. I found some info
about
> how to do it on x86 processor, looks like it’s doable from x86
> driver. but I cannot find any info on how to call real mode code
from
> x64 driver, anyone can give me some ideas? Or is it completely not
> possible?
>
> Thanks in advance.It may not be possible. 64bit Windows uses the CPU in IA-32e mode,
some
of the time in its 64bit submode, and some of the time in
compatibility
mode. Compatibility mode behaves like 32bit protected mode, and
allows
32bit apps to run.The trouble is compatibility mode doesn’t include Virtual 8086
submode
(subsubmode maybe). It was Virtual 8086 that allowed for the running
of realmode code from 32bit protected mode. Its not there. The CPU
can’t do it, not while in IA-32e mode.
I admit that I haven’t read about the details here, but it’s a fact
that
MANY pre-Vista display drivers use INT 10 to call into the video BIOS
for setting the video mode, using APIs like Ke386CallBios. I guess I
would be extremely surprised to learn that display driver writers had
to
rewrite their mode set routines in order to make their display drivers
Win64-compatible.
And, in fact, there’s a hint here. If you do “link /dump /imports
videoprt.sys” on a Vista 64 system and it still shows Ke386CallBios,
then a disassembly of ntoskrnl.exe might prove to be very
enlightening.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
I believe this is a special-case emulated and/or sandboxed solution.
-Zach
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-286815-
xxxxx@lists.osr.com] On Behalf Of Tim Roberts
I admit that I haven’t read about the details here, but it’s a fact
that
MANY pre-Vista display drivers use INT 10 to call into the video BIOS
for setting the video mode, using APIs like Ke386CallBios. I guess I
would be extremely surprised to learn that display driver writers had
to
rewrite their mode set routines in order to make their display drivers
Win64-compatible.
Paul Gardiner wrote:
Michael Huang wrote:
> Hi all,
>
> I know it’s probably not recommeded by anyone, but I really really
> need to call some real mode code in a driver. I found some info about
> how to do it on x86 processor, looks like it’s doable from x86 driver.
> but I cannot find any info on how to call real mode code from x64
> driver, anyone can give me some ideas? Or is it completely not possible?
>
> Thanks in advance.It may not be possible. 64bit Windows uses the CPU in IA-32e mode, some
of the time in its 64bit submode, and some of the time in compatibility
mode. Compatibility mode behaves like 32bit protected mode, and allows
32bit apps to run.The trouble is compatibility mode doesn’t include Virtual 8086 submode
(subsubmode maybe). It was Virtual 8086 that allowed for the running
of realmode code from 32bit protected mode. Its not there. The CPU
can’t do it, not while in IA-32e mode.You might be able to use the VM extensions to provide a way to jump
out of IA-32e mode, but I think it would be very hard.
Actually, the VM-extensions (which are not in all the x64 chips) are not
needed. A simpler, less involved approach is to do (in reverse) what
old-time DOS-extenders did to run 32 bit programs under DOS:
Save away CPU state etc.
Switch CPU from long mode (64 bit mode) to old fashioned 32 bit mode
with PAE paging tables (to allow physical memory addresses > 4GB).
From there, both the 16 bit modes (Virtual 8086 mode and 16 bit
protected mode) are available as well as 32 bit protected mode.
When the need arrives to run some 64 bit code, switch the CPU back to
long mode, where the 16 bit modes are missing but the 64 bit ones are not.
In your 32 bit CPU setup, there needs to be stub handlers for all
interrupts, traps and SYSENTER/SYSCALL mechanisms . Each of these stubs
need to either do the full handling without 64 bit code or switch the
CPU back to 64 bit mode for the duration.
Because 32 bit mode can only see the first 4GiB of virtual address
space, but putting any of your kernel code or data within the first 8EiB
of long mode virtual address space, the 32 bit and 64 bit modes must use
separate 3rd level paging directories and special care must be taken
when handling any interrupts or traps occurring during the mode switch.
All of this mode switching work would be most easily done by the
ntoskrnl developers already responsible for the relevant parts of the
CPU state, but it is not inconceivable for a 3rd party to develop a
general purpose 16bit extender for 64 bit windows.
For comparison, it should be noted that the x64 version of the Linux
kernel does include VM86 support as a standard configuration option.
–
Jakob B?hm, M.Sc.Eng. * xxxxx@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right
Jakob Bohm wrote:
> .
> .
> .
>
- When the need arrives to run some 64 bit code, switch the CPU back to
long mode, where the 16 bit modes are missing but the 64 bit ones are not.
Am I correct in thinking it’s not the 16bit modes that are missing,
its just the real mode addressing provided by V86 mode that’s missing?
BTW, given your obvious knowledge in this area, I wonder what your
thoughts are on the easiest way to provide 32bit apps, running under
64bit windows, with access to the LDT.
Cheers,
Paul.
Paul Gardiner wrote:
Jakob Bohm wrote:
>
> .
> .
> .
>
> 4. When the need arrives to run some 64 bit code, switch the CPU back
> to long mode, where the 16 bit modes are missing but the 64 bit ones
> are not.Am I correct in thinking it’s not the 16bit modes that are missing,
its just the real mode addressing provided by V86 mode that’s missing?
You are right, I just double-checked the AMD64 manual, 16 bit protected
mode is available in long mode too, so in theory, WOW32 for Win16 and
the OS/2 1.x subsystems could be implemented without mode switching,
even though simulate-real-mode ntvdm.exe DOS support could not.
BTW, given your obvious knowledge in this area, I wonder what your
thoughts are on the easiest way to provide 32bit apps, running under
64bit windows, with access to the LDT.
The easiest way would be if Microsoft would implement the SetLDT
syscalls in the x64 ntoskrnl.exe . But in general the x64 core
implementation suffers from its Alpha64/Itanium heritage where efficient
DOS-like features were assumed absent at the hardware level.
Adding LDT manipulation for existing ntoskrnl.exe files already shipped
would involve some pretty deep interactions with the Mm and Ke parts of
the ntoskrnl code (to avoid sudden disappearance and BSODs), but the
actual setting could be via a device io control to a special driver.
Such an add-on driver would be fully responsible for security-checking
the proposed entries, to prevent uncontrolled switching to ring 0/1/2
(gate descriptors etc.), access to kernel memory (descriptors with
limits or bases that go outside the low 8EiB of the address space) and
BSOD conditions (invalid descriptors and descriptors that trigger traps
not supported by the ntoskrnl trap handlers).
Also such a driver may need to deal with setting proper segment register
values when interrupts, traps and syscalls occur, in case the
implementations in ntoskrnl assume that weird segments are not in the
tables and cannot be in the registers.
–
Jakob B?hm, M.Sc.Eng. * xxxxx@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right
MSDN says that, in Win64, handles have 32 significant bits (being 64bit
wide datatype).
Since Win16 and DOS handles are 16bit, NTVDM on Win64 is not possible - not
all file handles will be representable in 16bit world.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
“Jakob Bohm” wrote in message news:xxxxx@ntdev…
Paul Gardiner wrote:
> Jakob Bohm wrote:
>>
> > .
> > .
> > .
> >
>> 4. When the need arrives to run some 64 bit code, switch the CPU back
>> to long mode, where the 16 bit modes are missing but the 64 bit ones
>> are not.
>
> Am I correct in thinking it’s not the 16bit modes that are missing,
> its just the real mode addressing provided by V86 mode that’s missing?
>
You are right, I just double-checked the AMD64 manual, 16 bit protected
mode is available in long mode too, so in theory, WOW32 for Win16 and
the OS/2 1.x subsystems could be implemented without mode switching,
even though simulate-real-mode ntvdm.exe DOS support could not.
>
> BTW, given your obvious knowledge in this area, I wonder what your
> thoughts are on the easiest way to provide 32bit apps, running under
> 64bit windows, with access to the LDT.
>
The easiest way would be if Microsoft would implement the SetLDT
syscalls in the x64 ntoskrnl.exe . But in general the x64 core
implementation suffers from its Alpha64/Itanium heritage where efficient
DOS-like features were assumed absent at the hardware level.
Adding LDT manipulation for existing ntoskrnl.exe files already shipped
would involve some pretty deep interactions with the Mm and Ke parts of
the ntoskrnl code (to avoid sudden disappearance and BSODs), but the
actual setting could be via a device io control to a special driver.
Such an add-on driver would be fully responsible for security-checking
the proposed entries, to prevent uncontrolled switching to ring 0/1/2
(gate descriptors etc.), access to kernel memory (descriptors with
limits or bases that go outside the low 8EiB of the address space) and
BSOD conditions (invalid descriptors and descriptors that trigger traps
not supported by the ntoskrnl trap handlers).
Also such a driver may need to deal with setting proper segment register
values when interrupts, traps and syscalls occur, in case the
implementations in ntoskrnl assume that weird segments are not in the
tables and cannot be in the registers.
–
Jakob Bøhm, M.Sc.Eng. * xxxxx@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right
Jakob Bohm wrote:
The easiest way would be if Microsoft would implement the SetLDT
syscalls in the x64 ntoskrnl.exe.
That would be so good! Seems a little unlikely though - only if
Microsoft need it themselves I would have thought, and I can’t
think why they would.
Adding LDT manipulation for existing ntoskrnl.exe files already shipped
would involve some pretty deep interactions with the Mm and Ke parts of
the ntoskrnl code (to avoid sudden disappearance and BSODs), but the
actual setting could be via a device io control to a special driver.
I have bought a copy of 64bit Vista only very recently, so I haven’t
started looking into this in earnest yet, but the first problem I’m
expecting is there to be no LDT, and hence no index for it in the
GDT. If so, any idea how I can trick the kernel into allowing the
addition of a GDT entry for the LDT?
As I said, I haven’t gotten along far enough yet to test whether
there is already an unused LDT in place so maybe I’ll be lucky.
Such an add-on driver would be fully responsible for security-checking
the proposed entries, to prevent uncontrolled switching to ring 0/1/2
(gate descriptors etc.), access to kernel memory (descriptors with
limits or bases that go outside the low 8EiB of the address space)
Yeah, I realised that such a driver was a potential security hole
but the conditions that I’d need to ensure don’t look too complicated…
and
BSOD conditions (invalid descriptors and descriptors that trigger traps
not supported by the ntoskrnl trap handlers).
… although, Eek, I don’t understand that area of the problem.
Also such a driver may need to deal with setting proper segment register
values when interrupts, traps and syscalls occur, in case the
implementations in ntoskrnl assume that weird segments are not in the
tables and cannot be in the registers.
Hadn’t thought of that either. I’d have thought there was a good chance
that the kernel wouldn’t be checking that. Hope it doesn’t.
I guess there’s also the problem of maintaining the LDTs across task
switches. I think my appication could work even if there was just
a single LDT used for all tasks. Also I think it could work even
if the LDT persisted only up to a task switch and the app had to
keep redefining it… maybe that wouldn’t work though: if you
return to a task and pull selector register values off the stack that
have no valid GDT or LDT entry, do the selector registers get
zeroed? I seem to recollect that being the case.
Most grateful for any thoughts on this.
Cheers,
Paul.
Paul Gardiner wrote:
Jakob Bohm wrote:
> The easiest way would be if Microsoft would implement the SetLDT
> syscalls in the x64 ntoskrnl.exe.That would be so good! Seems a little unlikely though - only if
Microsoft need it themselves I would have thought, and I can’t
think why they would.
Win16 support would be a good Microsoft use.
> Adding LDT manipulation for existing ntoskrnl.exe files already
> shipped would involve some pretty deep interactions with the Mm and Ke
> parts of the ntoskrnl code (to avoid sudden disappearance and BSODs),
> but the actual setting could be via a device io control to a special
> driver.I have bought a copy of 64bit Vista only very recently, so I haven’t
started looking into this in earnest yet, but the first problem I’m
expecting is there to be no LDT, and hence no index for it in the
GDT. If so, any idea how I can trick the kernel into allowing the
addition of a GDT entry for the LDT?As I said, I haven’t gotten along far enough yet to test whether
there is already an unused LDT in place so maybe I’ll be lucky.> Such an add-on driver would be fully responsible for security-checking
> the proposed entries, to prevent uncontrolled switching to ring 0/1/2
> (gate descriptors etc.), access to kernel memory (descriptors with
> limits or bases that go outside the low 8EiB of the address space)Yeah, I realised that such a driver was a potential security hole
but the conditions that I’d need to ensure don’t look too complicated…
No, basically the same ones checked by Microsoft’s own LDT syscalls in
the i386 ntoskrnl .
> and BSOD conditions (invalid descriptors and descriptors that trigger
> traps not supported by the ntoskrnl trap handlers).… although, Eek, I don’t understand that area of the problem.
Many traps (such as GP, but there are others) are triggered by the
relationships between what code tries to do and what is in the
descriptor tables. The trap handlers in ntoskrnl know how to deal with
the trap scenarios that occur without a modified LDT and might end up
doing “the wrong thing” when suddenly exposed to a wider range of
possibilities due to new LDT entries.
> Also such a driver may need to deal with setting proper segment
> register values when interrupts, traps and syscalls occur, in case the
> implementations in ntoskrnl assume that weird segments are not in the
> tables and cannot be in the registers.Hadn’t thought of that either. I’d have thought there was a good chance
that the kernel wouldn’t be checking that. Hope it doesn’t.
Well that would be the problem! If the kernel assumes that the only
possible data or code selectors at trap/interrupt/syscall time are the
ones it provides itself, it might make (unchecked) assumptions about
what those selectors could be like and get mighty confused if a
completely different (LDT) selector was active.
I guess there’s also the problem of maintaining the LDTs across task
switches. I think my appication could work even if there was just
a single LDT used for all tasks. Also I think it could work even
if the LDT persisted only up to a task switch and the app had to
keep redefining it… maybe that wouldn’t work though: if you
return to a task and pull selector register values off the stack that
have no valid GDT or LDT entry, do the selector registers get
zeroed? I seem to recollect that being the case.
If a pop from stack or any other method tries to load a
no-longer-current selector handle, the result is a GP (trap0D). And
always consider the possibility of the last running task having its own
LDT with a different meaning for one of your LDT entries.
So a bolt-on driver might need to intercept task switches too, but doing
that is a documented step.
–
Jakob B?hm, M.Sc.Eng. * xxxxx@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right