But it seems that the performance increase depends on turning the feature off for the vast majority of allocations - those under a page in size. This should not be taken as a comment on the implementation of Electric Fence and the superiority of the BSD implementation. It's an observation that the hardware does not run efficiently when you use this technique.
Hm. One way to do the little ones, another for the big ones, and another for the static ones. My feeling for the past decade or so has been that this entire problem just cries out for hardware to address it. In some ways, we were better off with segment registers, since what we are really trying to do here is implement a non-contiguous address space.
As I have written elsewhere in this thread, we had the iAPX 432 sometime in the 80's, which could actually be made to run fast if done today, and which kept every function in its own privilege ring.
I don't understand why we do not see more innovative hardware architecture around the issue of security in general.
Well, unfortunately, it appears that the way to get performance is to only allocate dead pages around allocations that are one page in size or greater. What's that, 4K? This is larger than almost all strings one would care to read and most C++ objects, for example. So, it doesn't surprise me that the examples found are regarding large (image-sized, in the case of X) buffers.
It would be nice if we could get to the point that it would be possible to run the maximum protection in a day-to-day environment. That is more than we can ask of the hardware at present.
You're forgetting about systems that do code generation on the fly such as Lisp systems.
Lisp? Forget about Lisp!Java does it.
But well-writen systems on good hardware (meaning not using i386 page-tables) use mprotect() to make code-pages executable and not writable, and everything else is not executable. So, systems with self-modifying code can be well-protected from this sort of attack. This is available from the OS on all POSIX systems where the hardware page-table-entry has the appropriate bits. One of our problems is that i386 does not. So, our main hardware platform won't protect us without kludges like Solar Designer's use of segmentation registers to establish a protected stack.
Did they fix this in X86_64? Can you make it available to a 32-bit address space without changes visible in user-mode? That would be worth working on.
It would generally find more because it exhaustively protects allocations and the new BSD allocator only does so when the allocation is greater than a page in size (8K?). Electric Fence positions the allocation at the end of the page rather than the start (unless you are testing for underruns), I wonder if the BSD allocator does this.
Image processing performance on some architectures can be horrible if all buffers begin on a page boundary. Some processors only have 2-way set-associative caches. This reveals worst-case behavior with a two-operand image processing operation and one output buffer. You can end up refilling a cache line with every operation. Many image processing libraries assign a random pad at the beginning of each buffer to get around this.
I think the iAPX 432 may have been the best approach to this problem so far, as it put every function in its own privilege ring. It's surprising that nobody is thinking that way today.
On shared-library systems, you can set an environment variable that tells the linker to load Electric Fence every time. Anyone with the patience to try that might be rewarded with some core dumps for which productive bug reports can be made.
Electric Fence explicitly allocates dead pages at the end (or configurably, the beginning) of buffers. It can also protect the memory immediately as it is freed. I think it was first published in 1987.
It may be a legitimate invention - it is cited as prior art in an ATT patent. This is also the first known example of a prior Open Source publication causing a patent filer to cite. ATT also removed a claim from the patent that my work invalidated. Just search for "Perens" in the U.S. patent database to find the patent.
We don't run it on production programs because of its overhead. To do this sort of protection exhaustively, it requires minimum two pages of the address space per allocation: one dead page between allocations and one page allocated as actual memory. This is a high overhead of page table entries, translation lookaside buffers, and completely destroys locality-of-reference in your application. Thus, expect slower programs and more disk-rattling as applications page heavily. If you are to allocate and release memory through mmap, you get a high system call overhead too, and probably a TLB flush with every allocation and free.
Yes, it makes it more difficult to inject a virus. Removing page-execute permission does most of that at a much lower cost - it will prevent injection of executable code but not interpreter scripts.
I don't think the BSD allocator will reveal more software bugs unless the programmers have not tested with Electric Fence.
To take a frivolous comment seriously, if I could get Schneiner, I would involve him. And I'm the Open Source expert. I do some security work, but am several orders of magnitude below Schneiner.
I volunteered to help OVC, and that's one reason I'm mentioned. I think I'm supposed to be the Open Source expert, although I do security work. Schneiner is several orders of magnitude above me in that regard. If there is the slightest possibility that we can get Schneiner to participate, I'd do everything possible to get him on board.
Symantec only counts vendor-acknowledged flaws in this study. Microsoft has yet to handle 19 flaws, and this is admitted by Symantec. If they had counted those, IE would have been less secure in their study. It seems to me that the methodology is deliberately flawed.
Think of it as evolution in action. Economics is worth listening to sometimes. Lots of us operate weblogs and percieve the difference between a hobby and a business. If we wanted to be serious journalists, we'd sell our homes and cars and take an oath of poverty and go full time.
Debian derivatives, taken together, have 3 times the market share of SuSe/Novell. Why not get them working together more effectively?
I'm working today on getting more Open Source into Department of Defense, and won't be able to participate any more in this thread. But I will read it all later, and you can always email me (bruce@perens.com). No phone calls today, but as always my number's on my web site.
One of the problem with UnitedLinux was that SCO was one of the major participants:-) . There was also the LCC, the ashes out of which this effort has sprung. But if you are counting, there are several other efforts begun by yours truly (or "helped-start" by the politically-correct edited interview) to get some of the same things done: Linux Standard Base, Progeny (for which I hired Ian), UserLinux. LCC includes a good deal of the planning of UserLinux, but I haven't given up on UserLinux yet (although everyone else has).
Well, I am corresponding with Eben on this, and hope to talk with him, and with Stu and Diane of OSDL this week. Hopefully I will have something material to say by the end of the week.
Don't accuse me of backsliding when I haven't changed my position.
Regarding what solution I offer, no, I'm not out to abolish the patent. I am for an end to software and business method patents. Nobody voted for software patents or business-method patents. Even the U.S. patent office was against them. We have them because of court decisions.
We have won so far in Europe. We can turn back the tide on software patenting, but I am afraid that half-measures like the patent pool will lull people into believing the problem is solved.
Slashdot Mirror
Bruce
As I have written elsewhere in this thread, we had the iAPX 432 sometime in the 80's, which could actually be made to run fast if done today, and which kept every function in its own privilege ring.
I don't understand why we do not see more innovative hardware architecture around the issue of security in general.
Bruce
It would be nice if we could get to the point that it would be possible to run the maximum protection in a day-to-day environment. That is more than we can ask of the hardware at present.
Bruce
Yes. It's used in the NX patch for Linux from Ingo Molnar. Was merged into the kernel with 2.6.8 .
Bruce
Lisp? Forget about Lisp! Java does it.
But well-writen systems on good hardware (meaning not using i386 page-tables) use mprotect() to make code-pages executable and not writable, and everything else is not executable. So, systems with self-modifying code can be well-protected from this sort of attack. This is available from the OS on all POSIX systems where the hardware page-table-entry has the appropriate bits. One of our problems is that i386 does not. So, our main hardware platform won't protect us without kludges like Solar Designer's use of segmentation registers to establish a protected stack.
Did they fix this in X86_64? Can you make it available to a 32-bit address space without changes visible in user-mode? That would be worth working on.
Bruce
Image processing performance on some architectures can be horrible if all buffers begin on a page boundary. Some processors only have 2-way set-associative caches. This reveals worst-case behavior with a two-operand image processing operation and one output buffer. You can end up refilling a cache line with every operation. Many image processing libraries assign a random pad at the beginning of each buffer to get around this.
I think the iAPX 432 may have been the best approach to this problem so far, as it put every function in its own privilege ring. It's surprising that nobody is thinking that way today.
Bruce
Bruce
It may be a legitimate invention - it is cited as prior art in an ATT patent. This is also the first known example of a prior Open Source publication causing a patent filer to cite. ATT also removed a claim from the patent that my work invalidated. Just search for "Perens" in the U.S. patent database to find the patent.
We don't run it on production programs because of its overhead. To do this sort of protection exhaustively, it requires minimum two pages of the address space per allocation: one dead page between allocations and one page allocated as actual memory. This is a high overhead of page table entries, translation lookaside buffers, and completely destroys locality-of-reference in your application. Thus, expect slower programs and more disk-rattling as applications page heavily. If you are to allocate and release memory through mmap, you get a high system call overhead too, and probably a TLB flush with every allocation and free.
Yes, it makes it more difficult to inject a virus. Removing page-execute permission does most of that at a much lower cost - it will prevent injection of executable code but not interpreter scripts.
I don't think the BSD allocator will reveal more software bugs unless the programmers have not tested with Electric Fence.
Bruce
While the rendering of the map might be copyrightable, the information about the routes is not. He should have someone else render a map.
Bruce
Bruce
Bruce
To take a frivolous comment seriously, if I could get Schneiner, I would involve him. And I'm the Open Source expert. I do some security work, but am several orders of magnitude below Schneiner.
Bruce
Tee hee. I hadn't seen that.
Bruce
It's 2 AM here in Norway, so I'm not going to write much else tonight.
Bruce
Bruce
Bruce
Bruce
Bruce
Bruce
I'm working today on getting more Open Source into Department of Defense, and won't be able to participate any more in this thread. But I will read it all later, and you can always email me (bruce@perens.com). No phone calls today, but as always my number's on my web site.
Bruce
It still needs doing.
Bruce
Bruce
Don't accuse me of backsliding when I haven't changed my position.
Regarding what solution I offer, no, I'm not out to abolish the patent. I am for an end to software and business method patents. Nobody voted for software patents or business-method patents. Even the U.S. patent office was against them. We have them because of court decisions.
We have won so far in Europe. We can turn back the tide on software patenting, but I am afraid that half-measures like the patent pool will lull people into believing the problem is solved.
Bruce
OK, I have replied to the message you cited.