On 4/5/2012 2:22 PM, sandeep kiran p wrote:
Hi,
I had described about the deadlock we are seeing in Heap32First and
Heap32Next APIs in my previous post. Here is where you can see the post.
http://groups.google.com/group/mailing.openssl.users/browse_thread/thread/3223701a7f64a957/56d67d77c9960429?q=Deadlock+in+RAND_poll%27s+Heap32First+call#
Believing that this is a problem with Windows APIs, we raised an
incident with Microsoft. MS is still investigating the problem and has
asked us to instead use GetProcessHeap and HeapWalk to enumerate the
heap entries of the default process heap. Here is what they said
"
Conceptually, the biggest change between using GetProcessHeap/HeapWalk
compared to Heap32First/Heap32Next is that you are accessing a heap
handle to which you already have access inside of the process – the
default process heap. All components are expected to use this heap and
it has serialized access to ensure that multiple threads from the same
process do not deadlock/corrupt the heap when accessing them
simultaneously. Heap32First, on the other hand, accesses all heaps in
the process, including private heaps that other components in the
process created. Those private heaps might have been created with the
HEAP_NO_SERIALIZE option which disallows application requested
locking. Components (such as SSIS in your case) typically use this
option when they perform the synchronization of memory access on their
own to gain efficiency. However, if another component in the process
start using those private heaps, it circumvents the synchronization
that the component puts in place.
"
And since we lock the heap before reading its contents, the chances of
another thread working on the same heap at the same time are
nullified. I have made changes to RAND_win.c to use GetProcessHeap and
HeapWalk APIs. Would you be interested in accommodating the fix to
mainstream code?
Please let me know your comments.
I am afraid that MS misunderstood the situation completely and got you
confused too.
Most *other* uses of heap walking are about looking at your own heap to
find out something about your own code, and then it makes sense to
either use a heap that has internal locks (the default heap or a
specific heap allocated without the HEAP_NO_SERIALIZE option), or to
take the lock you yourself is using with a specific heap allocated with
HEAP_NO_SERIALIZE.
This is the situation which MS PSS was talking about in its answer.
But the RAND code in openSSL is using the heap walking to get as many
random allocation details as possible from all processes in the system
to seed its RNG.
So limiting the RAND code to only a single heap from its own process
will effectively make that code useless and severely weaken the security
of all cryptographic keys and nonces produced by openSSL. It is simply
not an option.
You will have to go back to MS PSS and explain that you are not trying
to look at a single heap, but at all heaps of all processes and ask why
the "snapshot" lock in the toolhelp32 API does not protect the
"non-invasive debugger" (this is the relevant Microsoft phrase) calling
toolhelp32 from locking issues in the target process. If they tell you
to suspend the process being debugged, remind them that a "non-invasive
debugger" is not allowed to interfere with its target in any way.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
