Re: Executable Memory in a Driver

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Ray Trent (ratrent_at_nospam.nospam)
Date: 02/11/05 

Date: Fri, 11 Feb 2005 15:47:17 -0800

Well, I'm not denying that *some day* it might become possible to safely
use a managed language in an NT-derived OS.

But for the moment, how about these:

Almost all the memory you typically allocate in a WDM kernel driver is
sitting in places that are tracked by the OS as pointers (e.g. your
device extension), or is sitting on the stack. These can't be garbage
collected without disaster (and must be allocated in NPP, mostly), so
you lose a majority of the benefit of the language being managed in the
first place, at the expense of a ludicrous amount of complexity.

Also, I'm a bit concerned that since you'd have to make all managed
memory non-pagable, that you'd have to run the GC quite frequently in
order to avoid unnecessary hogging of this precious resource (not to
mention the even more precious kernel stack). That has it's own problems
in any setting, but for a majority of drivers a timing uncertainty of
that magnitude could be problematic.

Also, I don't know of any managed languages that are currently as robust
as C or even C++ in terms of their compiler/interpreter implementation.
That will change eventually, of course, but in the mean time it would be
criminal to expose users to the added bluescreen and security risk.

Also, almost all of the problems that plague C++ in kernel mode apply
double to a managed language.

If you interpret the byte-code, it will be dog slow. If you JIT it,
you're opening up a whole can of security holes by requiring that much
of the memory used by driver images has to be (at least for a while)
both writable and executable. Any bugs in the entire interpreter/JIT
compiler now become kernel vulnerabilities. So you're going to end up
statically compiling and linking it anyway, which removes the
opportunities that many of these languages have to make your life easier
by using dynamic code.

If I cared to spend the time, I could probably come up with another
dozen (but probably not 2 dozen... it's not *that* bad an idea :-).

Tim Roberts wrote:
> Ray Trent <ratrent@nospam.nospam> wrote:
>
>>I was including JIT in the phrase "self-modifying code", and no, I don't
>>think it's a good idea to use any of the byte-code languages in the
>>kernel for reasons too numerous to list.
>
>
> I, personally, would like to have you enumerate some of those reasons.
>
> I don't think I would ever find myself doing it, but it seems to me that a
> .NET-type solution has some real advantages for kernel mode. Managed code
> can be made more predictable and secure than unmanaged code.
>
> You'd need the approprate (and well-optimized) run-time library support,
> but I certainly see no major obstacles to it, and I can't really see any
> philosophical objections.
>
> It might actually provide the path to actual Microsoft-supported
> class-oriented programming in the kernel. 

-- 
../ray\..