Re: Device Driver that uploads it's own code?
- From: "Don Burn" <burn@xxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 3 Jun 2008 19:37:28 -0400
Well you can't measure non-determinism since you can run fine for a long
time then get hit. The real problem with your idea is you are destroying
security for Windows, it might as well be DOS if you allow an application to
download the code. And of course your application has to get everything
right in a dynamic load situation, where you will need to use
MmGetSystemRoutineAddress to resolve every call, meaning of course you can't
use any kernel mode DLL's with your driver.
Sorry in my opinion you are doing a ton of work, will get nothing out of it,
and of course along the way make any system that has this thing on it less
secure than DOS 1.0.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"respect privacy" <respect__privacy@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:Fgi1k.3758$C12.3205@xxxxxxxxxxxx
Thanks to make this clear !
To provide the "more info" as requested...
Suppose the driver needs to handle detection of different bit/byte
sequences and/or timing sequences and in doing so it's expected to
respond/interact with hardware with microsecond precision. But the
detection of these situations, and the details of the exact response,
changes on-the-fly. Because of the high-speed timing response required,
this has to happen right within the driver itself, if I'm not mistaken...
though I find it hard to get anyone to commit some actual numbers as to
what actual microseconds it takes to switch between KernalMode and
UserMode? My background being hardware design, which tends to be more
real-time and linear, the idea of fluctuating state and variable latency
is sometimes a bit foreign to me.
Not sure if you have Electronics and/or Process Controller experience but
a common control loop might implement what's called PID (proportional,
integral, differential) where the mathematical calculations to tune the
control loop change dynamically, so that the control loop can be adjusted
manually or even automatically adaptive. Yes, traditionally this is done
in separate external hardware, where the connection to Windows is largely
only for GUI purposes. However, with recent advances in CPU speed and
processing throughput, it's becoming attractive (cost savings potential)
to do this right on the Windows platform, with minimal external hardware.
If my UserMode application could interpret high-level math commads (making
it user friendly) and boil these down to raw assembler code, then upload
to the KernalMode driver for direct execution... it would be a very
flexible system. So if all the code did was make bit shifts,
add/subtracts, logical operations, conditional branches....would it be ok
to upload and run it KernalMode, on-the-fly? It's the same CPU and OP
Codes, right?
To ease security concerns, uploaded code could be scanned/blocked from
making any kernal, i/o, memory calls or interactions outside the context
of the driver and the I/O port it uses. In fact, because the raw code is
generated from a high-level language the the user works from, it simply
won't contain instructions other than directly to the driver's operation
itself.
Looking at it from a bigger picture, I'd essentially like to fake-out or
approach near Real-Time performance for simple applications running on
Windows XP, and completely bypass the need for expensive Real-Time
extensions such as RTX from Ardence, or InTime from Tenasys. The terms
Soft Real-Time versus Hard Real-Time come to mind in this case.
People keep circulating opinions like Windows is non-deterministic by
default and should NEVER be used for Real-Time control without a Real-Time
extension (or switch to Windows CE is another option). I'll accept that
wise warning, but what I don't accept is that no where will anyone provide
practical bench-mark tested hard numbers as to how bad the
non-deterministic behavior actually is. Many process control situations
are very tolerate of the odd random delay imperfection in small
millisecond range, if it only happens less than 1% of the time.
Presented with the #1 most popular hardware/software platform, a PC
running Windows XP, it's very unpleasant to always be told by the so
called experts... you can't, you shouldn't, it's not good to, ....when
clearly the CPU has the performance capability to meet the required
duties, without expensive separate Hardware/Software always being
required.
;-) I await the flames....
___
~RP
"Volodymyr M. Shcherbyna" <v_scherbina@xxxxxxxxxxxxxxx> wrote in message
news:ew#nA$ZxIHA.5892@xxxxxxxxxxxxxxxxxxxxxxx
Anyway, if you need dynamically extend functionality of your application,
look into direction of plugin based system. You can have plugins of both
types: user mode and kernel mode. If you design a well interfaces, the
whole system might be powerful in terms of extensibility.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Volodymyr M. Shcherbyna" <v_scherbina@xxxxxxxxxxxxxxx> wrote in message
news:eMAeO8ZxIHA.4952@xxxxxxxxxxxxxxxxxxxxxxx
[...]
Is it possible to have only the outer skeleton of a device driver,
where the inner code logic is uploaded at runtime from the users own
application that uses the driver?
Yes. It is possible, but the code you pass from user mode is just unable
to be run in kernel mode without special preprocessings. The problem is
that user mode code usually calls some functions, which are not present
in kernel mode.So you need to pass a simplest code which does not rely
on api, or preprocess the code, so that the offsets to import functions
point to the simular or the same procedure in kernel mode (this task is
complex).
I'd like to give UserMode applications full control/configuration and
runtime alteration of the driver's behavior. For example, if the
driver must deal with complicated timing and sequencing issues on
real-time in/out data streams, and those issues are not know until
runtime or might even change during the application's runtime, how else
can that be coped with? Seem impractical to have a library of 1,000's
of slightly different device drivers and always be unloading reloading
different drivers to accommodate different functionality that changes
on-the-fly. Or to have a mega-driver with millions of different code
branches to account for all possible combinations.
[...]
Well, believe me, kernel mode programming is not an easy thing. Its
better to use decomposition approach: devide task into small sub tasks,
which are solved by appropriate module (driver).
Maybe this is what is meant by UserMode driver? I'm still not clear on
difference between a KernalMode and UserMode driver, and under which
situations I would use either one, and their respective advantages
disadvantages.
It depends on what you are trying to accomplish. Give us more info.
Is there some kind of digital signature that's within all .SYS files,
which is tested for validity before it's allowed to load or run?
If so, is there a "hack" workaround to get past such limitations?
You have to sign binaries in x64 version of Vista and further OS. Why
would you need to hack it?
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
.
- References:
- Device Driver that uploads it's own code?
- From: respect privacy
- Re: Device Driver that uploads it's own code?
- From: Volodymyr M. Shcherbyna
- Re: Device Driver that uploads it's own code?
- From: Volodymyr M. Shcherbyna
- Re: Device Driver that uploads it's own code?
- From: respect privacy
- Device Driver that uploads it's own code?
- Prev by Date: Re: Device Driver that uploads it's own code?
- Next by Date: Re: Device Driver that uploads it's own code?
- Previous by thread: Re: Device Driver that uploads it's own code?
- Next by thread: Re: Device Driver that uploads it's own code?
- Index(es):
Relevant Pages
|
