Is it possible to access real mode from a windows driver. I would like to query a piece of hardware that has bios interrupt calls but cannot call these from protected mode which is what windows normally runs in. any ideas?
The short answer is no. What sort of hardware is this?
Mark Roddy
On Thu, Sep 30, 2010 at 12:35 PM, wrote:
> Is it possible to access real mode from a windows driver. I would like to query a piece of hardware that has bios interrupt calls but cannot call these from protected mode which is what windows normally runs in. any ideas?
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
Not really, though there are a couple of exotic, special case ways to do
this, but not without a REALLY good reason.
What’s your hardware?
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@EMPIRE.ECLIPSE.NCSC.MIL
Sent: Thursday, September 30, 2010 12:35 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Real Mode
Is it possible to access real mode from a windows driver. I would like to
query a piece of hardware that has bios interrupt calls but cannot call
these from protected mode which is what windows normally runs in. any ideas?
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Yeah, and what kind of hardware even CARES if is or isn’t in protected mode?
How would it even know unless a driver running in protected mode configured
the hardware for only feral mode.
Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Thursday, September 30, 2010 11:22 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Real Mode
The short answer is no. What sort of hardware is this?
Mark Roddy
On Thu, Sep 30, 2010 at 12:35 PM, wrote:
> Is it possible to access real mode from a windows driver. I would like to
query a piece of hardware that has bios interrupt calls but cannot call
these from protected mode which is what windows normally runs in. any ideas?
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
xxxxx@EMPIRE.ECLIPSE.NCSC.MIL wrote:
Is it possible to access real mode from a windows driver. I would like to query a piece of hardware that has bios interrupt calls but cannot call these from protected mode which is what windows normally runs in. any ideas?
It is possible, at least on 32-bit systems, but it’s not easy and it’s
not documented. There is an undocumented kernel API called
Ke386CallBios that can make BIOS calls in V86 mode. The only way to
figure out its use is by reverse engineering. The display video port
driver uses it to call INT 10 to change the video mode.
I’m assuming V86 mode is good enough. If you truly need real mode, then
you’re on your own.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Gary G. Little wrote:
Yeah, and what kind of hardware even CARES if is or isn’t in protected mode?
How would it even know unless a driver running in protected mode configured
the hardware for only feral mode.
The hardware doesn’t care, but the BIOS code does. If it were me, I
would probably disassemble the BIOS and re-implement the code in my
driver. It’s probably little more than a bunch of I/O statements, and
that would be a lot easier than calling Ke386CallBios.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
It’s been a while since I looked at this, but I’m not sure that
Ke368CallBios() allows one to safely call arbitrary BIOS routines.
You might be able to disassemble the BIOS calls in question and reimplement
them in your driver. If this is possible, this is DEFINITELY what I would
do.
Otherwise, not that I’m in any way, shape or form recommending this, but if
you really need to do this, on both x86_32 and x86_64, you could use SMM,
but that would be very complicated, a lot of work, not necessarily stable
and decidedly not supported, to put it mildly.
Good luck,
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, September 30, 2010 2:06 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Real Mode
xxxxx@EMPIRE.ECLIPSE.NCSC.MIL wrote:
Is it possible to access real mode from a windows driver. I would like to
query a piece of hardware that has bios interrupt calls but cannot call
these from protected mode which is what windows normally runs in. any ideas?
It is possible, at least on 32-bit systems, but it’s not easy and it’s
not documented. There is an undocumented kernel API called
Ke386CallBios that can make BIOS calls in V86 mode. The only way to
figure out its use is by reverse engineering. The display video port
driver uses it to call INT 10 to change the video mode.
I’m assuming V86 mode is good enough. If you truly need real mode, then
you’re on your own.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> Yeah, and what kind of hardware even CARES if is or isn’t in protected mode?
…any piece of hardware that is meant to be accessed only in SMM by the code that got installed by the
firmware - for example, a thermal device…
Anton Bassov
> but that would be very complicated, a lot of work, not necessarily stable
and decidedly not supported
Aside from that it’s fine though 
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> It’s been a while since I looked at this, but I’m not sure that
> Ke368CallBios() allows one to safely call arbitrary BIOS routines.
>
> You might be able to disassemble the BIOS calls in question and
> reimplement
> them in your driver. If this is possible, this is DEFINITELY what I would
> do.
>
> Otherwise, not that I’m in any way, shape or form recommending this, but
> if
> you really need to do this, on both x86_32 and x86_64, you could use SMM,
> but that would be very complicated, a lot of work, not necessarily stable
> and decidedly not supported, to put it mildly.
>
>
>
> Good luck,
>
> mm
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
> Sent: Thursday, September 30, 2010 2:06 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Real Mode
>
> xxxxx@EMPIRE.ECLIPSE.NCSC.MIL wrote:
>> Is it possible to access real mode from a windows driver. I would like to
> query a piece of hardware that has bios interrupt calls but cannot call
> these from protected mode which is what windows normally runs in. any
> ideas?
>
>
> It is possible, at least on 32-bit systems, but it’s not easy and it’s
> not documented. There is an undocumented kernel API called
> Ke386CallBios that can make BIOS calls in V86 mode. The only way to
> figure out its use is by reverse engineering. The display video port
> driver uses it to call INT 10 to change the video mode.
>
> I’m assuming V86 mode is good enough. If you truly need real mode, then
> you’re on your own.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
Yes, otherwise you’ll really enjoy the play, Mrs. Lincoln.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Thursday, September 30, 2010 3:13 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Real Mode
but that would be very complicated, a lot of work, not necessarily stable
and decidedly not supported
Aside from that it’s fine though
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> It’s been a while since I looked at this, but I’m not sure that
> Ke368CallBios() allows one to safely call arbitrary BIOS routines.
>
> You might be able to disassemble the BIOS calls in question and
> reimplement
> them in your driver. If this is possible, this is DEFINITELY what I would
> do.
>
> Otherwise, not that I’m in any way, shape or form recommending this, but
> if
> you really need to do this, on both x86_32 and x86_64, you could use SMM,
> but that would be very complicated, a lot of work, not necessarily stable
> and decidedly not supported, to put it mildly.
>
>
>
> Good luck,
>
> mm
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
> Sent: Thursday, September 30, 2010 2:06 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Real Mode
>
> xxxxx@EMPIRE.ECLIPSE.NCSC.MIL wrote:
>> Is it possible to access real mode from a windows driver. I would like to
> query a piece of hardware that has bios interrupt calls but cannot call
> these from protected mode which is what windows normally runs in. any
> ideas?
>
>
> It is possible, at least on 32-bit systems, but it’s not easy and it’s
> not documented. There is an undocumented kernel API called
> Ke386CallBios that can make BIOS calls in V86 mode. The only way to
> figure out its use is by reverse engineering. The display video port
> driver uses it to call INT 10 to change the video mode.
>
> I’m assuming V86 mode is good enough. If you truly need real mode, then
> you’re on your own.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>You might be able to disassemble the BIOS calls in question and reimplement them in your driver.
If this is possible, this is DEFINITELY what I would do. Otherwise, not that I’m in any way, shape
or form recommending this, but if you really need to do this, on both x86_32 and x86_64, you could use
SMM, but that would be very complicated, a lot of work, not necessarily stable and decidedly not
supported, to put it mildly.
Now consider what happens if some hardware event/condition triggers SMI while your operation is in progress - you cannot guard yourself against it, can you. If SMI handler happens to operate on the same device registers that you are accessing from your driver and it catches you in the middle of your operation, you can end up with absolutely anything, including hardware damage. Therefore, I am not sure that reimplementing BIOS call in a driver is lesser evil compared to entering SMM…
Anton Bassov
Well, if we are waxing hypothetical, yes, what you’re saying is true for any
code running anywhere on the system. SMM could preempt all of it and have
its way with whatever it wants, so if it has its eyes on your registers,
you’re screwed.
For example, under your scenario, some rogue SMM handler out there right now
as we speak could be in the process of trashing the registers of
everybody’s, say, RTC. I can’t say that I’ve checked, but I’m going to
venture that the HAL is not implemented in SMM to account for this scenario,
but even if it happens to be, if he were to go to pounding away in SMM,
corruption would certainly still happen if he failed to emulate the
hypothetical HAL’s functionality perfectly - provided that that’s even
possible, which it isn’t necessarily - and might happen no matter what he
did, depending on the hardware (write only registers, for example).
This is also true for hypervisors. At least as commercially implemented
(I’ve never seen anything that implements dual smm treatment), any SMM
handler can do whatever it wants.
A similar argument could be made for rouge NMI handlers or for that matter
any code that runs at a higher IRQL than you do.
The bottom line for him and everybody else is that you can’t access hardware
that you don’t own safely, no matter how you do so. If that’s what he’s
going to do that (I have no idea of what he’s actually trying to do), then
he’s screwed.
So, I fail to see why rolling your own SMM handler - which minimally
includes coexisting with the previous one (not always possible), dealing
with write only registers, (protected mode) interrupt latency, et. c. - is a
better idea than accessing the SAME hardware resources using
REG_REGISTER_ULONG() or whatever, just because something that could happen
at any time to anything in the kernel might happen just to him. If he is
able to do the latter and he owns the hardware, then he’s as close to a
legacy driver as he’s going to be able to get.
Now, if he needs features that he can’t perform from a driver, or if he
needs SMM to emulate the hardware so that some other driver remains
functional (dubious in practice), then, yes, I would say that his only
chance is SMM, but that’s not obviously going to work either and will easily
be a good order of magnitude harder to get right, so I definitely would
consider it an absolute last resort until the need is proven, and what
you’re proposing as a reason is already true for all code running in the
kernel, at least as I see it.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Thursday, September 30, 2010 9:22 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Real Mode
You might be able to disassemble the BIOS calls in question and reimplement
them in your driver.
If this is possible, this is DEFINITELY what I would do. Otherwise, not
that I’m in any way, shape
or form recommending this, but if you really need to do this, on both
x86_32 and x86_64, you could use
SMM, but that would be very complicated, a lot of work, not necessarily
stable and decidedly not
supported, to put it mildly.
Now consider what happens if some hardware event/condition triggers SMI
while your operation is in progress - you cannot guard yourself against it,
can you. If SMI handler happens to operate on the same device registers that
you are accessing from your driver and it catches you in the middle of your
operation, you can end up with absolutely anything, including hardware
damage. Therefore, I am not sure that reimplementing BIOS call in a driver
is lesser evil compared to entering SMM…
Anton Bassov
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> yes, what you’re saying is true for any code running anywhere on the system. SMM could preempt
all of it and have its way with whatever it wants, so if it has its eyes on your registers, you’re screwed.
For example, under your scenario, some rogue SMM handler
You are missing the main point here - in the scenario that I describe it is not “rogue SMI handler who has its eyes on your registers”, but, instead, it is your rogue driver who attempts to access registers of a device that is supposed to be accessed only in context of SMI handler. After all, it is your driver who tries to re-implement a feature that is already implemented in a firmware and not the other way around…
So, I fail to see why rolling your own SMM handler - which minimally includes coexisting with the
previous one (not always possible), dealing with write only registers, (protected mode)
interrupt latency, et. c. - is a better idea than accessing the SAME hardware resources using >REG_REGISTER_ULONG() or whatever, just because something that could happen at any time to
anything in the kernel might happen just to him.
That’s because the existing one will be able to run only after yours exits and only if your handler decides that the existing one should be allowed to run, in he first place - they are not going to overlap one another at any particular moment. However, if you allow the possibility of your code being interrupted by SMI, then they may overlap and screw up one another’s operations…
Anton Bassov
A hard solution might be to put a whole x86 emulator in the driver. You
MIGHT succeed in getting one of the public emulators to compiler and run in
a kernel environment. You could make some low physical to virtual memory
mappings for the emulator to use, and then set its virtual execution context
to the real mode code address you want. An ugly little issue is some real
mode code is not real mode at all. I know of PCI adapter BIOS’s (like gPXE
boot roms) that you call the real mode entry point, and they shift into 386
protected mode, run some code, and then shift back to real mode. Other PCI
adapter roms put the processor in big real mode, which is essentially like
real mode, except segment limits are 4GB and you can use 4GB offsets. You
have to go into protected mode and then exit back to real mode in a specific
way to enable big real mode. An emulator COULD do all this. If real mode
code expects to process real hardware interrupts, it would be very sticky.
Even accessing things like the PCI config address and data registers would
be sticky, as there may be other processors causing the OS to use them too,
so you would need to capture all the processors or the emulator would need
to trap simulated access to dangerous ports and use OS API’s to simulate
them. Sounds like a lot of work offhand, although for some very specific
card you need to call, you might not need to handle every ugly case because
that device doesn’t do ugly operations. An interpreted emulator like Bochs
might be the thing to look at.
Jan
Is it possible to access real mode from a windows driver. I would like to
query
a piece of hardware that has bios interrupt calls but cannot call these
from
protected mode which is what windows normally runs in. any ideas?
> A hard solution might be to put a whole x86 emulator in the driver.
Actually, I just don’t understand how emulator may help here. After all, the OP wants to actually communicate with the physical device, rather than just making driver believe that it does. If this was an objective emulator would be, indeed, a good option…
Anton Bassov
>
> A hard solution might be to put a whole x86 emulator in the driver.
Actually, I just don’t understand how emulator may help here. After
all, the
OP wants to actually communicate with the physical device, rather
than just
making driver believe that it does. If this was an objective emulator
would
be, indeed, a good option…
The emulator runs the real mode code, and as soon as your emulated code
tries to do any io to the ports you are interested in then you actually
read the physical port rather than a virtual port.
Given that the code you want to emulate is very minimal you probably
only need a fairly small subset of a full emulator.
James
> as soon as your emulated code tries to do any io to the ports you are interested in then you actually
read the physical port
This is exactly what my point is - you need to read a physical port anyway, and, due to the specifics of the target device (it must be obviously something “not-so-conventional” like, for example, a thermal device on SMBus) the only possible way to do it is in the real mode. This is why I cannot understand how emulator may possibly help here. …
Anton Bassov
Jan Bottorff wrote:
A hard solution might be to put a whole x86 emulator in the driver. You
MIGHT succeed in getting one of the public emulators to compiler and run in
a kernel environment. You could make some low physical to virtual memory
mappings for the emulator to use, and then set its virtual execution context
to the real mode code address you want.
I’m not sure whether you’re familiar with it, but this is EXACTLY the
approach used by the X Window server on Linux. Many of the graphics
drivers call into INT 10 to set the video mode, and that’s a big problem
on non-x86 machines, since ROM BIOSes are always x86 machine code. So,
they have an x86 emulator embedded right in the server that simulates
the BIOS code. It works surprisingly well.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
xxxxx@hotmail.com wrote:
> as soon as your emulated code tries to do any io to the ports you are interested in then you actually
> read the physical port
This is exactly what my point is - you need to read a physical port anyway, and, due to the specifics of the target device (it must be obviously something “not-so-conventional” like, for example, a thermal device on SMBus) the only possible way to do it is in the real mode. This is why I cannot understand how emulator may possibly help here. …
I don’t see the problem. If my emulator comes across an OUT DX, AL
instruction, I will emulate that by executing WRITE_PORT_UCHAR with the
emulated values of DX and AL. I will be doing exactly the same I/O
cycles that the 16-bit code would have done.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> I’m not sure whether you’re familiar with it, but this is EXACTLY the
approach used by the X Window server on Linux. Many of the graphics
drivers call into INT 10 to set the video mode, and that’s a big problem
on non-x86 machines, since ROM BIOSes are always x86 machine code. So,
they have an x86 emulator embedded right in the server that simulates
the BIOS code. It works surprisingly well.
You’d think open source people would fix their drivers instead…
–
Aram Hăvărneanu