I don’t know if I catch the gist of your reasoning, but a device driver
should be the bottom layer of the onion peel, and there’s a mass of OS code
in between the app and the driver. If a problem in an app, such as a
dangling pointer, is passed all the way down to the driver, the problem is
in the intervening layers: IMO “defensive programming” here means, heck, we
can’t trust the input the OS gives us, therefore we have to armor our car in
case they ws rocket propelled grenades at us. Is it ok to write a driver as
if we were a platoon commander in Iraq ?
Somehow I don’t think this is the right way of doing business. A device
driver, by its very position in the hierarchy, should not have to worry
about bad input, small stacks, or anything of that sort. After all, that’s
why it’s trusted code, no ?
And the architecture has a failsafe mechanism to contain dangling pointers,
it’s called “segments”. It’d be a simple matter to wrap every I/O buffer and
driver-accessible data packet in a segment, and you’d not need to worry
about corrupting other people’s buffers.
Use the architecture, dude…
Alberto.
-----Original Message-----
From: Loren Wilton [mailto:xxxxx@earthlink.net]
Sent: Wednesday, July 16, 2003 12:58 AM
To: Windows System Software Developers Interest List
Subject: [ntdev] Re: how can i handle string operation in kernel mini
driver?
It all depends on if you can trust your input. Same as any other kernel
code.
Sure. And The Answer in kernel mode is that You Can’t.
Which could explain why a whole lotta MS Kernel routines start with _try,
and those that can’t either know they will take out the user program only,
or carefully check their inputs by hand before using them. And still get
burned sometimes.
Kernel mode (or OS interfaces in general) are somewhat unique in that it is
very very rare that one programmer and one programmer only has absolute
control of both sides of an interface. Any interface. Even if there is a
spec on what is to be provided to an interface (or *back from* an
interface), you can’t trust that *everyone* will *always* get it right. So
you have to practice Defensive Programming if you expect your code and the
OS to survive.
Blowing up in a call from a bad pointer dereference is bad enough. But if
you manage to trash a bunch of global data (or worse, code) do to a runaway
data transfer in the process, *really* bad things can happen, which in a lot
cases can be virtually irrecoverable,even with a reboot. And the bad thing
is that while you know quickly when you fumble a bad pointer and die, you
may not have any immediate indication at all that you trashed data outside a
buffer range. Someone else might find that out, three days from now.
Loren
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.