Walter Oney’s book is OK.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
“Cathal Mullaney” wrote in message
news:xxxxx@ntdev…
> Hi Arlie,
> Can you recommend a book on Driver development in Windows for absolute
> beginners? There are a lot out on the market but if you could recommend one
> in particular I’d be very grateful.
>
> Kind Regards,
> Cathal Mullaney
>
> (PS Sorry for not posting to the ntdev list with this query, hope that is
> alright.)
>
> On 10/14/06, Arlie Davis wrote:
> >
> > There are a lot of serious problems associated with passing user-mode
> > pointers into kernel-mode components. And these problems apply to nearly
> > all current OS platforms, not just NT.
> >
> > First, consider all the potential problems that would exist if user-mode
> > processes simply passed pointers to kernel-mode drivers. Every kernel-mode
> > driver would have to implement its own buffer verification – which means
> > that 95% of them would either not do it at all, or would simply get it
> > wrong. The Windows kernel simplifies this by allocating kernel memory
> > (pool) for each I/O control request, if the request is marked “buffered”,
> > and handles shuttling data back and forth. The kernel handles validating
> > addresses and buffer bounds, copying the data, freeing the memory,
> > etc. This allows device-driver developers to focus on the logic of the
> > device, not the details of getting memory safety & security correct. And
> > before you complain that it’s slow – it isn’t, in most cases, or at least
> > it is far from the bottleneck in most driver designs.
> >
> > And when it is too slow, your driver can choose to use either “direct”
> > memory access, which uses Memory Descriptor Lists (MDLs) to lock down and
> > identify user-mode buffers, or it can use totally raw user-mode
> > pointers. MDLs are structures that the kernel uses to describe locked-down
> > user-mode buffers; the most common use for MDLs is to set up DMA transfers
> > with drivers. (MDLs contain the locked-down physical page addresses of the
> > virtual range.)
> >
> > Raw user-mode pointers are the most dangerous and difficult transfer mode
> > to get right, and they should only be used in situations where you have
> > proved to yourself that the performance of the buffered and direct
solutions
> > is inadequate.
> >
> > Consider all those problems, all over again, when dealing with user-mode
> > memory that itself contains pointers. The driver must handle locking down
> > and validating every pointer that it deals with. And just because the
> > driver read value V1 at time T1, doesn’t mean that the driver can’t read
> > value V2 at time T2 from the same location. This provides a huge hole for
> > security exploits coming from user-mode components, unless the driver
> > developer is extremely cautious, experienced, and willing to spend (waste?)
> > time on this topic.
> >
> > In general, you should work hard to avoid such designs – they are
> > excruciatingly difficult to get right. In every single case that I’ve
seen,
> > the better design was to consider what data you wanted to move from the app
> > to the driver, and from the driver to the app, and to design a serialized
> > data format that fits in the InputBuffer and OutputBuffer arguments of the
> > DeviceIoControl call. Also, instead of using pointers, use integer offsets
> > within the buffer.
> >
> > Another problem with exchanging pointers between driver and app occurs
> > when you consider 64-bit platforms. On 64-bit platforms, drivers must be
> > 64-bit; the kernel will simply not load 32-bit drivers. But the OS
supports
> > both 32-bit and 64-bit apps. There’s a lot of jiggery-pokery behind the
> > scenes to make this work, and luckily your driver can ignore the difference
> > 99% of the time. But if you’re passing pointers between your driver and
> > app, you do have to deal with it, and it’s never fun.
> >
> > Yet another problem is dealing with user-mode addresses in device drivers,
> > when the device driver code is running in an arbitrary thread/process
> > context. There was just a big discussion here about what “arbitrary”
> > means. The short explanation is that, during certain code paths, your
> > driver code is not guaranteed to be running in the same process as it was
> > when a request started. Since a different process may be loaded, the
> > interpretation of a user-mode pointer means something totally different.
So
> > dereferencing that pointer can get you into some big trouble.
> >
> > Correctness and security are very difficult to get right if your driver is
> > dealing with user-mode addresses. I’m not saying it can’t be done, but
it’s
> > especially difficult to get right for people who are new to developing
> > drivers on a new platform, and that’s true regardless of which platform
> > you’re dealing with. And there’s usually not even a good reason to do
> > it. The only reason that consistently comes up is performance, and until
> > you’ve measured and proved that buffered I/O or direct I/O is your
> > bottleneck, you’ve probably got bigger perf problems elsewhere.
> >
> > If you want to learn more about this, there are a lot of “Intro to Windows
> > Drivers” type books on the market. They might not focus specifically on
> > this detail, but with some reading, and serious thinking, you can prove to
> > yourself how dangerous user-mode pointers are.
> >
> >
> >
> > ________________________________
> > From: xxxxx@lists.osr.com [xxxxx@lists.osr.com]
> > On Behalf Of xxxxx@lists.osr.com [
> > xxxxx@lists.osr.com]
> > Sent: Saturday, October 14, 2006 9:27 AM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Address translation from user mode to kernel mode (via
> > deviceiocontrol).
> >
> > Hi Everyone,
> > When I pass the address of a variable through a DeviceIOControl input
> > or putput parameter the address of the variable seems to be changed to
point
> > within kernel space. Is this correct? Why is this necessary? I’ve noticed
> > this with ordinary variables and with double pointers, when double pointers
> > are passed through DeviceIOControl they seem to become unuseable, the
memory
> > the array of pointers is pointing to does not seem to be allocated anymore.
> > Can someone explain what is happening or maybe point(!) me to appropriate
> > reading on the subject? I’ve looked through ddk docs but haven’t found
> > anything yet.
> >
> > Thanks everyone.
> > — 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
> >
>