[Dev] [RFC] Tizen system rollback

Stoppa, Igor igor.stoppa at intel.com
Fri Nov 29 17:01:22 GMT 2013


Hello,


On 29 November 2013 17:07, Aliaksei Katovich <a.katovich at samsung.com> wrote:

> hi all;
>
>         I would like to bring to your attention Tizen system rollback
> feature.
>         The idea is to provide possibility to roll back Tizen based system
> to
>         one of several known working configurations. Most obvious
> use-cases are:
>
>         * system update or upgrade failed;
>         * there are regressions introduced by system update;
>         * User does not like features added by system update;
>         * User wants to restore device to first time configuration;
>         * User wants to restore device to factory defaults.
>
>         Proposed architecture is based on device-mapper thin-provisioning
>         capabilities. Please find more details in attached document.
>
>         Before starting actual implementation of this feature I would like
> to
>         hear your opinion about presented architecture and the idea in
> general.
>

I see some reasons why part of these options are unfeasible/undesirable
under certain circumstances:

* user has subsidized device
If a way is found to break the simlock for a certain SW revision, the
operator should
be able to forcibly update all the units deployed in the field that are
made available w/ subsidy.
The user should not be able to rollback to some unlockable version.

* hole in DRM scheme is found
This is a bit similar to the previous case but applies to both locked and
unlocked devices.
If a certain SW version is found to be exploitable for cracking DRM
content, the OEM/operator
should have the means to issue (possibly) non-mandatory irreversible
updates.
I'm not a lawyer but I suppose that neither OEM nor operator have the
rights to impose a SW update
on user-owned devices, however they can easily make it so that the
following user-issued upgrade
prevents any rollback. Preceded by some warning, of course.

So I think there should be means to forcibly and voluntarily permanently
flush the queue or
prevent any rollback, from before a certain version.

Furthermore, I think it's not such a great idea to tie factory settings and
overall device status.
I would prefer if each SW update would also include its own specific set of
"clean slate" configuration values.
Without talking about factory.

Red Hat, afaik, targets different type of products where these issues are
not present.

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


More information about the Dev mailing list