('binary' encoding is not supported, stored as-is) In-Reply-To: <75C025AE395F374B81F6416B1D4BDEFB01009380@mtv-corpmail.microfocus.com> >AS/400, where C programs in essence run under a virtual machine, and most >out-of-bounds accesses will immediately trap. > That's interesting. I'm passingly familiar with the VMs used by AS/400, but I wasn't aware that out of bound accesses would immediately trap. I wonder how they do this... I was under the impression that VMs used in this way were really just a sort of defense in depth. They don't prevent an individual process from being compromised but prevent that compromise from expanding beyond the boundaries of the VM. Do they really trap overruns from one valid chunk of memory into an adjacent one? >With help from mprotect or equivalent these areas could further be protected >with guard pages. There'd be a performance penalty for such a scheme >(versus having each malloc'd area carry its own information, as is typical), >but besides making the heap harder to corrupt, it'd let the implementation >catch invalid and duplicate free's. > Storing things differently would be smart. Would guard pages actually be useful, tho'? mprotect() and VirtualProtectEx() type functions only work with the granularity of memory pages. So to effectively prevent this exploit all your malloc()s would have to allocate at least an entire page plus a second guard page which wouldn't need any physical storage. That's not very practical; at this point there wouldn't really be any need to use an allocator at all since all allocated objects that were protected would already consume an entire page. Yeah, there would definitely be quite a performance penalty for such a scheme... Cheers, ~x
This archive was generated by hypermail 2b30 : Fri May 16 2003 - 15:54:15 PDT