I was initially thinking DisARMing Code is just perfect, and - unlike my other books - will not need further updating. Oh, how wrong of me :-)
First, there were a bunch of embarrassing typos and errata (little/big endian, sheesh, you'd think after 20+ years in the industry I'd get this right, even authoring in the wee hours..). Those are all fixed, finally, and I thank the readers who communicated them to me.
Then there was the suggestion of Simon (s03) to cover XZone. Readers of the book surely noticed that Darwin's libmalloc got paltry mention, especially considering the deep detail on Scudo and GlibC. Some of this was due to my already existing discussion in M-I/9, but a large part due to the biggest change - The xzone malloc - being deliberately closed source.
Simon got me to look and see that, by now (April 2026), XZM has been open sourced - probably due to AAPL no longer keeping MTE under wraps. This made me effectively rewrite that entire section, bringing it on par with Scudo/Glibc and really making this chapter complete, IMHO.
Continuing in the tradition of MOXiI and Android, when I add significant content (on order of a page), I'll provide it in full here, so early readers can get it by reading below. There a couple of other pages (Linux IO URings and GCD minor additions). This is the best I can do. The book is not a subscription, and all other publishers leave with you a print book that grows older and outdated even before it sees first print. I'm trying, at least, to catch up as much as I can, and doing it with no charge. Oh, and you're welcome.
This rather important update brings the book to v1.1. I also catch up with ARMv9.6 (which is finally public in version M.a of the manual), as well as 9.7 and even "future technologies", from what little ARM's website is willing to detail. The full list follows:
"Consider a theoretical operating system in which the ABI is "broken", so as to allow a system call to return values not just in X0, but in X1 through X7. Weigh the pros and cons of this approach."
randomize_layout
attribute (used in the Linux kernel and pretty useful)2.2.4 Deferred Reclaim (Darwin 25)
Darwin 25 adds reclaimable memory. This allows user space to write addresses and respective sizes ready to be purged or freed into a kernel ringbuffer. The kernel can then dispose of the memory on low memory conditions. This allows a "grace period" in which user space can "change its mind" and reclaim the address by removing it from the ring buffer. A new Mach trap, mach_vm_reclaim_update_kernel_accounting_trap (#63) supports this feature.
map_shadow_stack(2) syscall (#453) as part of Linux's
GCS.
FEAT_TPS[P] at the end of 7/2.2 (after Figure 7/2-6, before
2.2.1:
Note, that at present nothing prevents one thread from accessing
another's TSD, since all data lives in the same memory space. ARM v9.8's road
map details FEAT_TPS and FEAT_TPSP, "Thread Private
State Checking" for EL0 and EL1/2 (respectively), using two new register sets
of TP[MIN/MAX]n_ELx, defining bounds in memory where TSD
resides.
TASK_CRASHINFO codes:
#define TASK_CRASHINFO_MB 0x841 /* struct crashinfo_mb */ #define TASK_CRASHINFO_CS_AUXILIARY_INFO 0x842 /* uint64_t */ #define TASK_CRASHINFO_RLIM_CORE 0x843 /* rlim_t */ #define TASK_CRASHINFO_CORE_ALLOWED 0x844 /* uint8_t */ #define TASK_CRASHINFO_TASK_SECURITY_CONFIG 0x845 /* struct task_security_config */