Oxide is designing a computer from the ground up. With this in mind, nothing goes undocumented. While reverse engineering the NXP LPC55S69 ROM they found an interesting piece of undocumented functionality that allowed them to update the ROM. Sadly (or good for attackers), this code is accessible by non-secure, unprivileged user code thus allowing attackers to make runtime modifications to purportedly trusted APIs.
The purpose of a secure boot process rooted in a hardware root of trust is to provide some level of assurance that the firmware and software booted on a server is unmodified and was produced by a trusted supplier. By using a hardware root of trust, we can 100% know if the firmware has been modified or not.
The chip has a set of privileged APIs for directly accessing Flash, putting the chip into programming mode and so on. The issue is that the undocumented API is not considered 'privileged' which allows for the altering of the ROM itself. Luckily, although the ROM can be modified, it does not persistent across boots. So, this does not corrupt the root of trust.
With access to this API that allows for the editing of this ROM, we can give ourselves access to patch part of the privileged APIs. Then, when a secure-mode application calls this API, we control the execution from this point onward. This issue could be pre-mitigated if the memory protection unit (MPU) is turne, which restricts access to specified address ranges.
The rest of the article talks about how to call this API, the reversing process and so on. All of this is interesting but not ground-breaking. The one thing of note is that only 32 bytes can be written via this API, restricting the impact of the bug.
To fully mitigate this issue, new chips without this feature have to be designed. According to the manufactures current chips do not have this functionality. Besides this, choosing to use the MPU fixes this problem from a user standpoint as well.
A DEFCON talk that dives into the details of TrustZone-M can be seen
here as well.