And so, dear reader, if you know how to disable this landmine — or are merely interested in advancing the state of the art in vermin removal — join us on #trilema!
I went down the rabbit hole and checked out the #trilema channel and it’s associated website. What in the world is even going on on there? It seems like it’s mostly obscene schizophrenic ramblings.
All the conspiracy stuff gave me a chuckle. The author apparently refuses to use x86 “crapolade” for… reasons, I guess.
For sure, the three letter agencies would love to have their own private backdoors into every computing device on the planet but that doesn’t mean all of the manufacturers are just going to hand it to them, even if bribed to do so.
The real reason Google would lock down Chrome devices because they want the devices to stay Chrome devices so that they’re used as Chrome devices so that they can show you ads on Google services. There’s barely any margin on the hardware at all so they don’t want people to buy them just to put Linux on, like I did.
Wow, what a rant. I’m very sympathetic to “people should be able to control their devices”, but this rant is missing a number of key factors:
The author’s assertion that this has to be inserted as an NSA backdoor is a link to them ranting about NSA backdoors on IRC. Yes, “just because you’re paranoid doesn’t mean noone is out to get you”. But it also doesn’t prove they necessarily are…
The author ignores the fact ChromeOS has a security model (and actual, real, historical consumer-level threats to desktop computer users that they are trying to mitigate).
They also seemingly ignore the fact that a 100% open device belongs to everyone who wants to own it, not just everyone with access to Google’s signing keys. The current device requires you to trust Google, their ideal seems to require you to trust everyone.
The author ignores the fact that a quick look at the published cr50 firmware source shows that there are a number of things a Rockchip-based laptop needs from some external microcontroller of this kind, aside from TPM-like functionality (power sequencing, battery gas gauge, etc).
In other words, there are clear and obvious reasons (security and basic functionality) why a small management microcontroller like this needs to exist in a laptop (without requiring an NSA conspiracy to insert it.)
At the same time, I totally agree that it would have been great & less problematic if Google had provided a way for advanced users (who understand the associated risks and loss of security) to disable the TPM-like functionality of this chip (ie Android bootloader unlock or older ChromeOS style). Or even better to provision their own signing key. It’s a shame they didn’t do this[*], although not too surprising given the market demand.
[*] It’s worth noting that even if they had done this, the OP wouldn’t be happy because they still can’t audit the rest of the H1 chip’s firmware, build their own, etc. This is a fair enough concern, but it’s hard to see how Google can mitigate that without either finding a TPM-like chip with a fully open source SDK (…), or provisioning two microcontrollers so it’s possible to physically disable the TPM chip entirely but still have a chip to monitor the battery voltage, make the power button work, etc.
Honestly, part of me would like to see more open-sourcing of these types of security/management chips and ways for knowledgeable users to disable these things. However, it seems that for every user who is genuinely qualified to do these things and decides to do them, there are from 10 to 100 users who can be convinced to go through the unlock process to see some dancing bunnies or something. For every user who is mad that someone else can unlock their system somehow through some Corporate-controlled process, there are 100 users who will forget all of their passwords and get mad that their hardware is now a brick because nobody can help them unlock it. Possibly including the original user mad at corporate backdoors.
master the I2C bus, on which, among other things, are to be found the sound card’s microphone
The cr50 driver they link doesn’t support multi-master, so any I2C bus that the H1 is on is not shared with the main CPU. If the digital microphone is controlled from the main CPU’s i2c bus, it’s on a different physical bus.
I2C (at least the 400kHz version here) doesn’t have a high enough data rate to carry real-time audio. So even if the H1 chip was on the same I2C bus and the H1 could send a control command to turn it on, something would have to be listening in the Linux CPU to capture the audio. And if you’ve already owned the Linux CPU to the point you can enable audio capture, you can probably turn the mic on without separately owning the H1 chip…
Streaming data via I2C (especially on a shared bus with other devices) would still be a massively inefficient way to do this. I’d be surprised if there’s a digital microphone manufacturer who has chosen this over I2S.
The Core Secrets and BULLRUN docs cover a lot of it. They used the FBI to “compel” U.S. companies to SIGINT-enable their products. They use spy tactics for foreign ones. The SIGINT-enabling budget was several hundred million dollars. Compromising companies like AT&T cost around $100 million. RSA was $30 million. Those that don’t cooperate might loose defense contracts. So, you can’t trust any for-profit with big sales to spying-loving governments.
It’s worth noting that companies like Microsoft and Intel voluntarily cooperated with NSA under Trusted Computing Group. There were a lot of tech companies involved in the DRM stuff willingly for many reasons. You might not even have to buy them outside whatever sales or contracts got them there. Google has big, defense contracts now, too, with more expected in the future.
I went down the rabbit hole and checked out the #trilema channel and it’s associated website. What in the world is even going on on there? It seems like it’s mostly obscene schizophrenic ramblings.
All the conspiracy stuff gave me a chuckle. The author apparently refuses to use x86 “crapolade” for… reasons, I guess.
For sure, the three letter agencies would love to have their own private backdoors into every computing device on the planet but that doesn’t mean all of the manufacturers are just going to hand it to them, even if bribed to do so.
The real reason Google would lock down Chrome devices because they want the devices to stay Chrome devices so that they’re used as Chrome devices so that they can show you ads on Google services. There’s barely any margin on the hardware at all so they don’t want people to buy them just to put Linux on, like I did.
Wow, what a rant. I’m very sympathetic to “people should be able to control their devices”, but this rant is missing a number of key factors:
In other words, there are clear and obvious reasons (security and basic functionality) why a small management microcontroller like this needs to exist in a laptop (without requiring an NSA conspiracy to insert it.)
At the same time, I totally agree that it would have been great & less problematic if Google had provided a way for advanced users (who understand the associated risks and loss of security) to disable the TPM-like functionality of this chip (ie Android bootloader unlock or older ChromeOS style). Or even better to provision their own signing key. It’s a shame they didn’t do this[*], although not too surprising given the market demand.
[*] It’s worth noting that even if they had done this, the OP wouldn’t be happy because they still can’t audit the rest of the H1 chip’s firmware, build their own, etc. This is a fair enough concern, but it’s hard to see how Google can mitigate that without either finding a TPM-like chip with a fully open source SDK (…), or provisioning two microcontrollers so it’s possible to physically disable the TPM chip entirely but still have a chip to monitor the battery voltage, make the power button work, etc.
The main issue brought up is that this device allows firmware updates without user authorization or clearing user data.
Honestly, part of me would like to see more open-sourcing of these types of security/management chips and ways for knowledgeable users to disable these things. However, it seems that for every user who is genuinely qualified to do these things and decides to do them, there are from 10 to 100 users who can be convinced to go through the unlock process to see some dancing bunnies or something. For every user who is mad that someone else can unlock their system somehow through some Corporate-controlled process, there are 100 users who will forget all of their passwords and get mad that their hardware is now a brick because nobody can help them unlock it. Possibly including the original user mad at corporate backdoors.
One more piece of paranoia still annoying me:
I2C can transmit realtime audio quite easily using Opus.
Streaming data via I2C (especially on a shared bus with other devices) would still be a massively inefficient way to do this. I’d be surprised if there’s a digital microphone manufacturer who has chosen this over I2S.
[Comment removed by author]
The Core Secrets and BULLRUN docs cover a lot of it. They used the FBI to “compel” U.S. companies to SIGINT-enable their products. They use spy tactics for foreign ones. The SIGINT-enabling budget was several hundred million dollars. Compromising companies like AT&T cost around $100 million. RSA was $30 million. Those that don’t cooperate might loose defense contracts. So, you can’t trust any for-profit with big sales to spying-loving governments.
It’s worth noting that companies like Microsoft and Intel voluntarily cooperated with NSA under Trusted Computing Group. There were a lot of tech companies involved in the DRM stuff willingly for many reasons. You might not even have to buy them outside whatever sales or contracts got them there. Google has big, defense contracts now, too, with more expected in the future.