westernsemico
New member
Hi, apologies if "Technical Support & Questions" is the wrong forum to post this in. The answer I'm seeking is technical even if the question deals with business/legal issues.
I was dismayed to find out that a big chunk of the IMXRT1060 documentation has been moved out of the publicly available reference manual and inserted into a secret "Security Reference Manual". Past experience has shown that documents with this status are simply not available to mere mortals under any circumstances, and the web form business about "type your FAE's name here" is effectively a runaround to avoid being blunt about this fact.
This was not the case for Teensy 3.x's CPUs -- as far as I can tell the public manuals for those devices describe all the software-accessible stuff.
This really troubles me. I've gravitated back towards the microcontroller world as a result of the endless proliferation of secret "trusted processors" like the IME/PSP that seem to have become unavoidable in SoC/desktop/server computing. It was a rude awakening to find that secret coprocessors have made it into the microcontroller world too.
Paul, as a high-volume distributor you have access to this "Secret Reference Manual" (I read through this fascinating thread). Obviously you can't disclose any NXP-confidential information, and I'm not asking you to, but I was hoping you could shed light on two questions:
1. Can you explain NXP's reason for keeping the software API for all this security stuff secret? I can't imagine why they would want to do this. If I were considering designing this thing into some high-volume product that would scream to me "security through obscurity". The fact that so few people are able to review the APIs and do penetration testing against these features is a negative, not a positive. Any idea what NXP was thinking? For the DCP there is *maybe* some kind of export control issue, but that doesn't explain the secrecy in any of the other modules outside of the DCP. The only self-consistent explanations I can come up with sound pretty tinfoil-hatty, so I won't include them here. If they're worried about competitors with enough cash to pay for a maskset and make a clone (i.e. several million $) that kind of money is most certainly enough to get the SRM from one of the dozens of developers who received it: you can buy zero-day exploits for those prices and use them to hack the developers who have the SRM, or just bribe one (not Paul!) for a lot less money.
2. Can we be sure that, so long as we don't need HAB or use SNVS, DCP, the TRG, OCOTP_CTRL, or BEE, and we blow the "complete JTAG disable" fuse, that nothing in the secret Security Reference Manual is relevant to the security of products we design around Teensy4? If we can be sure of that, how can we be sure? If not, isn't that a problem?
I'd also be interested in reading any speculation you might have on why this SRM/CSU/IME/PSP/TrustZone stuff seems to be increasingly crammed down our throats, whether we want it or not. I know you don't have too much clout with NXP, but I would sure appreciate it if their products started coming with a "disable anything that isn't publicly documented" eFuse and a publicly documented commitment that blowing that eFuse will do that. Then the people who need these super-secret features can have them, and the rest of us can be sure that we aren't affected by stuff we're not allowed to know about -- or at least as sure of that as we are about any other assumption whose failure would count as a silicon bug committed by NXP.
Hope this post didn't come off as too much of a rant.
I was dismayed to find out that a big chunk of the IMXRT1060 documentation has been moved out of the publicly available reference manual and inserted into a secret "Security Reference Manual". Past experience has shown that documents with this status are simply not available to mere mortals under any circumstances, and the web form business about "type your FAE's name here" is effectively a runaround to avoid being blunt about this fact.
This was not the case for Teensy 3.x's CPUs -- as far as I can tell the public manuals for those devices describe all the software-accessible stuff.
This really troubles me. I've gravitated back towards the microcontroller world as a result of the endless proliferation of secret "trusted processors" like the IME/PSP that seem to have become unavoidable in SoC/desktop/server computing. It was a rude awakening to find that secret coprocessors have made it into the microcontroller world too.
Paul, as a high-volume distributor you have access to this "Secret Reference Manual" (I read through this fascinating thread). Obviously you can't disclose any NXP-confidential information, and I'm not asking you to, but I was hoping you could shed light on two questions:
1. Can you explain NXP's reason for keeping the software API for all this security stuff secret? I can't imagine why they would want to do this. If I were considering designing this thing into some high-volume product that would scream to me "security through obscurity". The fact that so few people are able to review the APIs and do penetration testing against these features is a negative, not a positive. Any idea what NXP was thinking? For the DCP there is *maybe* some kind of export control issue, but that doesn't explain the secrecy in any of the other modules outside of the DCP. The only self-consistent explanations I can come up with sound pretty tinfoil-hatty, so I won't include them here. If they're worried about competitors with enough cash to pay for a maskset and make a clone (i.e. several million $) that kind of money is most certainly enough to get the SRM from one of the dozens of developers who received it: you can buy zero-day exploits for those prices and use them to hack the developers who have the SRM, or just bribe one (not Paul!) for a lot less money.
2. Can we be sure that, so long as we don't need HAB or use SNVS, DCP, the TRG, OCOTP_CTRL, or BEE, and we blow the "complete JTAG disable" fuse, that nothing in the secret Security Reference Manual is relevant to the security of products we design around Teensy4? If we can be sure of that, how can we be sure? If not, isn't that a problem?
I'd also be interested in reading any speculation you might have on why this SRM/CSU/IME/PSP/TrustZone stuff seems to be increasingly crammed down our throats, whether we want it or not. I know you don't have too much clout with NXP, but I would sure appreciate it if their products started coming with a "disable anything that isn't publicly documented" eFuse and a publicly documented commitment that blowing that eFuse will do that. Then the people who need these super-secret features can have them, and the rest of us can be sure that we aren't affected by stuff we're not allowed to know about -- or at least as sure of that as we are about any other assumption whose failure would count as a silicon bug committed by NXP.
Hope this post didn't come off as too much of a rant.
Last edited: