Posts by jrtc27

FreeBSD 14.2 wants to woo Docker fans, but still struggles with Wi-Fi

14.2’s install media has the firmware for various WiFi chips installed to it too in case you need them.

Arm rages against the insecure chip machine with new Morello architecture

References can be, and often are, turned back into raw pointers, and nothing stops you using the unchecked parts of C++. How many times have you use the unchecked std::vector<T>::operator[] instead of the same std::vector<T>::at, or used the unsafe std::vector<T>::front/back, for example? Just because they exist in parts of the language doesn't mean C++ is suddenly a panacea.

Re: Silicon Secured Memory (SSM)

SSM, also known as ADI, is not a compartmentalisation technique. It is the same concept as Arm's MTE (which was clearly inspired by it). Such tagging techniques do not provide deterministic fine-grained memory protection; they operate only at a coarse granularity, typically on the order of 16 bytes (that's what MTE typically uses, thought the SPARC M7 has a whopping 64 bytes, i.e. cache line, granularity), and are in the general case only probabilistic with a 1 in 2^N chance, for some small N that's typically around 4 or 8, since if you pick two allocations at random there is a 1 in 2^N chance the memory colours/versions will happen to match. On the M7 that means a 1 in 16 chance if you have no prior knowledge about the version. Moreover you can only bound the allocation, you cannot hand out access to part of an allocation, since recolouring part of the allocation would break the original pointer (you can, though, *split* the allocation at the tagging granularity), and in a compartmentalised world you rely solely on a malicious compartment not just guessing, or inferring, the right version to use. This is the killer that makes it useless for compartmentalisation, resigned to being solely a debugging and probabilistic mitigation technology. These limitations are all laid out for you in the very article you link to. Also not sure where you got this idea of "making sure pointers do not exit their [already reasonably secured] MMU isolated area", there's no such thing, SSM does nothing to stop you storing your pointer wherever you like.

CHERI suffers from none of those issues. Capabilities cannot be forged, even if you know every single bit of the capability, the bounds are in the pointer so you can hand out multiple aliasing capabilities with different bounds and permissions, and single-byte capabilities are supported.

If you want the details, there's Arm's full specification at https://developer.arm.com/documentation/ddi0606/latest, as well as our CHERI specification at https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-951.pdf; Arm's spec describes everything about the architecture but leaves out a lot of the design rationale that is present in the CHERI spec, instead choosing to reference our spec. https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-916.pdf is a few years old now but has ideas for how CHERI can help lessen the effects of speculative execution attacks; the high-level observation is you can avoid speculatively accessing out of bounds, so if you have accurate bounds for your language-level objects then you can avoid the `if (x < len) return a[x];`-style Spectre gadgets being abused as arbitrary read gadgets, only for reads within bounds (some of which may still not be permitted by the language-level checks, but it's at least a start). There's still a lot of nuance though.

Re: Very Expensive Approach / Details

Safe languages are great, but the world has huge piles of C/C++ and people keep adding to that pile every day. Some projects are being rewritten in languages like Rust, but they are few and far between. If you can write everything in a safe language then you do not need hardware memory protection (though there is the possibility that having bounds checks in hardware could remove the need for generated bounds checks in software). C/C++ are going to remain around for decades and something needs to be done to tame those languages, and that is what CHERI/Morello addresses. It also allows you to limit the damage of unsafe regions of code in safe languages in the same way that it limits the damage of buggy C/C++, be that something like Rust's unsafe or something like Java's JNI.

Re: Design of Intel MPX ~2015

MPX was racy, had no protection against using the wrong bounds with a given pointer as it was totally separate, and only had four bounds registers. It was not a good design.