Very interesting paper, Tom! Thanks for the link. You didn't mention one advantage of the 7090/7040 index architecture: Since indices were hardware _subtracted_ from the pointer instead of added, (upper) bounds checking was easy: "negative" indices were out of bounds!! But you could achieve the same thing with additive index registers: arrange the index register to hold a "negative" index, such that any HW overflows into positive territory indicate a buffer overflow. Example. Suppose we have 15-bit index registers and byte addressing. We want to reference a byte array of ten bytes "bytearray[i]". The "base" of our bytearray is (@bytearray)-32758, so we are really accessing (@bytearray-32758)[i+32758]. If i gets too big, our indexing HW will overflow. From a systems security point of view, the interface to your memory management unit is critical; even one screwup, and the entire system will be compromised. The entire system needs a threat model, and a _formal proof_ that the system is secure. Since this is hardware, we don't have any opportunity to retrofit; we'll have to throw the hardware out if it has any security flaws. The one thing that Defcon-type conferences have shown time & again is that even the smallest chink in the armor can be escalated to a full- fledged pwn. The details of the memory management unit, the instruction fetch unit, the TLU, and particularly the various kinds of hardware trapping, can conspire to enable hacking. I'll have more thoughts later when I have had more time to think about your low-fat pointer scheme. At 11:54 AM 6/10/2014, Tom Knight wrote:
Since a large fraction of current bugs arise from bounds check failures, another approach is to make the array pointer itself aware of the array bounds. This is a paper describing a low-overhead approach to doing this which we are implementing as part of a clean-slate processor/language design: http://www.crash-safe.org/sites/default/files/fatptr_ccs2013_0.pdf