[Dev] [RFC] Tizen system rollback

Stoppa, Igor igor.stoppa at intel.com
Sun Dec 1 21:21:54 GMT 2013

On 30 November 2013 04:22, Carsten Haitzler <tizen at rasterman.com> wrote:


> i think that your cases, while they do exist, are for a shrinking mindset.
> more
> and more operators don't lock devices even with contracts. they use actual
> contracts and legal means for that. it's a practice that is in decline.

well ... this might be a matter of perception - I'd rather not get into a
debate of
I think/you think

unfortunately I'm not able to provide hard data about the use case, I can
only say
that so far this has been a requirement from several/many operators toward

as for the DRM scenario - eventually the user is going to have to make a
> choice
> - older software with bugs or missing features... vs crackable DRM. it
> discourages them and in the end is a small price to pay imho.
> and for both of the above they can still factory-reset anyway, so it's no
> different. if they really want to get around these mechanisms... just
> factory
> reset and presto. (and if its a particular update after that just walk
> forward
> one update at a time until you get there).

I think here you might have missed part of my point.
Which was to drop the concept of "factory reset" and instead replace it with
"reset to latest supported configuration" which might very well be what is
in he factory, but not necessarily what was flashed on _that_ device in the
Rather, it ought to be "what is currently flashed in the factory".

i think one of the most important aspects to realize is that these days
> products are not done and finished when shipped. software is large and
> complex
> and FULL of bugs. always. and always will be. there is nothing you can do
> to
> change that. the most important thing to any producer of a product is to be
> able to update in the field. probably 100% the most important thing. the
> device
> has to be able to function enough to be able to update and "be fixed". as a
> direct bi-product of this, should a fix render the device unable to do
> another
> update after this (a buggy update not tested well enough), you just
> bricked a
> whole bunch of devices out there. a rollback mechanism is an absolute
> requirement of any update-in-the-field mechanism. since the update
> mechanism is
> a requirement, then so is a rollback, by definition. not having such a
> mechanism is living life on the edge.

Sorry, but I cannot agree with this.
You are somehow implying that the end user would not be able to flash the sw
on a bricked device.

Which is not true.

Both x86 and ARM nowadays support the cold flashing of signed FW, through
the execution
of ROM code or some other means that a broken update cannot cripple.
So that's your recovery path, in the extreme case. All is needed is that
the OEM provides
a chain of trust FW->kernel->OS.

Sure, OTA upgrades are nice, but the real safety net lies in cold flashing.
You can equally have buggy rollback mechanism :-)
Of course this applies to the cold-flashing mechanism as well, but in
general that's much simpler
and extremely more tested, so I think it's fair to expect it to be safer.

Final few considerations:

1) given the dynamics of how testing works and the fact that testing teams
have only so many devices available, it's much more likely that cold
flashing gets
significant more testing than OTA. I won't get into details, but it's
obvious that they
have to test many releases and typically the testing starts with flashing a
new image.
Only a limited amount of devices are reserved to real OTA updates, because
requires more complex IT infrastructure.

2) alternatively, one could use cloud storage to keep track of user data
and configuration (like apps installed and related keys) and just rebuild
the user's
customized setup on top of a new build.
Even with a rollback, there will be the problem that the use might want to
re-install whatever
was non-offending and got installed in between the restored snapshot and
the failure that needed reset.
And even re-installing, the user data might be in a non-consistent state.

3) how to decide to take a snapshot?
- let the user choose
- whenever some native app is installed
- before a distro upgrade, like windows does?
- a mixture of the options above

If I were to decide, probably I would either do it all the time or misjudge
and skip it when
it would really turn out to be useful. Probably I would do both :-)

The rollback, to me, makes some sense only in certain corner cases, like:
- no access to broadband connection
- no access to a PC
- hard requirement of 99.999% availability

So it might fit cases where you have rural users, but if we can assume that
device is targeting city dwellers, the reconstruction seems more attractive.
Which is btw, what Apple does.

I'm not saying that it's right just because they do it, but certainly we
will all agree
that they have a large use base which is not necessarily tech savvy and yet
manage to keep the bricking to an acceptable level.

cheers, igor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131201/bfc775eb/attachment.html>

More information about the Dev mailing list