My apologies if the following few naive questions are out of place or off topic here. I do suppose that there might perhaps be other places where such question might perhaps be better put, but many/most/all of those other places appear to be filled, at present, with discussions and comments which are about on par with some of the alien abduction theories relating to MH370. And I would prefer to have a more thoughtful exchange. Thus I come here. Anyway, having read the currently available (and quite detailed) online descriptions of the Heartbleed bug, I am disposed to seek answers to the following few questions: 1) Why does OpenSSL even contain a function called "OPENSSL_malloc"? Does anyone other than me think that it might perhaps have been a better choice to provide only a function called "OPENSSL_calloc"? 2) Not that this would actually have eliminated the bug, but... Was there some compelling reason why space for the "buffer" at issue was allocated via a call to "OPENSSL_malloc", rather than, say, simply being declared as a function-local "auto" char[1+2+65536+padding] ? 3) Not that this would actually have eliminated the bug, but... After making some effort to do so, I have been unable to find any information online which would serve to document the initial state of the blocks of memory allocated by calls to pthread_create(). Would any of you happen to know if said blocks are or, conversely, are not cleared to zeros prior to execution of the created thread(s)? 4) If, as has been suggested in some quarters, the _actual_ size of the heartbeat client-supplied payload may be correctly determined without any reference whatsoever to the _content_ of the request packet, then why is/was it the case that the SSL protocol specified that such packets should contain a payload length specification... a value that, as we all now know, may be spoofed with disasterous consequences? Regards, rfg P.S. Looking just now at the man page for execve(2) I could not help but notice that it neglects to say a single word about the state of the memory comprising the initial page of the (new) execution stack, let alone any additional pages that may be subsequently and automagically added to the execution stack. I, for one, had certainly always hoped and believed that such pages would be pre-initialized by the kernel to all zeros... as opposed, say, to whatever data had been left in those pages by the most recently deceased process(es) that last held them. But in lieu of any explicit statement on the matter within the man page, I am left with a slight uneasy feeling. To be clear, I have no real fear that others might be able to abscond with data left unerased at the demise of my processes, but as a general matter of principal I greatly prefer it if important aspects of behavior are documented. To me, every man page is a contract. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"