The DDK specifies that some operations are restricted to highest-level
drivers only. Such as safely waiting on dispatcher objects. Ok, this makes a
lot of sense.

But how a driver can guarantee it is in effect the highest-level driver?
Assume, I just want to assert this at run time, will ExGetPreviousMode do the
trick?

Re: Assert being the highest-level driver by Doron

Doron
Thu Aug 11 01:48:24 CDT 2005

you can't reliably do this. you have to take it on faith that if the design
of your stack is that you are the highest level driver, you are the highest.
if a driver attaches above, it is the duty of the attaching driver not to
violate the contract regarding changing of contexts or other things that
make the stack work.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"ijor" <ijor@nospam.nospam> wrote in message
news:CCE6EC2F-3F94-4A20-AF7F-FAD8A6389023@microsoft.com...
> The DDK specifies that some operations are restricted to highest-level
> drivers only. Such as safely waiting on dispatcher objects. Ok, this makes
> a
> lot of sense.
>
> But how a driver can guarantee it is in effect the highest-level driver?
> Assume, I just want to assert this at run time, will ExGetPreviousMode do
> the
> trick?
>



Re: Assert being the highest-level driver by Doron

Doron
Thu Aug 11 09:48:06 CDT 2005

you should also note that all microsoft provided samples which assume that
they are the highest level driver actually assert this state, it is just
assumed.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
news:%23YOktCknFHA.3564@tk2msftngp13.phx.gbl...
> you can't reliably do this. you have to take it on faith that if the
> design of your stack is that you are the highest level driver, you are the
> highest. if a driver attaches above, it is the duty of the attaching
> driver not to violate the contract regarding changing of contexts or other
> things that make the stack work.
>
> d
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
> "ijor" <ijor@nospam.nospam> wrote in message
> news:CCE6EC2F-3F94-4A20-AF7F-FAD8A6389023@microsoft.com...
>> The DDK specifies that some operations are restricted to highest-level
>> drivers only. Such as safely waiting on dispatcher objects. Ok, this
>> makes a
>> lot of sense.
>>
>> But how a driver can guarantee it is in effect the highest-level driver?
>> Assume, I just want to assert this at run time, will ExGetPreviousMode do
>> the
>> trick?
>>
>
>



Re: Assert being the highest-level driver by ijor

ijor
Thu Aug 11 10:20:15 CDT 2005

"Doron Holan [MS]" wrote:

> you can't reliably do this. you have to take it on faith that if the design
> of your stack is that you are the highest level driver, you are the highest.

I see, thanks.

But just for my knowledge, what is exactly the meaning of "previous" in
ExGetPreviousMode? The concept is a bit loose in this context.


Re: Assert being the highest-level driver by Maxim

Maxim
Thu Aug 11 20:12:40 CDT 2005

> But just for my knowledge, what is exactly the meaning of "previous" in
> ExGetPreviousMode? The concept is a bit loose in this context.

The mode in which the processor was running before entering the current code
via syscall.

You see - any thread running inside the kernel is either a) system thread, for
which ExGetPreviousMode() == KernelMode and b) user process's thread, which
originated in user mode and entered the kernel code via syscall, page fault or
such.

In this latter case usually ExGetPreviousMode() == UserMode.

But! Note that Windows allows kernel syscalls - i.e. re-entering the kernel
recursively from the kernel mode code by one of the ZwXxx routines, which
generate the trap. Also Windows kernel is partly pageable - can do page faults.

So, in the kernel page fault path, and in the kernel syscall path,
ExGetPreviousMode() == KernelMode.

The practical sense of it is that the kernel syscall caller can specify
kernel-mode pointers and kernel handles to the call, while user mode code
cannot. So, your validation code (if any - most usual IO syscall arguments are
validated by the IO manager itself, but not all - for instance, pointers and
handles inside the IOCTL input buffer are not validated, and your code must do
it itself) must notice this previous mode.

If ExGetPreviousMode() == KernelMode, then you must do NOT do any pointer
validation, and pass KernelMode to MmProbeAndLockPages if you lock this
pointer.

Otherwise, you must do ProbeForRead/Write, and pass UserMode to
MmProbeAndLockPages.

As about the handle validation - pass ExGetPreviousMode result to
ObReferenceObjectByHandle.

Note that in any IRP handling contexts, you must use Irp->RequestorMode instead
of ExGetPreviousMode. It is assigned as:

Irp->RequestorMode = ExGetPreviousMode();

in NtXxxFile functions where the IRP is created.

So, the whole song is - to provide the ability for kernel modules to notice and
reject the case when a user mode code is passing a kernel space pointer to the
syscall. This must be rejected, while the same thing for a kernel mode caller -
must not.

Internally, ExGetPreviousMode is implemented by finding the last trap frame on
the kernel stack and examining the CS segment selector - whether it is
KERNEL_CS constant or USER_CS.

The notion of previous mode is very old, predates Windows at all and is
originated at PDP-11 and RSX-11 OS - later migrated to VAX and VMS (which looks
like direct descendant of RSX-11) without any significant changes. These CPUs
supported this value as hardware flags in the flag register (x86 only exposes
current mode this way, not previous mode).

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com



Re: Assert being the highest-level driver by ijor

ijor
Thu Aug 11 23:38:03 CDT 2005


"Maxim S. Shatskih" wrote:

> > But just for my knowledge, what is exactly the meaning of "previous" in
> > ExGetPreviousMode? The concept is a bit loose in this context.
>
> The mode in which the processor was running before entering the current code
> via syscall.

Hi Max,

Thanks a lot for a very detailed explanation. But I still don't see how this
could be used reliably. See my reply to Peter.


Re: Assert being the highest-level driver by Maxim

Maxim
Fri Aug 12 04:53:11 CDT 2005

Previous mode is a thread's attribute, not the global one and not the CPU's
one.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"ijor" <ijor@nospam.nospam> wrote in message
news:59FB0836-9859-44A1-8A18-626318535930@microsoft.com...
>
> "Maxim S. Shatskih" wrote:
>
> > > But just for my knowledge, what is exactly the meaning of "previous" in
> > > ExGetPreviousMode? The concept is a bit loose in this context.
> >
> > The mode in which the processor was running before entering the current
code
> > via syscall.
>
> Hi Max,
>
> Thanks a lot for a very detailed explanation. But I still don't see how this
> could be used reliably. See my reply to Peter.
>