0

I'm learning about writing kernel-mode code. I keep seeing this notion of system stability being fragile in this mode of operation. I'm looking for a low level explanation of why that is.

I understand some ways code running in kernel mode code could certainly cause problems:

  • kernel-mode code can write to any memory address, which might include corrupting memory used by a user-mode process
  • or even modify memory relied on by the kernel to perform critical tasks.
  • can communicate directly with hardware (which is just another feature of memory access)

But these seem like things one could avoid by simply allocating a safe memory space to work in, and generally not writing over any memory allocated to another process unless the process is specifically designed to share this memory.

I'll reference something I just read in the Windows documentation:

Important A driver should not allocate memory "on the side" and use it as a kernel-mode stack. This has never been a recommended practice for any platform, because it affects the stability and reliability of the operating system. On x64-based systems, if the operating system detects an unauthorized kernel-mode stack, it will generate a bug check and shut down the system. - Guidelines for using the kernel-mode stack

Why is this the case?

Can a driver not simply allocate some unused memory which the rest of the system will know not to use?

J.Todd
  • 707
  • 1
  • 12
  • 34
  • 2
    Allocating memory is fine, the warning is highly specific to a driver setting up its own stack. Stack overflows are very nasty, they named a popular programmers' web site after it. It would allow a userland program to crash the kernel rather easily, the kernel can do something about it when it created the stack itself and knows its limits. – Hans Passant Sep 01 '21 at 21:18

1 Answers1

0

Allocating memory in kernel (on heap) is common practice, there are a lot of functions to do that.

if you need to use big size data, it is recommended you allocate memory in the right pool and not use variables on stack.

Baget
  • 3,318
  • 1
  • 24
  • 44