Strict Provenance APIs

For some people, working with pointers that are nothing more than a raw memory address dressed up e.g for MMIO or DMA, the Exposed Provenance API in this work is what you'll mostly interact with and these functions are morally much like PNVI-ae-udi model that C has written into a TS now and which is more or less de facto standard for optimising C compilers. Tooling both software like MIRI and hardware like CHERI can't help here, I hope you knew what you were doing, nothing really got better for you, except that this API lets you make it clear exactly what you're doing so any human reviewer can see what you meant (e.g. a subsystem owner)

However for people who were doing tricks with pointer bits, but did NOT know the raw addresses, the Strict Provenance API means more often now the tooling can tell you if you mistakenly pointed a gun at your own foot. For these people the new APIs ought to be a real help in achieving confidence that what you did was correct as well as fast. You get a way to say "Given any pointer A, I want to fiddle with the bits and produce a pointer B which may or may not be valid" and also "Given any pointer B that I made with that previous routine, here's a way to get back pointer A" which is exactly what you need for squirrelling away some flags bits in the bottom of an aligned pointer for example. MIRI can follow along as a synthetic pointer A goes through the process to make B, stuff happens, and much later B goes through the other process to make A again, and it can say OK, that's a valid pointer, this code isn't insane. Or, if your code was faulty and that produced C instead which isn't a valid pointer under that model, MIRI can tell you hey, this doesn't work, even though if you'd released the code anyway that "invalid" pointer would have "worked" by mangling unrelated values in memory and you'd have perhaps lost a week debugging the pointer twiddling code.