It sounds like this is more or less equal to android's "ADB"?
> “There are several ways someone could do this. An attacker could change the BIOS configuration (for example, with a use of a Flash programmator) when they have physical access to the equipment during manufacturing, storage or usage.
It has to be specifically enabled (with physical access)
No, at least not on stock Android devices. ADB is pretty constrained (SELinux policy, the DAC, etc). It shouldn't be possible to go from there to something like root+unconfined on a normal user device, though of course with additional exploits anything is possible.
If the comments above are correct this is either more like JTAG or is JTAG. That's commonly far more capable, usually providing the ability to do things like read and write arbitrary memory without any kernel hinderance at all (although ARM cpus can typically still protect trustzone memory).
JTAG is a protocol for testing electrical connectivity and package pins, all the debug capability is proprietary vendor extensions. Which is to say that for any retail product, the CPU will have had a fuse set to make it "protected" which typically includes disabling debug JTAG functionality.
It isn't always the case that there's a 'protected' fuse.
Manufacturers seem to have settled on a few different approaches to JTAG:
1/ Leave it open, hope nobody notices.
2/ Leave it to ARM, since modern ARM CPUs have the ability to disable normal and secure world invasive and noninvasive debugging.
3/ Require you to scan in a secret to unlock most debugging functionality.
4/ Fuse off JTAG on production devices.
I can only speak to my experience, but my guess is that for consumer electronics this is roughly in order of popularity with the top option being maybe half of devices and the bottom maybe 10%.
And each of these has problems, so it's no wonder people haven't figured out just one.
Leaving it open is terrible from a security perspective, but for some classes of devices it's also a legal and IP headache. So this is mostly the "couldn't be bothered" set.
Leaving it to ARM is fine as long as your trusted world is sane and the only interesting thing on the chain is your CPU. For many devices this isn't the case. And sometimes bootloaders etc can be made to be insane.
Scanning in secrets is just a bad idea. Provisioning per device secrets is hard, so the "secret" often isn't. Usually it's either something simple (1111... etc) or a serial number, or a serial number ^ a constant, or just the constant. Even where this isn't the case, the secret checking logic is often glitchable or has a viable timing attack. So these frequently fall into the "annoying but possible" bucket for me.
Fusing off JTAG is a mixed bag. It's a huge PITA for manufacturing and RMA so I understand why people don't do it. And you really have to have kind of a lot of logic running on most devices today to get fuses working, so it isn't always as effective as it looks in the presence of glitching attacks. But it is still by far the best option for security and it can be gotten right.
There are also usually various levels of 'disabled', with some parts letting you run eg mbists even in a secured configuration. Obviously, more special cases means more ways to go wrong.
Of course some segments of the market are better about these things than others, so YMMV on the frequency of various approaches.
That's interesting, I figured they would just disable/fuse it at the same time that the software is flashed, and updates need to use a bootloader anyway. What's the legal and IP issues?
Some industries are under various requirements not to be user-modifiable. Some of those requirements are uncommonly applied or are uncertain (wifi routers), but some have serious teeth (export controlled munitions). For devices in those classes they often can't be open without risking liability.
On the IP side, some people really care about keeping firmware proprietary. Leaving JTAG in a mode that is meaningful for debugging that firmware will pretty much completely destroy that. So if you super duper care, you sometimes put clauses in your contracts holding the integrator or OEM responsible if your firmware leaks.
Regarding a race condition, yeah. It's pretty common for devices to come up open, then harden up-- and not just for JTAG. It's also not unique to the register-setting approach.
Almost all modern embedded and non-embedded platforms do not actually have fuses (or separate flash area) for HW configuration and instead boot in some fixed and somewhat sane hardware state and all the "fuse setting" is done by software on each boot.
Typically the "sane hardware state" means enough to execute firmware instructions from somewhere and have some scratchpad RAM. Interesting approaches to this include modern x86 system which boot into state that could not be reasonably described as "sane" (no RAM, MMU preloaded with configuration that should not be normally possible...) and various RISC implementations that boot by loading initial contents of various registers and on-die caches from external serial PROM (which is essentially same way as how FPGA's are configured).
> all the debug capability is proprietary vendor extensions.
To be fair, these are generally fairly well documented for most CPU cores. For the ones that aren't documented, sniffing a proprietary debugger isn't difficult.
> “There are several ways someone could do this. An attacker could change the BIOS configuration (for example, with a use of a Flash programmator) when they have physical access to the equipment during manufacturing, storage or usage.
It has to be specifically enabled (with physical access)