It changes back when the system call returns. Another system call made within the same thread won't taint it.

But if a kernel-mode component calls ZwDeviceIoControl(...) it's deliberately switching the previous mode to KernelMode. You should treat that as a kernel-mode call and can trust that it's done any necessary parameter validation, etc...

-p



-----Original Message-----
From: ijor@nospam.nospam
Posted At: Thursday, August 11, 2005 2:21 PM
Posted To: microsoft.public.development.device.drivers
Conversation: Assert being the highest-level driver
Subject: Re: Assert being the highest-level driver



Hmm, I probably miss something. Because otherwise I don't understand how this could be useful as claimed by the docs.

How can I know if by the time I call ExGetPreviousMode some other thread made a system call and changed the "previous mode"?

> "Peter Wieland [MSFT]" wrote:
>
> It's the mode of the processor before the last system call.
>
> -----Original Message-----
> From: ijor@nospam.nospam
> Posted At: Thursday, August 11, 2005 8:20 AM Posted To:
> microsoft.public.development.device.drivers
> Conversation: Assert being the highest-level driver
> Subject: Re: Assert being the highest-level driver
>
>
>
> "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 ijor

ijor
Thu Aug 11 23:34:02 CDT 2005

"Peter Wieland [MSFT]" wrote:

> It changes back when the system call returns. Another system call made within the same thread won't taint it.
>
> But if a kernel-mode component calls ZwDeviceIoControl(...) it's deliberately switching the previous mode to KernelMode. You should treat that as a kernel-mode call and can trust that it's done any necessary parameter validation, etc...
>
> -p
>
>
>
> -----Original Message-----
> From: ijor@nospam.nospam
> Posted At: Thursday, August 11, 2005 2:21 PM
> Posted To: microsoft.public.development.device.drivers
> Conversation: Assert being the highest-level driver
> Subject: Re: Assert being the highest-level driver
>
>
>
> Hmm, I probably miss something. Because otherwise I don't understand how this could be useful as claimed by the docs.
>
> How can I know if by the time I call ExGetPreviousMode some other thread made a system call and changed the "previous mode"?
>

Sorry Peter, but I still don't get it. Restoring the "previous mode" after
the system call returns doesn't seem to be enough to avoid race conditions.

What if I call ExGetPreviousMode *after* another thread made a system call,
but *before* that system call returns? Won't I get a wrong "previous mode"?


Re: Assert being the highest-level driver by Doron

Doron
Fri Aug 12 02:21:21 CDT 2005

previous mode is a per thread concept. if another thread makes a sys call,
its previous mode is changed, not the thread you were running on.

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:8337ED8D-B49F-4B23-B7E6-ED64F5D637CE@microsoft.com...
> "Peter Wieland [MSFT]" wrote:
>
>> It changes back when the system call returns. Another system call made
>> within the same thread won't taint it.
>>
>> But if a kernel-mode component calls ZwDeviceIoControl(...) it's
>> deliberately switching the previous mode to KernelMode. You should treat
>> that as a kernel-mode call and can trust that it's done any necessary
>> parameter validation, etc...
>>
>> -p
>>
>>
>>
>> -----Original Message-----
>> From: ijor@nospam.nospam
>> Posted At: Thursday, August 11, 2005 2:21 PM
>> Posted To: microsoft.public.development.device.drivers
>> Conversation: Assert being the highest-level driver
>> Subject: Re: Assert being the highest-level driver
>>
>>
>>
>> Hmm, I probably miss something. Because otherwise I don't understand how
>> this could be useful as claimed by the docs.
>>
>> How can I know if by the time I call ExGetPreviousMode some other thread
>> made a system call and changed the "previous mode"?
>>
>
> Sorry Peter, but I still don't get it. Restoring the "previous mode" after
> the system call returns doesn't seem to be enough to avoid race
> conditions.
>
> What if I call ExGetPreviousMode *after* another thread made a system
> call,
> but *before* that system call returns? Won't I get a wrong "previous
> mode"?
>



Re: Assert being the highest-level driver by ijor

ijor
Fri Aug 12 13:24:06 CDT 2005

"Doron Holan [MS]" wrote:

> previous mode is a per thread concept. if another thread makes a sys call,
> its previous mode is changed, not the thread you were running on.

Thanks, all makes sense now. I don't know why some of the replies gave me
the idea that it is a global (not per thread) attribute.