memory protection, hardware solution to prevent buffer overflow - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: December 03, 2014, 01:23:05 am
content: Quotefromthisblogvery interesting and amazing technology by intelanyone has seen something similar implemented in SoftCore (fpga) ?

author: legacy
author_rank: Super Contributor
timestamp: December 03, 2014, 01:24:20 am
content: more useful information about MPX: seethisproject (address-sanitizer)

author: tggzzz
author_rank: Super Contributor
timestamp: December 03, 2014, 10:19:12 am
content: Quote from: legacy on December 03, 2014, 01:23:05 amAlmost certainly with significant limitations, e.g. fromhttps://code.google.com/p/address-sanitizer/wiki/IntelMemoryProtectionExtensions#MPX_weaknessesQuoteOf course, a lot of C/C++ and OOP code contains lots of pointers. Array-based HPC languages such as Fortran contain far fewer pointers.

author: Rasz
author_rank: Super Contributor
timestamp: December 03, 2014, 11:29:10 pm
content: Quote from: legacy on December 03, 2014, 01:23:05 amits not really amazing, its just bringing higher level language features to lower level (C) compilerQuote from: legacy on December 03, 2014, 01:23:05 am? it has nothing to do with hardware, its just software

author: legacy
author_rank: Super Contributor
timestamp: December 04, 2014, 01:17:07 pm
content: theMPXtechnology by intel is an hardware approach to solve the problem

author: amyk
author_rank: Super Contributor
timestamp: December 04, 2014, 04:02:45 pm
content: Add even more complexity, slowness, and memory usage just so stupid programmers can continue to write buggy code...?

author: legacy
author_rank: Super Contributor
timestamp: December 04, 2014, 04:22:34 pm
content: i don't knowjust considering if i could add a few MPX-like features to my poor softcore (codename "ponoku", it' a toy)wandering if it has any sense, or if it could be useful

author: Rasz
author_rank: Super Contributor
timestamp: December 04, 2014, 05:24:50 pm
content: Quote from: legacy on December 04, 2014, 01:17:07 pmits a hardware approach implemented in a compiler? ....its right there in your link - they cant handle binary patching and had to resort to compiler optimisation, it only works on sourcecode.maaybe in a long run they might be able to build state machine capable of recognizing binary compiled code for common cases they want to cover, but not now+ you dont need this for anything other than C

author: legacy
author_rank: Super Contributor
timestamp: December 04, 2014, 10:18:42 pm
content: Quote from: Rasz on December 04, 2014, 05:24:50 pmthe question is: any useful hardware approach to help the compiler or the debugger to find out bugs (buffer overflow) ?is it possible ? is it really useful ?also wandering about the ADA language, it should be safer by design, but i don't know

author: Marco
author_rank: Super Contributor
timestamp: December 04, 2014, 10:44:01 pm
content: Buffer overflow is fundamentally a software problem. What you can do is provide better support for memory protection, namely address space IDs in TLB entries (this allows you to use virtual memory for sandboxing everything upto and including drivers without getting killed by TLB flushes on context switch). Unless you have a complex OS for which that would be actually useful it seems like a waste of time though.Just use languages which don't suffer from buffer overflows.

author: ehsmeng
author_rank: Contributor
timestamp: December 05, 2014, 06:24:48 pm
content: OpenBSD took an interesting approach in the 3.8 release:"During the development cycle of the 3.8 release, changes were made to the malloc memory management functions. In traditional Unix operating systems, malloc allocates more memory by extending the Unix data segment, a practice that has made it difficult to implement strong protection against security problems. The malloc implementation now in OpenBSD makes use of the mmap system call, which was modified so that it returns random memory addresses and ensures that different areas are not mapped next to each other. In addition, allocation of small blocks in shared areas are now randomized and the free function was changed to return memory to the kernel immediately rather than leaving it mapped into the process. A number of additional, optional checks were also added to aid in development. These features make program bugs easier to detect and harder to exploit: instead of memory being corrupted or an invalid access being ignored, they often result in a segmentation fault and abortion of the process. This has brought to light several issues with software running on OpenBSD 3.8, particularly with programs reading beyond the start or end of a buffer, a type of bug that would previously not be detected directly but can now cause an error. These abilities took more than three years to implement without considerable performance loss and are similar in goals to that of the Electric Fence malloc debugging library by Bruce Perens."