Re: Some Pocket PC 2003 incorrectly running apps in "User mode"! by The
The
Wed Nov 12 22:31:20 CST 2003
"Eli Schleifer [MSFT]" <elisch@online.microsoft.com> wrote in message
news:OrXg3cVqDHA.1672@TK2MSFTNGP09.phx.gbl...
> The PocketPC is by default assumed to be a trusted environment and all
> applications run in system mode (this is not true of the smartphone which
> has a tighter default security configuration). If you are seeing this
> happening with a specific device it is probable that the OEM intentionaliy
> configured the device to run everything in user mode. I would suggest you
> get in touch with SYMBOL and determine if there is a way to change the
build
> back to support System mode custom apps.
>
> --
> Thanks,
> Eli Schleifer [MSFT]
After discussing with Neil Enns [MSFT], we understand that the situation is
the following:
- Most Pocket PC's run applications in "Kernel mode"
In fact *all* Pocket PC 2000 and 2002 run applications in "Kernel mode", as
far as we know.
- Some Pocket PC's 2003 run applications in "User mode" (e.g. SYMBOL PTT
8800)
When we contacted the manufacturers of those devices (e.g. Symbol), it
appears that they did not configure their device with the intention of
running applications in "User mode", it was just a mistake on their part.
Apparently MSFT does not include a test in the platform SDK to warn OEM's of
possible mis-configuration when they run apps in User mode.
- Running apps in "User mode" does *not* improve the security of the
platform in any way!
On a Pocket PC that runs apps in "User mode", apps are always allowed to
switch any of their threads to "Kernel mode" using SetKMode(TRUE).
- Running apps in "User mode" causes compatibility problems with *many*
Pocket PC applications.
Most Pocket PC applications assume they run in Kernel mode, because
developers are not aware it can be otherwise.
They don't bother calling SetKMode(TRUE) in each of their threads. So when
they run in "User mode", some code will fail. For example, applications
that execute the following privileged instruction to detect the Xscale
version won't work on those devices:
; Read ID Reg in coprocessor #15, requires Priviledged mode
mrc p15, 0, r0, c0, c0, 0
By the way there is no API to reliably get the CPU type and version (e.g.
ARM vs PXA-250 vs PXA-255 etc), which is why we use the code above. There
are other API's that are sometimes (optionally) implemented by OEM's but
they rely on OEM's text strings that are often wrong and specify an
incorrect CPU type. The only good way to know it to ask the CPU with the
above instruction.
- It is totally unclear to us whether Pocket PC's that run applications in
"User mode" are compliant with MSFT's specification of the Pocket PC
platform.
- If those Pocket PC's are compliant with MSFT's specification of the Pocket
PC platform, then MSFT should make it clear to Pocket PC developers that
THERE IS NO GUARANTEE THAT THEIR APP WILL RUN IN KERNEL MODE, and that they
*need* to call SetKMode(TRUE) if they do anything that requires being in
Kernel mode (e.g. looking at Xscale processor version).
- MSFT did not include pkfuncs.h, toolhelp.h etc, in the Pocket PC SDK.
Those header files contain the declarations for SetKMode and for many other
functions routinely used by Pocket PC applications (KernelIoControl etc).
- There is clean API to detect if the application is running in User mode of
Kernel mode.
You can call SetKMode several times, since it returns the old mode. Or you
can execute
mrs r0, cpsr ; Load CPSR into R0
And look at some bits in this register (see Intel Xscale manual)
- If the application is running in Kernel mode, SetKMode(FALSE) does not set
it in User mode, contrary to what the documentation suggests.
- SetKMode only changes the mode of its calling thread, contrary to what the
documentation suggests.
- Thread that are created later do *not* inherit of the mode set by
SetKMode.
I think that covers this subject pretty thoughrouly...