[From the last episode: We saw how updates can be performed securely.]
OK, so you’ve got your IoTThe Internet of Things. A broad term covering many different applications where "things" are interconnected through the internet. device and it’s set to be securely updated. Good job. But… no softwareIn this context, "software" refers to functions in an IoT device that are implemented by running instructions through some kind of processor. It's distinct from "hardware," where functions are built into a silicon chip or some other component. is perfect. What if there’s something dreadfully wrong with the update, and the company didn’t catch it before they shipped it to you?
Think that can’t happen? Not only can it, it has happened. Here’s one example – a couple of years old, but it still illustrates the point. It represents a worst-case situation where an updated device becomes completely unusable – it becomes as useful as a brickUsed as a verb, indicates taking a device that performs some function and eliminating or disabling that function. It’s considered no better than a brick at that point.. Yes, “brick” is a noun, but here in techlandia, we have verbed that noun: The device in this instance was bricked.
A bad update doesn’t have to be that extreme. Perhaps something that used to work stops working. Or perhaps some new securityRefers to whether or not IoT devices or data are protected from unauthorized viewers. flaw is introduced. (I know, updates are supposed to close security holes, but it’s possible to open them too.) The point is, you don’t really want that update. And the company that sent it wants a redo.
Except that you’ve already applied the update. The new software is in your systemThis is a very generic term for any collection of components that, all together, can do something. Systems can be built from subsystems. Examples are your cell phone; your computer; the radio in your car; anything that seems like a "whole.". How do you get it out? Specifically, how do you get back to what used to be working before the update?
Room for New Features
What we’re talking about here is called a rollbackWhen talking about software updates, this refers to a situation where a new update fails and you want to revert to the old version.. And there are a number of ways that might work.
Let’s say you’re doing your update, and, for some reason, the update fails. Are you now stuck with a brick? You’re not on the old version anymore, but the new version isn’t in yet either.
Here’s where a rollback is useful. If the update doesn’t work, then you roll back to the prior version. Sounds simple enough, but having that capability comes with a cost. And many devices aren’t willing to impose that cost, so they don’t have rollbacks.
The cost comes in memory. All of these devices need memory. Part of the memory is for data – say, sensorA device that can measure something about its environment. Examples are movement, light, color, moisture, pressure, and many more. measurements and such. But a huge chunk of the memory will simply be there to hold the software. It will be stored in some kind of memory that sticks around even with the power off – usually so-called flash memoryA type of memory that can retain its contents even with the power off. Thumb drives use flash memory. (which you also find in thumb drives).
Designers need to anticipate how much memory they’re going to need and build that in. One of the considerations, for example, is that the software may grow with updates. Remember that garden device that started out measuring moisture but then was updated to measure nutrients as well? The memory needed for just the moisture measurement may be smallish, but they have to make sure there’s room for the new updates with the new features that use more software. That leftover space is sometimes called headroom.
Room for a Rollback
Why not just make oodles of memory available, just in case? Because oodles cost more than not oodles. The tradeoff is ultimately in the price you’re willing (or unwilling) to pay when you buy the device. So a designer might not opt for oodles, but might, say, figure out how much memory they’re using and, oh, double it for good measure. If the cost allows it.
OK, so, now you have enough memory for your current software plus any extra that you might get in updates. But how does the update actually proceed? Well, when you get the update, it’s going to be stored in memory. Let’s say they doubled the memory based on the first version of software, and now you’re getting an update that’s 10% bigger. Not huge; it will certainly fit within the doubled memory.
But when you store that new software, where in the memory is it going to go? Well, in the space that’s already there – which has the old software in part of it. With flash memory in particular, you have to erase it before writing new data into it. So when the update comes, you’ll erase most of the old memory contents and replace it with the new contents.
But what if there’s a problem with that last part? You want to roll back to the old version – except that the old version has been erased to make room for the new version. You’d literally have to get the old version over the air from the factory. In the prior linked door-lock example, the new version couldn’t communicate. So there was no way to get back the original code.
Point Me to the New Code
To provide for a local rollback, you need enough clean memory to put in the new code without erasing the old code. Somewhere in the system is an addressWhen referring to memory, a binary number that shows where, within some memory block, the data you want is located. If you want to read or change that data, you have to give the address so that the right data is read or changed.: it tells the system where in memory the code starts. Such an address is often called a pointerA variable that, instead of holding data, holds an address where data is located. That is, it "points" to the data instead of being the data. because it points to the starting place. In a rollback situation, one way to handle this is to keep the old software and pointer in place. You install the update, and then, only if everything went fine, you change the pointer so that it now points to the start of the new software. On the next startup, the device will load the new software.
Once you’ve done that, what do you do with the old software? Well, you could erase it, creating space for yet another update. But what if it turns out that there’s a problem with the new update? In other words, the update process itself worked fine, but the new software has a problem. If you kept the prior version around, you could simply change the pointer back to the old version and, voilà: you’ve rolled back until a fixed new version comes around. If the old software had been erased, you couldn’t do that.
So that could be handled by keeping the old version around until a second update arrives. Then you erase the first version while you’re still running the second version. The new update (which makes it the third version) goes where the first version used to be before it was erased, and, if the update works, now the pointer is changed to this new version. The second version is still kept around, in case a future rollback is needed.
Multiple Versions?
What if you wanted to keep more than one version around? Just in case? Well, as you can tell, that’s going to require a lot of memory, and that’s probably going to be a price issue. A company could certainly decide to do that, but it’s unlikely that you’re ever going to want to roll back more than just one version. So the payoff for that extra cost probably won’t be there. Like I said, many devices don’t even have room for one rollback, much less more than one.
Just as a reminder, these update options are built into devices, and the factory controls the whole thing. There’s nothing you specifically can do to affect these choices – except perhaps to ask your salesperson when you buy it (and hope that he or she knows the answer).
Leave a Reply