Legato Read Only R/O

The Legato can be built as read-only (R/O) This is done by setting the variable READ_ONLY=1 as argument to make. In this case, both images RW and RO are generated.

Note
This is the default for ar759x and ar758x platforms.

It also possible to force the built as read-write (R/W) by setting the variable READ_ONLY=0.

What is Legato R/O
The Legato system tree is built and deployed into a squashfs or ubifs image. This image is standalone and is not modifiable. Everything required to run Legato is provided during the build time.
When freshly installed, the Legato is fully ready and no further installation or configuration operations are expected.
The Legato R/O is safe of any write to a R/W partition on a flash device. This mode is typically to be used for flash devices mounted in R/O.

What is Legato R/W
The Legato system tree is built, but some installation operations need to be performed at the first startup of a freshly installed system. Also, to run these operations, Legato is expecting a R/W partition to post deploy and finalize its configuration steps.

Build:
By default the targets ar759x and ar758x are R/O. For these platforms, two images R/W and R/O are created in the build/... directory.
The images suffixed with a _ro, ie, legato_ro.cwe, legato_ro.squashfs, legato_ro.squashfs.ubi are R/O and the others suffixed with a _rw, ie, legato_rw.cwe, legato_rw.squashfs, legato_rw.squashfs.ubi are R/W. The images without suffix are symbolic links to the R/W images: legato.cwe, legato.squashfs, legato.squashfs.ubi.

Restrictions:
The Legato ReadOnly feature is introducing the following restrictions:

  • The sandboxed applications are only launchable if and only if legato has a write access to /etc/passwd and /etc/group. If these files are not writable, the applications uid and gid will not be created and the related applications are not usable.
  • To prevent the dynamic installation or removal of legato applications.
  • To prevent single application update through AirVantage.
  • The modifications of the config-tree remain volatile inside its cache and are not physically written to flash.
  • Legato should avoid to modify files into the root file-system (/etc/passwd, /etc/group) because the root becomes may also R/O.
  • The cache of ld.so is dymically generated by the legato startup script to add the pathes to the Legato libraries and customer Legato libraries. A bound mount is done to /tmp/ld.so.cache for /etc/ld.so.cache. This is because the Legato system tree image may be updated without updating the rootfs.

Impacts
The Legato ReadOnly feature will introduce the following impacts:

  • The whole Legato system tree should be installed by flashing the Legato in a partition partition in once operation.
  • The usage of app runProc will fail for sandboxed applications if legato fails to create uid/gid for these applications.
  • Reject the usage of app install or app remove.
  • Reject the usage of the update tool.
  • If some specific users or groups are required for Legato, they should be created at build time (Yocto), because the root file system is also R/O and dynamically modifications of /etc/passwd or /etc/groups is impossible. This should be handled by the supervisor and fwupdate daemon of Legato.
  • Files requiring to be acceded in WRITE should be located into /tmp or into the customer dedicated R/W partitions, if any.
  • Files located inside the applications trees should be opened by their relative path and not by an absolute path.
  • The smsInbox application and others applications using /data for recording data may not work until /data is located into a RW partition or applications are adapted to use another RW location.
  • The applications, service daemons and tools need to be added into the default_readonly.sdef or <target>.sdef file in the way to be compiled and deployed into the whole legato system tree.

Setting SMACK labels:
Because the Legato directory tree is read-only, the SMACK labels need to be set during the build time.
This is done by fixing labels name and value to the variables SMACK_ATTR_NAME and SMACK_ATTR_VALUE located into the targetDefs.<target>.

For example, the variables set in the targetDefs.ar759x file:
# SMACK attribute name and value (optional)
# If set, SMACK attr will be set at build time
export SMACK_ATTR_NAME=security.SMACK64
export SMACK_ATTR_VALUE=*

Copyright (C) Sierra Wireless Inc.