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. Thanks Sandeep On Thu, Apr 5, 2012 at 8:30 PM, Jakob Bohm <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#<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 >
