![]() Re: "Trust the OS" - If only it were that simple. It would be a good idea to have separate memory pools with no-access pages between them to segregate different types of in-process data from buffer overruns, but you'd pretty much have to write your own allocator for that purpose too. The big issue here is simply not validating the received PDU (which could simply be random data, even if not malicious). And of course OpenSSL runs on a wide variety of platforms and malloc performs rather differently across all of them. Applications often keep several separate memory pools and libraries often expect (or at least allow) the calling application to do their memory allocation for them. There's no way malloc could "know" what the best thing to do would be in every circumstance. And OpenSSL isn't even an application, it's a library used by applications which use memory for other things and might not want OpenSSL to get memory on a first-come-first-served basis. Using malloc for every PDU you received (for example) would be madness. Memory allocation is always going to be a problem because the "right" strategy depends on the application. "Trust the OS" - If only it were that simple. Ask how quickly microsoft/IBM/Oracle/Sybase come up with fixes to such problems. In any event, the patch was out the same day it was discovered and people were patching their SSL code straight away. ![]() So holding up the whole of the FOSS community to ridicule, and the author of this code specifically, is pointless. There is no doubt that Heartbleed is a big bug. These are things that need to be done fast and efficiently. Context Swaps, Process Creation, memory paging, device IO. Very carefully controlled ways of ignoring bounds checking are used so that your PC responds fast, at the speed you want. The second problem is that, in the kernel of an O/S, especially in Unix/Linux type of O/S's, there are many places where bounds checking is just inappropriate. The first problem is that at compile time the bounds are not known. ![]() So yeah, modern Linuxes give you lots of cool tools, but they're not compiled in by default.Ĭ is still my favorite programming language after all these decades, but most people really shouldn't be allowed to use it, certainly not without extensive oversight of anything security-critical.ĪC suggested he is not a coder drone and proposes that bounds checking be done in the compiler. The reason the memory of the dead objects wasn't zeroed on release is that, by default, OpenSSL keeps its own pool of memory and doesn't bother using malloc() very often (because on some systems, that might be slow, which would make managers sad), so OpenSSL doesn't call free() when it's done with those objects, and therefore if you've got a malloc()/free() system that has extra protection, like zeroing stuff or putting guard pages after chunks of memory to keep you from running off the ends, it doesn't waste time doing that. It's able to grab whatever 64KB off the heap is near the object it's supposed to be able to ask for, so that can include memory from live or dead objects, because C doesn't stop you from shooting yourself in the foot by running off the end of an array. No one programming technique is appropriate for all cases and attempting to use one across all or to use the wrong technique is utterly stupid. Some things are appropriate implemented one way, some another. If you had an understanding about just how much more processor resources (memory and CPU cycles) are consumed by managed code than unmanaged code then you would understand. ![]() The lower level the API the less appropriate it is that it is implemented using "managed" code. This kind attitude to coding is exactly why many current applications and indeed operating systems are so staggeringly inefficient and slow compared to the equivalent of even a few years ago despite the hardware being orders of magnitude faster. SURE I BROKE MY NECK A FEW TIMES, BUT IT'S NOT GONNA HAPPEN AGAIN. THIS ZIMMER FRAME REALLY GETS ME THERE FASTER, I JUST HAVE TO BE CAREFUL WHEN GOING DOWNSTAIRS. Writing in C means you have to be much more careful FROM THE EIGHTIES! Well, already in 1984: The Lilith That efficiency is achieved by working as close as possible to the "bare metal" - And C gets you there.īOLD TALK. System libraries usually need to be implemented in the most efficient possible way. Re: This attitude is not the key to success
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |