sample W2K PCI driver for memory mapped I/O
Bernd Hofner
does anyone know where I can find a sample driver with the following
characteristics:
OS: W2K
BUS: PCI
TODO: map dual ported physical RAM on the PCI card to user-space
There has been a similar example for NT4.0 in the DDK called Mapmem,
which seems to be no longer present in the W2K DDK.
What I want to do is:
- walk through the list of the PCI cards until I find my
Vendor/Device ID
- access the PCI configuration register to gain a pointer
to the loctaion of the DP-RAM of the card
- map that pointer to user space so that I can access it
from my application
This is probably not quite the "NT-way" of doing it, but it doesn't
make sense to wrap the access to the DP-RAM in IRPs, because my
app is the only one accessing the board (it's a Siemens CP5613 PROFIBUS
card).
In fact I wouldn't bother writing a driver at all, if the Siemens
supplied "driver package" wouldn't force me to install 190MB of
undesired stuff, including background services I certainly don't need...
I could try to extract just the needed *.sys, *.dll, registry entries
etc from this package, but that seems to be a bit to much archaeology
for me.
Thanks in advance,
bernd hofner | diesterwegstr. 3 | 57078 siegen germany
tel: +49 (0)271/20266 | fax: +49 (0)271/20758 |
mobile: +49(0)170/2813683 | Mail: Bernd....@gmx.net
Maxim S. Shatskih
> Vendor/Device ID
Do not do this. The hardware resources will be supplied for you in PnP
START IRP.
Then map the memory in IOCTL path.
Max
Tim Roberts
>
>does anyone know where I can find a sample driver with the following
>characteristics:
>
>OS: W2K
>BUS: PCI
>TODO: map dual ported physical RAM on the PCI card to user-space
>
>There has been a similar example for NT4.0 in the DDK called Mapmem,
>which seems to be no longer present in the W2K DDK.
The NT4.0 mapmem will still run in Win2K. You can download many variants
of it from the web; a Google search will prove fruitful.
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Maxim S. Shatskih
variants
> of it from the web; a Google search will prove fruitful.
If my experience on researching the innerworkings of VIDEOPRT is
correct, then MAPMEM uses the same technique which is used by DDraw to
map video surfaces to user space.
Max
Pat LaVarre
> Date: 2003-03-25 06:49:07 PST ...
> where I can find a sample driver ...
> OS: W2K
> BUS: PCI
> TODO: map ... the PCI card to user-space
Me too please!
> From: Maxim S. Shatskih (ma...@storagecraft.com)
> Do not do this.
I'm talking to the only sample of my hardware that exists on the
planet. Dos & Linux mmap work fine to give me a virtual base address
I use to talk slowly to the card. I'm looking for the Win XP
analogue.
> From: Tim Roberts (ti...@probo.com)
> Date: 2003-03-25 23:52:15 PST
> a Google search will prove fruitful
WHICH Google search!!! I've tried a number, for some weeks, and
clicked thru a few bum leads.
Anybody out there searching with me, can we make a pact? Whoever
finds it first, will post the answer here?
Thanks in advance, hope this helps, Pat LaVarre
Gary G. Little
Assumption here ... you have a driver that you will be using to "map" the
PCI base addresses to the user application, if you can ever figure out how
to map these little explitives to user space. Is this correct?
Silly question ... are you not blowing a lot of time trying to "map" IO base
addresses to user mode so your application can continue doing "inp/outp"
instead of simply implementing port read and write via an IOCTL call into
your driver? If you really insist on doing it this way ... look for PortIo,
memmap and GenIo. You should find one or more of them in the NT4 DDK.
--
Gary G. Little
Have Computer, Will Travel ...
909-698-3191
909-551-2105
http://www.wd-3.com
"Pat LaVarre" <ppa...@aol.com> wrote in message
news:2695edf1.03040...@posting.google.com...
Maxim S. Shatskih
> planet. Dos & Linux mmap work fine to give me a virtual base
address
> I use to talk slowly to the card. I'm looking for the Win XP
> analogue.
MmMapLockedPages(...UserMode...) in a driver, or open
\Device\PhysicalMemory by ZwOpenSection and then call
ZwMapViewOfSection.
Max
Pat LaVarre
> > OS: W2K
> > BUS: PCI
> > TODO: map ... the PCI card to user-space
>
> Date: 2003-04-03 10:59:08 PST ...
>
> doing it this way ...
> look for PortIo, memmap and GenIo.
Keywords!!! Thank you, I will pursue. Anybody got more/ newer?
> You should find one or more of them in the NT4 DDK.
I'm new to, and just part time in, the game of coding for Windows.
The web tells me Microsoft has taken its NT/ 2K/ XP DDK's off the
gratis web - untrue? If I go find someone - maybe myself - with a $$
MSDN subscription, does that person have a copy of the NT4 DDK,
whether they know it or not? Where? In what MSDN installation copied
to their HDD, or only back with the original CD/DVD's, wherever those
may be?
> ... instead of simply implementing port read and write
> via an IOCTL call into your driver?
I'm happy to do anything good & cheap & quick: I'm too ignorant to
forswear any option suggested without learning more.
From an app can I pass IOCTL thru driver to hardware with only the
gratis MinGW gcc? That would be easy. Or do I have to use the $$
MSVC? That would be tolerably easy, but not so very easy.
Is there a working example on the gratis web I can modify? Or in the
$$ MSDN distribution somewhere? That would be easy. Or do I have to
learn to build the structure, not just the substance?
> Assumption here ... you have a driver that you will
> be using to "map" the PCI base addresses to the
> user application, if you can ever figure out how ...
I think No? Is that nuts? Why would I want to learn to write a
driver? I have one sample of my target hardware, I don't plan to
build any more. I don't plan to teach anyone but myself to program
this hardware. I don't need real-time response. Why wouldn't I
prefer an app build environment (a la MSVC) with single-stepping,
Ctrl+Break, .dll's, scripting languages, GUI, etc. etc. etc.?
> if you can ever figure out how to map these little
> explitives to user space ... trying to "map" IO
> base addresses to user mode so your application
> can continue doing "inp/outp"
I think No? Is that nuts? On the web I'm told the x86 has a physical
address space of 4 GiB of "memory" and 64KiB of "i/o". I'm trying to
talk to "memory", not "i/o".
Incidentally, the "i/o" problem appears solved by the GIVEIO of DDJ:
http://www.ddj.com/ftp/1996/1996.05/directio.zip/README.TXT
Yes someday I might care. For Dos & Linux I've posted some tools for
tickling IDE hardware. My Dos tools I ran in Dos boxes of Win
95/98/ME: I'm happy to see DDJ make classic Debug I/O scripts work
again in Win NT/ 2K/ XP. And in Linux hitting i/o ports is again
standard API. But just now in Win XP I'm trying to talk to "memory",
not "i/o".
> Silly question ... are you not blowing a lot of time ...
I do think I must be missing something cultural, I would like to know
what that is.
Read/write physical address is standard API in Linux, yet deeply
hidden in Windows, as yet I'm too ignorant to begin to explain that
difference.
The time I'm blowing is the port to Windows from Linux. Me giving
that up would make some people unhappy. Maybe a direct port would be
too alien. Maybe Win culture demands that I restructure my code. I'm
not yet sure about that.
> > OS: W2K
> > BUS: PCI
> > TODO: map ... the PCI card to user-space
Anybody? The Linux analogue is merely:
int fd = open("/dev/mem", O_RDWR);
if (0 < fd) {
void * vo = mmap(
NULL, length, PROT_READ | PROT_WRITE,
MAP_FILE | MAP_SHARED, fd, offset);
volatile unsigned char * uchars = vo;
This gives me a virtual base address for the physical address offset
that works for length bytes. Simple. Easy. Totally unsafe.
> ... instead of simply implementing port read and write
> via an IOCTL call into your driver?
How does this idea qualify as "simple"? Linux is simple here. Google
gets snippet examples of API like that above. Cut, paste, edit,
compile, run, happy. That's maximally simple? Next most simple is a
worked example of adding inexplicably missing API to the O.S. - that's
what the original post of this thread requested. Does that not exist?
Thanks again in advance, Pat LaVarre
Pat LaVarre
> > base address I use to talk slowly to the
> > looking for the Win XP analogue.
>
>
> ... or open \Device\PhysicalMemory by ZwOpenSection
> and then call ZwMapViewOfSection.
Seemingly just the right keywords, thanks ... but I find my link fails
if I try to call ZwOpenSection?
Anybody have a clue why?
Just now I posted copies of my specific "error LNK2001: unresolved
external symbol" errors in a reply to:
http://groups.google.com/groups?as_umsgid=3E8CE249.2E89ADC3%40mindspring.nospam.com
Subject: Re: Physical memory access wanted
Date: 2003-04-03 17:39:27 PST From: James Antognini
(anto...@mindspring.nospam.com)
Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode
Cluelessly, curiously, thankfully yours, Pat LaVarre
Maxim S. Shatskih
> gratis MinGW gcc? That would be easy. Or do I have to use the $$
> MSVC?
Cheap DDK is enough. It contains the MSVC's compiler and the linker.
Apps can be built using any compiler you want, the drivers are not
guaranteed to work after this and require the MS's compiler.
> Incidentally, the "i/o" problem appears solved by the GIVEIO of DDJ:
> http://www.ddj.com/ftp/1996/1996.05/directio.zip/README.TXT
>
> Yes someday I might care. For Dos & Linux I've posted some tools
for
> tickling IDE hardware. My Dos tools I ran in Dos boxes of Win
> 95/98/ME: I'm happy to see DDJ make classic Debug I/O scripts work
And I'm very unhappy seeing this dirty software for free downloads
here and there. This software violates the system integrity, and thus
Windows _intentionally_ made it is more complex (and undocumented) to
write such software which can crash the machine with ease.
What is the need in tickling IDE hardware for a non-maniac user? IDE
works with MS's driver stack. It works fine, SMART is supported, and
you can send any arbitrary vendor-specific command to a CD drive. With
disks, the necessary command set is tiny - I/O and SMART, this is all.
> again in Win NT/ 2K/ XP. And in Linux hitting i/o ports is again
> standard API.
I hope it can be switched off, otherwise, the stability of Linux on
servers or machines used by groups is doubtful.
> Read/write physical address is standard API in Linux, yet deeply
> hidden in Windows,
Because _it is not necessary to develop anything useful_. For DMA, use
the DMA address translation routines which are provided and
documented.
> that works for length bytes. Simple. Easy. Totally unsafe.
You responded to yourself. Windows limits the number of ways of
writing unsafe code. That's all.
Max
Tim Roberts
>>
>> From: Maxim S. Shatskih (ma...@storagecraft.com):
>>
>> ... or open \Device\PhysicalMemory by ZwOpenSection
>> and then call ZwMapViewOfSection.
>
>Seemingly just the right keywords, thanks ... but I find my link fails
>if I try to call ZwOpenSection?
>
>Anybody have a clue why?
Are you actually writing a kernel driver, or are you hoping you can call
kernel APIs from a user-mode program?
ZwOpenSection is only available to kernel drivers.
Pat LaVarre
> Date: 2003-04-05 20:29:50 PST
...
> ZwOpenSection is only available to kernel drivers.
News to me, thanks for sharing.
> Are you actually writing a kernel driver
I hope not. Is that nuts?
> or are you hoping you can call kernel APIs from a
> user-mode program?
I'm hoping to find the user-mode API for read/write of a physical
address.
For example, when $$ SoftIce PCI (or gratis Linux cat /proc/pci) tells
me my custom-built one-off PCI card today is at address xD410.0000,
then I want to type xD410.0000 into a user app and speak slowly, but
interactively, with my card.
In Linux, from a user-app, without having written a kernel driver, I
call "open" to connect me with "/dev/mem" and then I call "mmap" to
get a virtual base address where in my user app I will find the region
of physical memory that interests me.
The contemporaneous thread "Re: Physical memory access wanted" tells
me next I will try "DefineDosDevice to give \Device\PhysicalMemory
some DOS-accessible name", "then OpenFileMapping on this name", "then
MapViewOfFile".
Nico Bendlin
> ZwOpenSection is only available to kernel drivers.
ZwOpenSection behaves like NtOpenSection if called
from user mode. In user mode app you typically link
with ntdll.dll instead of ntoskrnl.exe (but second
one works in user mode too (at least for now)).
--
codito, ergo sum :]
Maxim S. Shatskih
tells
Or gratis WinDbg's !pci
:-)
> In Linux, from a user-app, without having written a kernel driver, I
> call "open" to connect me with "/dev/mem" and then I call "mmap" to
This is not a major need for any production hardware anyway, and it
also violates the OS stability a lot.
Max
Pat LaVarre
This bait has not yet switched?
As yet, only the DDK costs money, not also WinDbg?
> not a major need
> for any production hardware anyway
Quite right, sorry I somehow sounded like I didn't know this.
I agree, letting me read/write physical addresses I name is just a small part
of what "having a /dev/mem" means.
Here now I'm by myself, in a lab, not in production, working with a
custom-built one-off PCI card that has memory-mapped i/o I wish to access.
I can connect with my card fine in Dos & Linux. But there I cannot run the
Microsoft Word/ Excel/ Outlook/ NetMeeting/ etc. etc. that my colleagues
pressure me to use in place of visibly different, less proprietary,
alternatives.
Pat LaVarre
Pat LaVarre
>
> > ZwOpenSection is only available to kernel drivers.
>
> Date: 2003-04-06 07:55:55 PST
>
> > ZwOpenSection behaves like NtOpenSection if
> > called from user mode. In user mode app you
> > typically link with ntdll.dll instead of
> > ntoskrnl.exe (but second one works in user mode
> > too (at least for now)).
Remember that sysinternals physmem we mentioned that does not work in Win XP?
http://www.sysinternals.com/tips.htm#KMem
links to physmem source that includes such fragments as:
NTSTATUS (__stdcall *NtOpenSection)(
OUT PHANDLE SectionHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes
);
...
if( !(NtOpenSection = (void *) GetProcAddress( GetModuleHandle("ntdll.dll"),
"NtOpenSection" )) ) {
...
Pat LaVarre
Nico Bendlin
> Remember that sysinternals physmem we mentioned that does not work in Win XP?
Yes, but Nt/ZwOpenSection does not fail.
This is IMHO the only 'native' funtion
you need. From that point on you can use
Win32 API functions on the section handle.
I use the following sequence in user mode
- NtOpenSection
- MapViewOfFile
- <get coffee>
- UnmapViewOfFile
- NtClose/CloseHandle
Phil Barila
> > Or gratis WinDbg's !pci :-)
>
> This bait has not yet switched?
>
> As yet, only the DDK costs money, not also WinDbg?
Only shipping cost, and not even that if you have MSDN subscription at OS
level or higher. DDK is effectively free.
> > not a major need
> > for any production hardware anyway
>
> Quite right, sorry I somehow sounded like I didn't know this.
>
> I agree, letting me read/write physical addresses I name is just a small
part
> of what "having a /dev/mem" means.
If you can do that in Linux, without needing root access, then Linux is no
more inherently secure or stable than DOS. And if you run Linux as root all
the time, you deserve whatever disasters happen to your systems.
> Here now I'm by myself, in a lab, not in production, working with a
> custom-built one-off PCI card that has memory-mapped i/o I wish to access.
You may be able to do what you want using the debug utility that ships with
all flavors of Windows.
> I can connect with my card fine in Dos & Linux. But there I cannot run
the
> Microsoft Word/ Excel/ Outlook/ NetMeeting/ etc. etc. that my colleagues
> pressure me to use in place of visibly different, less proprietary,
> alternatives.
But why are you trying to use one system for everything under the sun? If
you need to develop your hardware, use a dedicated system for it. Or, if
you prefer, use a dedicated system for Windows, and do your development on
something else.
Phil
--
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.
E-mail address is pointed at a domain squatter. Use reply-to instead.
Pat LaVarre
> Date: 2003-04-07 09:20:35 PST
Thanks for your interest.
> > Here now I'm by myself, in a lab, not in
> > production, working with a custom-built one-off
> > PCI card that has memory-mapped i/o I wish to
> > access.
>
> You may be able to do what you want using the debug
> utility that ships with all flavors of Windows.
Do you mean to say with C:\WINDOWS\system32\debug.exe
?
Really??? How?
> If you can do that in Linux,
> without needing root access,
There I use the `sudo` flavour of temporary root access, when I need
it. I of course prefer the `sudo chmod ...+rwx ...` flavour, whenever
that lesser privilege suffices.
> if you run Linux as root all the time,
I don't.
> But why are you trying to use one system for
> everything under the sun?
At the moment, I am getting by with a set of systems. In particular,
on one system I have Win XP SP1, and on a second system I have Knoppix
Linux 2.4 and a free PCI slot, on another system I have Mac OS X
10.2.4, and on and on the list goes.
But if I could read/write physical addresses from Windows, then via
NetMeeting on the x86 system with the free PCI slot I could show
people what I'm doing with my custom-built one-off PCI card as I do
it, rather than capturing a log and then describing in English how to
imagine the interactive experience that the log records.
Having Windows appear to work more often would just be convenient, not
earth-shattering.
> DDK is effectively free.
Possibly nearly gratis. Definitely not free. For example, I may not
give you a way to click thru to view:
/WINDDK/3615/src/storage/tools/spti/
Pat LaVarre
Phil Barila
> > From: Phil Barila (PBa...@Barila.com)
> > Date: 2003-04-07 09:20:35 PST
>
> Thanks for your interest.
>
> > > Here now I'm by myself, in a lab, not in
> > > production, working with a custom-built one-off
> > > PCI card that has memory-mapped i/o I wish to
> > > access.
> >
> > You may be able to do what you want using the debug
> > utility that ships with all flavors of Windows.
>
> Do you mean to say with C:\WINDOWS\system32\debug.exe
> ?
>
> Really??? How?
I'm not sure it will allow you to do this. It provides IN/OUT to ports, and
DUMP/WRITE to memory. If nothing else, if the port IO really works, you
should be able to setup the card, then DUMP/WRITE to your card's memory
range.
> > DDK is effectively free.
>
> Possibly nearly gratis. Definitely not free. For example, I may not
> give you a way to click thru to view:
> /WINDDK/3615/src/storage/tools/spti/
Free as in beer, not speech.
Pat LaVarre
> > that does not work in Win XP?
>
> Date: 2003-04-07 00:05:01 PST ...
>
> Nt/ZwOpenSection does not fail.
> This is IMHO the only 'native' funtion
> you need. From that point on you can use
> Win32 API functions on the section handle.
> I use the following sequence in user mode
> - NtOpenSection
> - MapViewOfFile
> - <get coffee>
> - UnmapViewOfFile
> - NtClose/CloseHandle
Do you mean to say you have read & written the physical address of
memory-mapped i/o in Win XP SP1 this way?
Pat LaVarre
P.S. I'm asking just because I'm curious. I'll try anyhow. I
hesitated to try this, only because physmem tries something so much
like this. I wonder if and how my try in ignorance can work better
than what physmem tries. But now I have to try, since the
"MapViewOfFile of OpenFileMapping of DefineDosDevice of
\Device\PhysicalMemory" from Maxim S doesn't just work.
Nico Bendlin
> Do you mean to say you have read & written the physical address of
> memory-mapped i/o in Win XP SP1 this way?
I use it to read ROM-BIOS (SMBIOS informations)
on WinNT to avoid using 16-bit code for dumping.
- nico
Pat LaVarre
> This is IMHO the only 'native' funtion
> I use the following sequence in user mode
> - NtOpenSection
> - MapViewOfFile
> - <get coffee>
> - UnmapViewOfFile
> - NtClose/CloseHandle
I'm not sure how literally I should be reading this quotation. For my
first try:
I'm using GetProcAddress to link with ZwOpenSection, ZwClose, and
RtlInitUnicodeString.
Either that's close enough, or I have misunderstood, so I'm posting in
hope of correction. In support of the idea of substituting Zw for Nt
I find Zw in the $$ Win DDK help, but I find Nt nowhere, in particular
not in the $$ MSDN help. But what then persuaded me was that here,
after a LoadLibrary of "NTDLL", GetProcAddress of "NtOpenSection"
gives me the same result as a GetProcAddress of "ZwOpenSection".
Similarly, GetProcAddress of "NtClose" equals that of "ZwClose".
Is all this too painfully naive of me for words, or correct, or ...?
Pat LaVarre
Pat LaVarre
> Date: 2003-04-07 00:05:01 PST ...
>
> - NtOpenSection
> - MapViewOfFile
> - <get coffee>
> - UnmapViewOfFile
> - NtClose/CloseHandle
RtlInitUnicodeString ZwOpenSection ZwClose works for me, as in the
broken sysinternals physmem.
My MapViewOfFile chokes via x57 (87) "The parameter is incorrect."
I see the symbols ZwMapViewOfSection and ZwUnmapViewOfSection also
appear in C:\Windows\System32\ntdll.dll
I'll try those next. But I see physmem has gone there before me ...
Pat LaVarre
Nico Bendlin
> I find Zw in the $$ Win DDK help, but I find Nt nowhere, in particular
> not in the $$ MSDN help.
Typically:
ZwXxx is used from kernel mode (ntoskrnl.exe).
NtXxx is used from user mode (ntdll.dll).
Drivers and Win32 appilications are using two
different APIs - and you cannot mix them.
Think about ntdll.dll as an user mode layer
which mapps Win32 APIs to kernel calls.
Generally speaking: NtXxx does security checks
while ZwXxx does not (no needing/sense for KM).
In practice, ZwXxx and NtXxx of ntdll.dll point
to the same address. So the function looks up
if the callee is running in KM or UM.
(not every ZwXxx has an NtXxx counter part and
vice versa - and not every Nt/ZwXxx can be
found in ntdll.dll and ntoskrnl.exe).
-
Therefore you'll find always ZwXxx in the DDK.
Your problems result from the fact, that you
need to open an named object which you cannot
open with Win32 API functions. Therefore you
have to use the NT-Layer (ntddl.dll) directly.
(but it is not easy to compile an Win32 app
with headers from the DDK - esp. with the
current Windows DDK)
For the rest you can proceed with Win32 API.
-
The best solution would be to write an driver
which acesses your hardware. And writing an
interface to an Win32 application for it.
But for now (testing) copying some DDK types
and GetProcAddress() should do the thing...
- nico
Pat LaVarre
> > > > production, working with a custom-built one-off
> > > > PCI card that has memory-mapped i/o I wish to
> > > > access.
> > >
> > > You may be able to do what you want using the debug
> > > utility that ships with all flavors of Windows.
> >
> > Do you mean to say with C:\WINDOWS\system32\debug.exe
> >
> From: Phil Barila (PBa...@Barila.com)
> Date: 2003-04-07 16:43:46 PST
>
> I'm not sure it will allow you to do this.
Fun question, thanks again.
> It provides IN/OUT to ports, and DUMP/WRITE to
> memory.
Debug claims to i from x0000..FFFF yes.
Debug claims to o to x0000..FFFF yes.
But d and w access some kind of virtual Dos box address numbered
x00:0000 ... xFF:FFFF. What I'm lacking is a way to map 64KiB of
those addresses to the physical addresses xD410:0000..D410:FFFF that
in Linux are the memory-mapped i/o of my one-off custom-built PCI
card.
> If nothing else, if the port IO really works, you
> should be able to setup the card, then DUMP/WRITE
> to your card's memory range.
I agree I SHOULD be able to do this. I agree I COULD do this in the
Dos/Win days of ISA. But I think noone among us knows how to let me
do this again now, in Win XP.
Pat LaVarre
Pat LaVarre
> From: Alexander Grigoriev (al...@earthlink.net)
> Date: 2003-04-09 07:15:53 PST
...
> Just write a driver, using MmMapIoSpace. It would
> take less time that the whole investigation about
> \Device\PhysicalMemory.
This theory we can test, thank you. This thread began with Bernd
Hofner on 25 March, but for the sake of argument we can agree to
restart the clock now.
I agree the DDK help for MmMapIoSpace says that we want to appear to
have called MmMapIoSpace from our user app.
How now do we write a driver that lets our user app appear to have
done this? Where can we find a mostly working example to modify
slightly?
> Just write a driver,
These words sound crazy to me. I conclude we're in culture conflict:
here now my Dos/ Linux/ other background distorts my perspective too
much for me to properly understand Windows English.
I haven't heard anyone clearly tell me it's easy for me to go write my
own /dev/mem for Windows.
Is it?
What I've heard instead is that I shouldn't want to be using /dev/mem,
that I should go write a driver for each new card I build, according
to how that card plugs 'n plays. And if & when I have two or more
cards, I should learn how to sort them out.
To me, that sounds crazy. For what it's worth, I'm not alone here.
http://www.google.com/search?q=%2Fdev%2Fmem+%2Fdev%2Fkmem
In that Google cache, we have Apple:
"One particularly painful surprise to people doing security
programming in most UNIX or UNIX-like environments is the existence of
/dev/mem and /dev/kmem. These device files allow the root user to
arbitrarily access the contents of physical memory and kernel memory,
respectively. There is absolutely nothing you can do to prevent this.
From a kernel perspective, root is omnipresent and omniscient. If this
is a security concern for your program, then you should consider
whether your program should be used on a system controlled by someone
else and take the necessary precautions.
http://nscp.upenn.edu/aix4.3html/files/aixfiles/mem.htm
More live, we have U Penn on IBM:
"Attention: When incorrect access to virtual memory is made through
these files, process termination, a system crash, or loss of system
data integrity can result.
"Note: Programs accessing these special files must have appropriate
privilege. Commercial application programs should avoid using the
/dev/mem and /dev/kmem files, since the virtual memory image is quite
specific to the operating system level and machine platform. Use of
these special files thus seriously affects the portability of the
application program to other systems.
"Note: ... ,address space layout can vary on other machine platforms
and versions of the operating system.
"Attention: Use of this special file by application programs should be
strictly avoided, as it is provided for diagnostic and problem
determination procedures only.
I understand all that. I don't understand how I am persistently
appearing not to understand that.
I just mean to be asking for the shortest route to finding /dev/mem in
Windows. Preferably a route I can compile into MinGW gcc, though for
me personally a $$ MSVC route would be good enough for now.
Pat LaVarre
Alexander Grigoriev
an user application (even under administrator) to crash a system (this is
also why there is no direct dev/mem equivalent in Windows), here are a few
hints:
1. Get any driver template from DDK. Some driver that just creates a named
DEVICE_OBJECT with a symbolic link.
2. Add or modify its DeviceIoControl handler, to handle the following kinds
of control codes:
a) read physical memory beyond RAM: do MmMapIoSpace, read the memory into
the user buffer, MmUnmapIoSpace;
b) write physical memory beyond RAM: do MmMapIoSpace, write the memory from
the user buffer, MmUnmapIoSpace;
c) map an area to the user space: ask Max Shatsky about that. Pend the IRP
after you've mapped the memory. Provide another IOCTL code to cancel that
pending IRP. This way the mapping will be correctly closed when your
application terminates without explicitly unmapping that memory.
The IOCTL codes are defined with CTL_CODE macro. Function Code compopent of
it can be choosen arbitrary.
"Pat LaVarre" <ppa...@aol.com> wrote in message
news:2695edf1.03040...@posting.google.com...
Pat LaVarre
> > to finding /dev/mem in Windows ...
>
> From: Alexander Grigoriev (al...@earthlink.net)
> Date: 2003-04-09 15:05:35 PST ...
>
> to write a driver which allows ...
> hints: ...
>
> 1. Get any driver template from DDK. Some driver
> that just creates a named DEVICE_OBJECT
> with a symbolic link.
>
Can anyone recommend a specific template? As a newbie, I'll look at
the first template I find, the second, and so on til I choose one. I
imagine that algorithm is unlikely to yield the best choice.
> Pend the IRP ... the mapping will be correctly closed
> when your application terminates without explicitly ...
Sensible, aye.
Pat LaVarre
Maxim S. Shatskih
> while ZwXxx does not (no needing/sense for KM).
A bit more complex.
In user-mode NTDLL.DLL, both are the same.
In the kernel itself, Ntxxx functions - not intended to be callable
from drivers - are direct syscall bodies. Zwxxx, on the other hand,
use the same syscall sequence as user-mode syscalls to access the
Ntxxx functions.
The result is that, if you call Zwxxx from a driver, then the syscall
path will have ExGetPreviousMode() == KernelMode.
If you would call Ntxxx (not documented and recommended), then the
syscall path will have ExGetPreviousMode() == your old previous mode
of the code which called Ntxxx.
Then ExGetPreviousMode() is used to do security checks, most are
skipped if it is KernelMode. Also note that IO subsystem puts this
value to Irp->RequestorMode, for use by FSDs and drivers.
Usually, Irp->RequestorMode is connected to the fact whether
Irp->UserBuffer is a kernel or user space pointer. If
Irp->RequestorMode is UserMode, then Irp->UserBuffer is a user-space
pointer, which was checked in Ntxxx code while creating an IRP.
Otherwise, Irp->UserBuffer can be any pointer.
Max