3 ms·
The CHERI extensions for the ARM architecture allow for compilers that achieve this effect by making all pointers "fat", with bounds, and doing pervasive hardwa
by rst 5y ago
The CHERI extensions for the ARM architecture allow for compilers that achieve this effect by making all pointers "fat", with bounds, and doing pervasive hardware bounds checks. They've been playing with FPGA versions and emulators for a while, but the first actual SoCs just got shipped: https://www.theregister.com/2022/01/21/arm_morello_testing/ https://www.theregister.com/2022/01/21/arm_morello_testing/ -- software for it includes tweaked versions of BSD and I think Linux which use bounds-checked pointers throughout, including in the kernel.
- WalterBright 5y agoMaking them all fat doesn't fix code that uses strlen().
- rst 5y agoNot quite sure what you mean. All it can do is turn undefined behavior on an out-of-bounds reference into a segfault, but if that ends up turning an RCE vulnerability into something less severe, it's still an improvement -- at least from that perspective. The intent is for the hardware-checked bounds to be at very close to the declared bounds for arrays in source code, at least in cases most typically subject to buffer overlow; see https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf (And I'm not sure how the alternative fat-pointer proposal you mentioned does better. Searched that page for references to strlen, but didn't find much.)
- WalterBright 5y agoMost arrays do not have declared bounds, that's why a runtime check is necessary.
- rst 5y agoBounds for storage are known when it is allocated. CHERI puts those bounds into the pointers (which double in size so they can fit), and has the processor do the runtime checks at every dereference. So, same effect as the proposal you reference, AFAICS -- just without altered syntax.