Kuhn: At Least Motorola Admits It
Kuhn: At Least Motorola Admits It
Posted Jul 16, 2010 18:31 UTC (Fri) by richardw (guest, #23638)In reply to: Kuhn: At Least Motorola Admits It by patrick_g
Parent article: Kuhn: At Least Motorola Admits It
http://www.engadget.com/2010/07/16/motorola-responds-to-d...
Posted Jul 16, 2010 19:16 UTC (Fri)
by Trelane (subscriber, #56877)
[Link] (9 responses)
"In reference specifically to eFuse, the technology is not loaded with the purpose of preventing a consumer device from functioning, but rather ensuring for the user that the device only runs on updated and tested versions of software. If a device attempts to boot with unapproved software, it will go into recovery mode, and can re-boot once approved software is re-installed."
*what* it does precisely is rather undefined. That it modifies the silicon, however, is uncontested:
"pecifically, the culprit is said to be a technology known as eFuse -- developed by IBM several years ago -- which allows circuits to be physically altered at the silicon level on demand."
http://en.wikipedia.org/wiki/EFUSE
So perhaps it's not permanent, although the linked article on antifuses indicates that they are.
Conclusion seems to be that more data is needed. :)
Posted Jul 18, 2010 21:37 UTC (Sun)
by jzbiciak (guest, #5246)
[Link] (8 responses)
E-fuse tends to be used for things such as RAM repair (diverting bad RAM columns/rows to redundant good columns/rows), changing the RAM read timing margins, tweaking the requested supply voltage to minimize leakage, that sort of thing. Basically, it just adjusts certain parameters to compensate for both minor defects and process spread, so that you get more (and better!) working parts out of the same batch. But, that happens once during device characterization at the factory. This isn't some Terminator 2 morph-on-the-fly thing that's continually changing once deployed, like Wikipedia's brief summary implies.
E-fuse also gets used for device specific identifiers and keys. Again, that's a "blow-once and then package the part" sort of action. Once all the E-fuses have been programmed, you generally want to lock down any further programming so that a transient device failure (battery glitch, cosmic ray, whatever) doesn't become a permanent one. In the e-fuse controllers I know of, there are "disable future writes" fuses that once blown makes the fuse settings it controls permanent.
E-fuse could be involved in that it holds the device specific ID or key that prevents you from moving a flash image from one phone to another. But, that's a read-only application of E-fuse.
Posted Jul 19, 2010 0:52 UTC (Mon)
by Trelane (subscriber, #56877)
[Link] (7 responses)
Sadly, many times I've said "they couldn't possibly be that stupid" yet to find out that yes, yes they are. *shrug*
Posted Jul 19, 2010 1:09 UTC (Mon)
by jzbiciak (guest, #5246)
[Link] (6 responses)
I did some googling around, and it appears the Droid X is based on a newer OMAP device. I work for TI, but I only have passing familiarity with the OMAP specifics. From what I remember in our other devices, we don't let our customers program e-fuses. We do that for them at the factory. More than likely, they're using M-Shield, which I'm reasonably certain provides for binding content and code to a specific device (ie. a specific Droid X phone) or devices (all Droid X phones), and only allowing signed code to load. E-Fuse is just the technology that allows storing key information in the device to that that can work, kinda like TPM chips do in a PC environment. If that's the case (and it seems the most likely), then it matches up nicely with Motorola's statement that you can re-flash an authorized image to restore the device's original functionality. Take off the tin-foil hat and apply Occam's Razor. The simplest explanation is most likely the correct one.
Posted Jul 19, 2010 2:28 UTC (Mon)
by Trelane (subscriber, #56877)
[Link] (5 responses)
ah, cool. I just toured down there with a group of student from ou/uark a couple of weeks ago (we saw the fab in dmos 6, I think it was).
"From what I remember in our other devices, we don't let our customers program e-fuses."
That's at odds from the report, which says that the bootloader tells the efuse to blow. (follow slashdot->mobilecrunch->mydroidworld forum posting by "ps3droid").
However, the original post that kicked this whole thing off was
"So this post is a mix of hard information and a bit of conjecture on my part (guesses)."
How much is of each is unstated. and I've no idea who this person is or how he/she got his/her information. So the trail grows cold here.
*shrug* The ultimate source of the *fuse* bit is rather misty, so I think I'll have to give mot the credit of the doubt (although I'd give pause before handing over hundreds of my own hard-earned dollars).
"it matches up nicely with Motorola's statement that you can re-flash an authorized image to restore the device's original functionality."
Well actually the quote is that
It doesn't say that the end-user can do the re-install and recovery, only that it will reboot once approve software has been re-installed. Is the efuse one-way, or can it be reset?
"Take off the tin-foil hat and apply Occam's Razor."
"tin-foil hat" tends to be used deprecatingly, and I tend to bristle when people accuse me of wearing a tinfoil hat. Perhaps you didn't mean to be insulting; I'll give you the benefit of the doubt. Regardless, hard experience (e.g. I'm a ps3 owner who bought the ps3 more for the linux than for the games; sadly it's now gotta be 100% linux) has taught me to be very, very, very cautious when I regard what large businesses (and other entities in general, although the power disparity in a relationship with a large megacorp as an end-user is so absurdly large that we mice have to beware of the elephant's feet!) say, and look at the *letter* of what they say, not the spirit.
However, permanent, temporary, carrier-serviceable, or other, the core point that Kuhn makes is clear; Mot doesn't seem to appreciate end-user freedom. and I'm rather fond of maintaining my freedoms.
Posted Jul 19, 2010 3:28 UTC (Mon)
by jzbiciak (guest, #5246)
[Link] (4 responses)
The e-fuse part seems to be pure conjecture based on seeing the name of the technology in M-Shield's key storage (e-fuse), and then thinking it must work like the ones you buy down at Radio Shack, or the thermal fuse you find in an average coffee pot. ie. If you accidentally do something bad with the device, it blows its fuse and refuses to work until the fuse is replaced. The thin description on Wikipedia doesn't help. In my experience with other secure devices I've worked directly with at TI, only the factory (TI) blows e-fuses. E-fuses are used more like jumpers of yore (only shrunk to be on the die) than like the ones in your fusebox in the garage. We architect our software and arrange our manufacturing flows accordingly. (Beyond that level of description, I'm not sure where I cross into proprietary information, so I'll stop there.) The e-fuse technology in OMAP is one-way, if it's at all like the e-fuses I've worked with before. You can't unblow an e-fuse. The fact that the device is recoverable by a reflash implies that nothing truly permanent has happened to the device. Now, I don't know anything about the Droid X and how Mot's "recovery mode" works. This mode should be the same mode the phone goes to if a legitimate update fails, say, due to a power glitch during the update. It may be that to recover the phone requires a special tool or device or bit of software that only Mot's authorized service centers have access to. That's got nothing to do with the e-fuse question at hand, though. It just determines how you restore the phone once it's been flashed with unauthorized code. When I said "you", I didn't mean you specifically. I just meant that Motorola's statement makes it clear that the device isn't a brick, it can be reflashed with the right equipment. There seems to be a lot of wild speculation about that assumes the worst possible motives on the part of Motorola, and what I was saying is that you don't need wild conspiracy theories about Mot bricking phones on purpose to explain this. Refusing to load unsigned code until a service center reinstalls it isn't nearly so malevolent as irreversibly destroying the phone. The former may require a trip to the service center, and the latter requires you to buy a new phone. Motorola built a phone that is meant to be used as a consumer gadget with its walled garden, and it disabled jail-breaking as part of the process. It still allows folks to develop Android apps, but it doesn't allow people to replace the OS image. I imagine this is in part at the urging of the carriers, but I don't know. No doubt about that. It's a consumer electronics market, and that's the default in that space: Everything's a closed, sealed appliance; no user serviceable components inside. I'm not saying that's the way I'd like it to be, I'm just saying that that's how it currently is. It's more than enough for 99% of the people out there who run away screaming from anything too complicated. Folks at work keep asking me why I didn't buy one of several Android phones, including the easily-rooted ones, when I bought my latest phone. I told them I didn't want to have to root my phone to be able to use it in the way that I want. I feel like that's just asking for trouble. It's not really the intended mode of operation for Android, even if I buy a pre-rooted phone. So, I have an N900 instead, and I had a working Xterm straight out of the box, no hacking required. A few taps later, and I have working a working compiler, VPN, Subversion, yadda yadda all on the phone. And I know it's never going away.
Posted Jul 19, 2010 3:57 UTC (Mon)
by Trelane (subscriber, #56877)
[Link] (3 responses)
Right, but the problem is that we have only conjecture about what parts are true, which parts are false/wrong, and what parts are conjecture. :)
"E-fuses are used more like jumpers of yore (only shrunk to be on the die) than like the ones in your fusebox in the garage. We architect our software and arrange our manufacturing flows accordingly. (Beyond that level of description, I'm not sure where I cross into proprietary information, so I'll stop there.)"
No worries; I respect that (I used to work at a large hard drive manufacturer for two summers). It sounds a lot like this is a plausible scenario.
"The fact that the device is recoverable by a reflash implies that nothing truly permanent has happened to the device."
Well, no. Strictly speaking, Mot says
"If a device attempts to boot with unapproved software, it will go into recovery mode, and can re-boot once approved software is re-installed."
How the re-installation can occur is completely unspecified. It could conceivably be that the OP was correct that the software can fuse a selected part in order to require you to go back to the shop and get a new chip, or get a second fuse blown for you (perhaps something like DVD drives do where you get five free reflashes at the store and then it's clear you're a baddie and you have to buy a new phone (or even just a new chip)) It's hardware/software; the primary constraints are laws, consumer (or customer, if they're like me and know and use the distinction) reaction and how much we can pack into a chip before it's too big/consumes too much power. Hooray for digital progress!
"This mode should be the same mode the phone goes to if a legitimate update fails, say, due to a power glitch during the update." It *could* be the same, but we have only supposition.
"That's got nothing to do with the e-fuse question at hand, though. It just determines how you restore the phone once it's been flashed with unauthorized code."
They might be unrelated. They might not be unrelated. We have no [b]data[/b], we have only supposition (and layer upon layer of it). There are definitely scenarios that could involve the fuse, even if the supposition that the fuse is permanently blown is true.
"Refusing to load unsigned code until a service center reinstalls it isn't nearly so malevolent as irreversibly destroying the phone."
Malevolence is motivation and rather tangential to the questions at hand. Rather, the question is what the [i]problems[/i] to us would be. and how problematic having a phone be a brick until you get it to a service center depends on a lot of things, and notably how far and inconvenient it is to get to the service center. :)
To summarize, my current position is that we need a lot more data before we can draw reliable conclusions about anything in this situation. Hopefully mot will be forthcoming with it. I'm very very glad you brought more data to the table. Despite not necessarily being directly transferable to the mot scenario, they're at least indicative about the state of current technology.
"I told them I didn't want to have to root my phone to be able to use it in the way that I want."
I'll drink to that! (Is incidentally why I don't have an iphone; my mac fanatic friends/colleagues said, well just root it to get an xterm and ssh.. riiiiight. "Jailbreaking" is rather a poor metaphor; rather, it should be something like hostage-freeing perhaps, or something involving a raid on a property theft ring and getting your TV back. :)
Posted Jul 19, 2010 9:33 UTC (Mon)
by mpr22 (subscriber, #60784)
[Link] (2 responses)
I would be surprised, given a device equipped to update its own firmware without return-to-base, if they designed it in a way that meant their service department would have to remove the casing, demount the screen, rework the PCB, remount the screen, and reinstate the casing just to recover the firmware if the update glitched. (The manufacturer lockdown module is unlikely to be able to tell the difference between "misprogrammed official firmware" and "unofficial firmware", and a mobile phone doesn't have room for socketed components.)
Posted Jul 19, 2010 9:59 UTC (Mon)
by jzbiciak (guest, #5246)
[Link] (1 responses)
It also seems extremely unlikely that they'd pick the most complicated and likely most expensive chip on the board (OMAP3) and blow e-fuses within it to implement such a scheme. That more or less would translate into needing to swap out the entire PCB that contains the OMAP.
It seems quite sufficient for the device to just check the flash signature and go to a recovery mode on signature failure, especially since TI builds that function into the ROM and CPU (M-Shield, linked above). It just uses e-fuse for key information.
So, while it's technically possible they could have a truly self-destructing phone, it seems extremely unlikely.
Posted Jul 19, 2010 11:43 UTC (Mon)
by Trelane (subscriber, #56877)
[Link]
Kuhn: At Least Motorola Admits It
"The primary application of this technology is to provide in-chip performance tuning. If certain sub-systems fail, or are taking too long to respond, or are consuming too much power, the chip can instantly change its behavior by 'blowing' an eFUSE."
Kuhn: At Least Motorola Admits It
Kuhn: At Least Motorola Admits It
Kuhn: At Least Motorola Admits It
Kuhn: At Least Motorola Admits It
"If a device attempts to boot with unapproved software, it will go into recovery mode, and can re-boot once approved software is re-installed."
Kuhn: At Least Motorola Admits It
That's at odds from the report, which says that the bootloader tells the efuse to blow. (follow slashdot->mobilecrunch->mydroidworld forum posting by "ps3droid").
However, the original post that kicked this whole thing off was
"So this post is a mix of hard information and a bit of conjecture on my part (guesses)."
It doesn't say that the end-user can do the re-install and recovery, only that it will reboot once approve software has been re-installed. Is the efuse one-way, or can it be reset?
"Tin-foil hat" tends to be used deprecatingly, and I tend to bristle when people accuse me of wearing a tinfoil hat.
the core point that Kuhn makes is clear; Mot doesn't seem to appreciate end-user freedom. and I'm rather fond of maintaining my freedoms.
Kuhn: At Least Motorola Admits It
Kuhn: At Least Motorola Admits It
It could conceivably be that the OP was correct that the software can fuse a selected part in order to require you to go back to the shop and get a new chip, or get a second fuse blown for you
Kuhn: At Least Motorola Admits It
Kuhn: At Least Motorola Admits It