Yes, it is required by regulation established many years ago. There is dedicated spectrum for it, so that it doesn't overlap with existing networks. Both the automotive company and the government are entitled to that data. Many cars also use normal mobile spectrum because that is actually available everywhere and works. The explicit scope of use, beyond collecting operational data, is law enforcement and traffic control. Cars can take commands over-the-air via this data link.
This has been pushed by governments for 20+ years. Now that the technology has caught up, automotive OEMs are finding their own revenue-generating uses for this data.
Umm... I'm pretty sure cellular modems have not been _standard_ in all Hondas until about 2018, if in fact they are standard now. My 2019 Honda Ridgeline has only WiFi and bluetooth, not cellular, according to my Hondalink app.
The exceptions seem to be the "Elite" and "Touring" models of Hondas, which started using the Qualcomm Snapdragon 4G LTE cellular modem in 2018 as part of user-accessible telecom services that resemble Ford's OnStar.
It looks like the modem is part of the Telematics Control Unit ($500 to replace). The real question is, when did TCUs start sending personal driving data to Honda? And when did Honda start selling that and other personal data to other companies?
We can't say for sure. I've been guilty of thinking everything I read anymore is AI generated, but then I read my own posts and think they look AI generated too, even though I know they're not, because I wrote them.
> Our guess is that this unknown hardware feature was most likely intended to be used for debugging or testing purposes by Apple engineers or the factory, or that it was included by mistake.
This appears to be used to direct write cache for testing purposes.
It's not an intentional backdoor.
It's more likely an insider leak of some private headers or something that gave someone the info necessary.
Or Apple left too much stuff in the debug info.
It would not be the first time either has happened.
No info one way or another, and I am not a nation-state actor, but if I was and was intending to introduce a back door to some platform, I would ideally want there to be some plausible explanation of it as an innocent mistake so that if/when it eventually got discovered everyone would think: “oh boy someone accidentally left the debug build in for this one” or “oh someone needed a godmode for testing and they accidentally enabled it in production” or whatever, rather than it being right there obvious in the code with no ambiguity. If you’re operating against active adversaries it makes sense to work on the basis that your activities will one day be uncovered and therefore to prepare the cover story ahead of time.
Additionally if you think about it if you’re an insider trying to subvert some system all your changes would still need to go through PR etc so it’s going to be pretty difficult to get some egregious backdoor through review vs figuring out a way to “accidentally” link in a test/debug version of some lib into production or something similar.
But apple has hundreds of debug registers. They have >1000 apple-specific MSR registers in the M3, which can be used to bypass/test lots of things, not just this, if you have enough permissions.
They were historically not locked down for the most part, just undocumented.
Apple has MSR lockdown registers that let them lock down access to MSR's (which only makes it harder, you can unlock access again later, but it means you have to be able to write the lock MSR to unlock them), and the latest kernels now lockdown most MSR's.
XNU also even has code to inject AMCC/DCS/ECC errors for testing.
Almost all of these can be seen from the KDK, and it's been that way for years.
This specific thing being a backdoor is totally implausible as a result. It's almost certainly not the only test mechanism that could be exploited due to some bug.
The CPU registers are MMIO accessible, like the GPU ones, but protected through various mechanisms that the GPU ones are not, by design (the GPU has no IOMMU).
It is much more likely they paid an insider for access to the GPU register names/info, or found it through a leak, and then started trying to see what they could do with the info, than it is that the entire thing, top to bottom, was an intentional backdoor.
I'll go a little further on why i think it's not a backdoor.
If you look at the debug info in the Kernel dev kits, you can see the internal SDK (which has existed forever - i had access to it 2 decades ago when i was working on compilers at IBM, for apple) has chip/register info in it:
Just some examples.
The first one is a header file containing the register names/structures/flags etc for the DART.
The second is for recent p-cores.
etc
Depending on what the kernel uses, sometimes they accidentally leak most of the data (more than once).
So for example, the current XNU debug info leaks the register bits/structure of the hid18 register (a p-core register):
(I put this in a GIST because i am too lazy to try to get the formatting right in-comment)
So you can see the bits of HID18 and what they mean, just from the debug info.
Now, current XNU dumps contain info on 2-3 registers like this out of the thousand+.
But, the header files contain all the data, presumably, on CPU, GPU, DART, etc.
They have also leaked much more before.
Regardless, it is much more likely to me that someone got a recent internal SDK (which again, was at least shared with partners at various points in time), went looking through the header files, and then started testing things out, than it is to me that they engineered a backdoor from scratch into the GPU.
I don't have the app / never have had the app. Android auto only.
Is there an onboard modem with lte?