InitializeCriticalSection code in kernel

[yash]

Hello People,

Everybody's buzzing with the launch of the WinCE 6.00.
Congrats to MS for the same.

I have a question related to the "InitializeCriticalSection" code in
the kernel sources. Some background first. We are using Windows Mobile
5.0 and the there was point where the code was Initializing the
critical section twice (meaning the InitializeCriticalSection was being
called twice). Now we started having a memory loss in the kernel (as
the application and driver seemed to be fine).

So, we checked the WinCE InitializeCriticalSection code (after we found
out the blunder). The code does a lot of complex things :), as
expected, and also updates some internal linked list. Also it uses up
some memory (a page or so) from the free pages and passes the same to
the CS structure "hcrit" member.

So now my question :- There is no check in the code whether the pointer
to the CS has been already initialized. Pls shed some light (whether
our understanding is right or whether there is a fix on the same) on
this as it is a potential issue. I understand that the onus of good use
of the critical sections is on the developers.

Regards
Yash

[Steve Maillet (eMVP)]

>I understand that the onus of good use
>of the critical sections is on the developers.

Indeed it is. However, at the very least the OS should have an ASSERT on a
re-init of an already initialized CS. Last I recall it does have checks for
that, though.

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

[yash]

Hello Steve,

The code I have for "InitCriticalSection" is in cscode.cpp in the
PRIVATE\WINCEOS\COREOS\CORE\DLL. I hope I am looking at the right file.
:)

It does not have any ASSERTs though. Also I checked in the WinCE 6.0;
things seem to be the same, no ASSERTs. Can we have some input from MS
on this or can you take it up with them. I think we can share the
detailed case with MS if required.

Regards
Yash

[Travis Hobrla [MS]]

Here's a response from our kernel team:

"We thought about that already, but we don't have a way to distinguish
between an "already initialized CS" and an "un-initialized CS". The reason -
an un-initialized CS can contain *anything*. Take the following code for
example:

pCS = new CRITICAL_SECTION;
InitializeCriticalSection (pCS);

Any assertion inside InitializeCriticalSection can potentially be hit, as
the memory allocated from heap can contain anything, which makes it looks
like a CS that is already initialized.
--
tho...@online.microsoft.com (remove "online" from reply-to address)
This posting is provided "AS IS" with no warranties, and confers no rights.

"yash" <yash....@gmail.com> wrote in message
news:1162803928....@h48g2000cwc.googlegroups.com...

[yash]

Hello Travis,

Glad to have received this mail from MS on this. I understand your
stand on the issue. Also I am sure you guys would have researched quite
a lot in this regard and come upto this IPC implementation.

Potentially looking at the kernel shared code anyone can simply crash
the system using the most intricate part of a kernel, the IPCs. Is
there an alternative way to check the same or is there any plan by MS
to plug the issue? I guess some sort of a variable introduction in the
structure would be useful and maintain backward compatiblity.

A concern which I wanted to share with the community. Thanx
Travis/Steve.

Regards
Yash

[Sue Loh [MS]]

It isn't really clear to me what you mean, that anyone can crash the system
using IPCs. Could you get more specific? Generally our goal is that low
privilege apps can crash themselves but nobody else, while high privilege
code could probably bring down the system.

Sue
sl...@microsoft.com (remove "online" from reply-to address)
http://blogs.msdn.com/ce_base/
_____________________________________________________________

This posting is provided "AS IS" with no warranties, and confers no rights.

_____________________________________________________________

[yash]

Hello All,

I am sorry but I was out of action for a long time now due to an
injury.

We did a small exercise going by the discussion we are having.

We wrote a small application in WinCE 5.0. The application does nothing
more than just declaring a variable of the type CRITICAL_SECTION and
then we put a small loop which keeps calling the
IntialiseCriticalSection repeatedly. After calling the same for about
~422291 times the message box shows "Not enough memory". The OS does
not respond after this.

I think this exercise brings out the purpose of my initial mail.
I am copying the code at the bottom.

Regards
Yash

==================================================
// critical.cpp : Defines the entry point for the application.
//

#include "stdafx.h"
#include "critical.h"
#include <commctrl.h>

void createcritical();

CRITICAL_SECTION m_Lock;

int WINAPI WinMain( HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPTSTR lpCmdLine,
int nCmdShow)
{
createcritical();
return 0;
}

void createcritical()
{
UINT i=0;
do
{
InitializeCriticalSection(&m_Lock);
RETAILMSG(1,(TEXT("i=%u\n"),i));
}while(++i);
}
==================================================

[Sue Loh [MS]]

In that case, you are leaking critical section object handles (inside the
kernel). Anybody can allocate enough memory that the system gets critical
and can't operate anymore. There are many, many ways to do so. A security
policy limiting system resources per application to prevent "denial of
service" attacks is under consideration, but would be very complicated.