On 4/5/2012 6:18 PM, sandeep kiran p wrote:
Jakob,
The last time we had this discussions, I mentioned when 0 is passed as
the second argument to CreateToolhelp32Snapshot, it takes a snapshot
of all the heaps for all the processes in the system. I was wrong.
This routine only takes the snapshot of all heaps of a single process
whose process ID is passed as the second argument to the call. If a 0
is passed there, it lets you enumerate the current process's heap.
Whereas for processes and threads, you get a list of all the processes
and threads running in the system.
So even with CreateToolhelp32Snapshot (with 0 passed as second
argument) you are just looking at the current processes's heaps. The
only difference wrt GetProcessHeap is that, with
CreateToolhelp32Snapshot you would look at all the heaps created
within the process and not just the default heap.
That pretty much makes it useless, as this code usually runs shortly
after process startup, when the heap layout is pretty much the same
every time (on Windows ASLR only changes at reboot to avoid messing up
programs that look at other processes without using undocumented(!)
tricks to handle interprocess ASLR differences).
Thanks
Sandeep
On Thu, Apr 5, 2012 at 8:30 PM, Jakob Bohm <jb-open...@wisemo.com
<mailto:jb-open...@wisemo.com>> wrote:
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
