Re: Capabilities, Anybody?

BGB wrote:

I am guessing Bounds-Check-Enforce is more likely to have around a 30%

My guess would be SQRT(30%) ~= 15%

overhead, maybe more or less. But, this is likely also to be for code that is potentially hostile. But, then, one wants the security to be strong enough that there is no practical way for code to break out of the sandbox; though, if allowing for arbitrary machine code, then there is still the great potential Achilles heel that is the Global Pointer or GOT.

Note:: GOT is not ST-able in My 66000 architecture.....You can LD it into
a Register for accessing what it points at or you can LD it into IP and
execute code over there. {No trampoline}

     Only sure way to avoid this is to not have any "potentially compromising" capabilities anywhere

"within the graph of what is reachable from the hostile code" is redundant.
 

                                    and the main obvious way to do this is via the use of system call.

If operating solely at the C level, it is a little easier: One needs to make sure that there is no way for the code to get direct access to the Global Pointer or GOT or similar. An ABI based on FDPIC would be bad here, since it is within the reach of C code (under typical C behavior, UB notwithstanding) to be able to gain access to the GOT for an arbitrary function pointer.

Application cannot ST to its GOT.

A big chunk of this would be overhead shared with the 128-bit ABI (which would have gone over entirely to 128-bit bounds-checked pointers), with a few new/additional overheads.