Modifying memory functions is never easy on an operating system, as a problem with memory affects everything in the system. OpenBSD developers have put out a call to help testing a new memory management system for the upcoming 3.8 release, which is tentitively set to be released this October.
Then help
us fix it. For everyone.. not just OpenBSD users.
That’s the spirit 🙂
Say whatever you want about Theo, but the result is that, to this day, OpenBSD is one of the world’s most secure operating systems available. The gap between OpenBSD’s rock solid performance and security and the Microseft joke widens with each release.
Theo may be a total jerk sometimes, but the work he does on OpenBSD benefits many operating systems, not just OpenBSD. Hothead stubborness seems to go with the territory of great project leaders
I certainly don’t agree with a complete mindset aimed at security all the time whenever it compromises performance significantly, or other problems, but so far he seems to have taken a reasonable balance.
Those that can afford to should support them however possible, whether through monetary or other means. I will certainly be helping test…
OpenBSD truely sets an example for OSS. Their emphatic, if not always diplomatic, drive for open source drivers, their proactive improvement of code is outstanding.
Rather than the “let’s code, release, fix bugs later” mentality that is so prevalent.
They have been working on the malloc/overflow improvements for three years after identifying this as a major weakness.
Very impressive.
I haven’t noticed any problems with the latest snapshot BTW. All my ports work fine.
Installed snapshot (3.8), so far so good, ports installed; gnome,gdm,xorg,etc.. work fine.
Very nice gcc gives notes about unsecure syscalls like strcat() and sprintf() and better alternatives.
strcat() and sprintf() are library calls, not syscalls
Oops my bad 🙂
Regarding library calls.
Didn’t hear Theo in his e-mail say anything about preventing return to libc.
> Didn’t hear Theo in his e-mail say anything about preventing return to libc.
There are already a few mitigation techniques to make it harder : libraries are randomly mapped and their base address is random too (try to run ‘ldd <executable>’ multiple times). It is not a silver bullet, but it probably does help.
They have a cool presentation here : http://www.openbsd.org/papers/auug04/mgp00001.html
A very silly question, but how can they keep the performance at a decent level with all this? I mean, if free() is called an a page happens to be unallocated, that page is un-bkred out of the process, right? Wouldn’t that cause performance penalties by updating the MMU all the time, or what is it I’ve misunderstood?
The idea is however great. I’ve chased enough memory leaks in my days to be totally convinced that Theo & co are on to something brilliant.
/Marcus
> A very silly question, but how can they keep the performance at a decent level with all this? I mean, if free() is called an a page happens to be unallocated, that page is un-bkred out of the process, right? Wouldn’t that cause performance penalties by updating the MMU all the time, or what is it I’ve misunderstood?
They keep a cache of free pages, so the performance penalty of unmapping should not be a concern in practice.
Let Theo debug his own crap. Then he won’t have anyone to whine and bitch about, but himself.
What an a$$
> Let Theo debug his own crap.
*Hrmm*
It is not ‘his own crap’ but the broken open source applications available as third-party packages they want to debug.
Dangerous programming is everyone’s problem.
Looks like Theo has found a well and is standing there in the desert with a bottle of wather in his hand.I will go for the water bottle and just continue to ignore the marketing troll stand with the beautifull sales talk.