Svadev mailing list

[John Criswell <criswell AT illinois.edu>]

On 5/26/12 6:28 AM, Baozeng wrote:

[snip]

So, the logic would be:

if (64-bit)
    set mask value as we do now
else
    if (32-bit)
        if (Linux)
            set mask value as we do now
    else
        mmap region dynamically and use that

Yes. It sounds reasonable. In our BBC implementation, when initializing the runtime pool, we have mmaped a large memory for baggy bounds table. If we mmap another large memory to support for OOB pointers, then the memory that an application uses is limited. Can we reuse the memory mmaped for baggy bounds table to support OOB pointers in 32-bit machine with OSes that is not Linux?

No, I don't think that's a good idea.  The OOB area should be read- and write-protected when in production mode so that OOB pointers generate a fault if they are used in loads and stores.  The BBC table needs to be read/write-enabled for the run-time checks.

I think that, on non-Linux 32-bit platforms, you should just do the mmap for the OOB area so that it falls within the 0xc0000000 - 0xffffffff range and just call abort if the mmap() fails.

To be honest, the only 32-bit platform that I'm concerned about supporting is Linux and maybe Mac OS X, and that's only because one of our funding agencies evaluates SAFECode on 32-bit Linux.  This design will work on 32-bit Linux, should work on 32-bit Mac OS X, and it'll probably work on other 32-bit Unix systems.

-- John T.