ubuntu-phone team mailing list archive

[Steve Langasek <steve.langasek@xxxxxxxxxxxxx>]

Hi all,

Many thanks to Chris for raising this important topic.

As Alex mentioned, he and I had chatted earlier this week about the
importance of keeping a single Ubuntu root image that's common to all
devices.  This is something that we need to hold the line on; allowing
individual OEMs to have custom root images - as opposed to having their
device-specific logic in their device image - isn't scalable, and we need to
ensure that anything that currently requires us to add device-specific logic
to the rootfs is treated as a bug to be resolved.

Now, there's also an inevitable tension between the need to keep a single,
device-independent rootfs, and the need to support arbitrary hardware on top
of it.  Some of this should be addressed by providing well-defined interface
hooks for the device image (just as we have already agreed to do for the
carrier customization image).  In some cases, though, I think we should look
closely at whether the per-device customizations should actually be allowed,
or whether this is just an expedient solution that's going to cause us to
pile up the technical debt down the line.  For instance, many of the
per-device files included in the rootfs today are related to the use of
non-standard, non-upstreamable kernel drivers.  I'm sure some of these will
be necessary, but I don't know that it's a good idea to allow unbounded
kernel driver divergence for production Ubuntu devices.  Should we actually
need per-device udev and apparmor rules, or is this simply opening the door
for us to repeat Android's mistakes?

I'm not saying that per-device udev rules are out of the question - and in
fact, I think that's fairly easy to support, in the grand scheme of things.
I just think we need to keep the big picture in mind when evaluating such
solutions.

On Thu, Jan 16, 2014 at 07:46:57AM -0600, Jamie Strandboge wrote:
> > One thing I forgot to mention on the apparmor bits is if the policy uses
> > #an include file or directory, that include file or directory must
> > exist. apparmor-easyprof-ubuntu makes sure that
> > /usr/share/apparmor/hardware/* exist, which is why packages are then
> > free to drop files in there.  We could make the
> > /usr/share/apparmor/hardware/* read/write on the image though, and the device
> > tarball can sprinkle policy files in there. We could also ensure that
> > /custom/.../apparmor/hardware/* exists on all images (apparmor-easyprof-ubuntu
> > could create the directories), but that seems less tidy.

> > Also, the OEMs can of course work with us to add the policy to the packages
> > before hand, but I understand this may not always work.

> Sergio reminded me that the unpack of the device tarball happens during
> the update phase, before we go to readonly.  As such, wouldn't it be
> reasonable to stick with the current plan in:

> https://lists.ubuntu.com/archives/ubuntu-devel/2013-September/037654.html
> https://bugs.launchpad.net/ubuntu/+source/lxc-android-config/+bug/1197133

Currently, our system image updates always apply the root image and the
device image to separate heirarchies (indeed, to separate filesystems).  If
we allow the device image to modify the root filesystem, we introduce a
substantial risk of file collisions at some point down the line, or even
just of modifying parts of the system that are not meant to be modified, and
a QA nightmare will result.

The way to ensure that no one at any point tries to take a shortcut with the
device image is to brick off the shortcut.  I.e., establishing a
well-defined list of hooks the device image can use to modify the system
behavior, and supporting hooks either by a standard bind mount into the
system path, or by extending the various components of the system (udev,
apparmor, what have you) to look in an additional path (e.g., under
/vendor).

This list of hooks will in all likelihood evolve over time, but the
per-device files identified on the current rootfs are a good starting point.

> and ship the apparmor device accesses as part of lxc-android-config, and
> just have OEMs drop their udev rules in /usr/lib/lxc-android-config/ and
> their apparmor device accesses in /usr/share/apparmor/hardware/....  The
> porting guide[1] has language for modifying lxc-android-config for these
> things already-- perhaps it should be updated to include instructions on
> using the device tarball mechanism?

Is it reasonable to make /usr/share/apparmor/hardware a bind mount (or
symlink) to /vendor/apparmor on the touch devices?

On Thu, Jan 16, 2014 at 03:17:13PM +0100, Oliver Grawert wrote:
> hi,
> Am Donnerstag, den 16.01.2014, 09:08 -0500 schrieb Chris Wayne:
> > My point is that lxc-android-config should even only have *generic*
> > container bits.  Anything and everything that is device-specific
> > should not be in the rootfs

> which is currently technically impossible ... i.e. we need the udev
> rules per device ... while these could live in the device zip, they
> would still be copied into the rootfs unless we patch udev to actually
> look in /system/foo/bar or whatever ... 
> ...and i guess apparmor is similar here since it needs to set
> permissions for hw specific devices that vary by model.

> even if we ship them in the android tarball (which as i mentioned
> elsewhere is a lot more effort to rebuild for a single change), they
> have to live in the rootfs after all.

In fact, we already patched udev once to look at picking up firmware files
from /vendor/firmware and /system/firmware before we decided this wasn't
actually necessary (and even harmful, because we didn't want udev loading
firmware if ueventd had already loaded it).  And we've even talked about
autogenerating udev rules from ueventd blocks (though this seems to have
stalled with me for quite a while... sorry about that).  I see no reason we
couldn't / shouldn't add /vendor/udev/rules.d, or even /run/udev/rules.d, to
the udev path to handle device-specific rules in a way that preserves our
hardware-independent, read-only rootfs.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@xxxxxxxxxx                                     vorlon@xxxxxxxxxx

Attachment: signature.asc
Description: Digital signature