[Cryptography] bounded pointers in C

[Jerry Leichter]

On Apr 18, 2014, at 7:35 AM, Ben Laurie <ben at links.org> wrote:
> Hmm. Any info on how this works (or worked)? All bounded pointers
> implementations I've seen have required some kind of code annotation
> to make them work properly (e.g. explicit fat pointers). Can it really
> be done without source modification?
In principle, it's easy.  Nothing in C constrains the size of pointers; the compiler can make them any size it likes.  There are statements about what happens if you cast a pointer type to an integer type "large enough to contain it", but nothing says such a type must exist.  So you can simple make every pointer a "fat pointer".  The only legal ways to get initial pointer values is by taking the address of an object (and the size of an object is always known); or by calling malloc() and friends, which necessarily know the size as well.  Beyond that, it's just a matter of keeping the size updated as the pointer is modified by pointer arithmetic.

That's the principle.  The *practice* is that a huge fraction of practical, every day, C programs assume that a pointer will fit in a long.  Nothing in the language guarantees it, but "everyone knows" that this is how C works.

At the cost of performance, you can move the lengths off to a hidden data structure in which you can look up pointers.  When you're handed a pointer, you look it up and get its length.  This is messy because you can be handed a pointer into a block of legal memory.  So you need a structure to check whether a pointer occurs in any of a set of ranges.  How well this would work in practice, I don't know.  Presumably a smart compiler can elide most lookups:  In some cases it knows the size anyway (e.g., you take the address of a struct on the stack); in others, once it's looked it up, it can keep it around for a while (i.e., thin pointers in memory, fat pointers in registers).

                                                        -- Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140418/41b7f527/attachment.bin>