From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Bernecky To: Joern Rennecke Cc: Michael Meissner , David Edelsohn , John Gilmore , Subject: Re: Esthetics (or worse?) of Secure Pointers Date: Wed, 18 Apr 2001 10:37:00 -0000 Message-id: References: <200104181703.f3IH3dj06433@phal.cambridge.redhat.com> X-SW-Source: 2001-04/msg00873.html Well, sort of. [I don't want to start a religious war here; I do want to make my position clearer.] Think of John's proposal as a stepping stone. We introduce a new architecture (bounded-x86) that lives alongside the existing x86 architecture. In the fullness of time, everyone buys into the secure-x86 architecture, we retire the x86 architecture completely, and everyone lives happily ever after. Will this work? I believe that there are strong engineering and liability reasons that will make it work. Here is a tiny picture of the future of the programming world, as lawyers exploit their y2k experiences: http://www.theregister.co.uk/content/8/18324.html As computing professionals, we have a responsibility to provide provably reliable tools. C without secure pointers is not reliable. We (the computing community) are going to be forced to move programming from a craft to an engineering discipline. Issues of performance and memory use are going to be swept aside by the threat of lawsuits. As someone who has worked with array languages since the dark ages (a bit earlier, actually), I have to emphasize that code safety (in the sense of having array buonds checks and automatic memory management) is an incredibly powerful tool for creating secure and robust applications. Buffer overflows simply do not and CAN NOT exist in array languages (modulo compiler bugs, of course). Secure pointers are not a complete solution to the problems in C (dangling pointers can still exist, and the absence of real arrays (N-dimensional objects rather than vectors of vectors) causes increased overhead and opportunity for more code faults), but they move us a long way toward reliability. John's position, and mine, is that good optimization work should let us get the cpu time overheads down to acceptable levels. We are stuck with the memory overhead, but memory is cheaper every day, so that's probably acceptable, particularly now that 64-bit architectures are becoming reasonably priced. Bob On Wed, 18 Apr 2001, Joern Rennecke wrote: > > > > On Tue, Apr 17, 2001 at 10:45:44PM -0400, David Edelsohn wrote: > > > The ELF architecture field in the header is assigned, not > > > something that one can "pick a new specifier" without causing conflicts. > > > > But since the ABI is effectively different anyways, one could argue it is a > > different machine (John's proposal) and/or uses a data encoding (my proposal) > > or even using some other field. > > John's proposal is not practical, since it means that you have to allocate > a new machine identifier for every machine identifier in existance where > you would contemplate using the BP checking compiler. And also for all > future non-BP machine identifiers. And you have to make sure you don't > step on someone's elses toes while doing these allocations. > > The data encoding proposal seems much more practical to me. You just have > to add two more types, and cover all architectures. > Robert Bernecky Snake Island Research Inc. bernecky@acm.org 18 Fifth Street, Ward's Island +1 416 203 0854 Toronto, Ontario M5J 2B9 Canada http://www.snakeisland.com