Warning on threats models: ========================== A user with physical access to the lime2 can power it off by unplugging the power cable, and then remove the uSD, replace its software, and then replugging it. While this is a security concern and is a serious concern for some threat models, it might be wise not to handle it, and to instead, mention it very clearly in the documentation. For instance, if the A20 has the ability to check the bootloader's signature, using such functionality can have grave freedom consequences, as the signing key has to be kept secret. If someone else then the users themselves keep that key, then users would not be able to run an alternative bootloader anymore. If the users or software in the control of the user do it, then it has to be robust enough to prevent: - Loosing the key, which would have grave consequences on the usability of the device. - Someone else then the user getting hold on the key. Hardware boot process consideration: ==================================== The A20 have a somewhat less configurable boot process than most SOCs I know of: - It can optionally switch to "USB mode" (Called FEL mode for Allwinner SOCs). This is done by pressing the RECOVERY button on the lime2. - It then have a fixed boot order: uSD0(present)->NAND(if present)->uSD2(absent)->SPI NOR (absent)->FEL(again). According to the linux-sunxi wiki([[FEL]]), you can also enter FEL mode by sending some specific caracters to the UART: "If you have access to the UART already, you can send the character '1' ('2' on some devices) to the device during power-up. Boot1 is initialized using this method." TODO: Try to write a script to do it. Good points of the A20: ----------------------- - User has the freedom to load and run free software bootloaders. - The source code of the bootrom is public and analyzed. See https://linux-sunxi.org/BROM - It's cheap, this permits more people to be able to easily buy it. NAND: ----- The board will only boot on NAND if no bootable microSD is present. The main advantage of the NAND over uSD is its lack of non-free firmware. See bunny's talk about microSD firmwares at CCC for more details. uSD: ---- The main advantage of the using uSD over the NAND is it's ability to contain all the system state: when removed, an attacker with physical access to the device cannot make any persistent software changes. Encrypted rootfs: ================= A way to protect against people arbitrarly modifications of the filesystem could be implemented by encrypting the rootfs. However booting on such filesystem is often done by having non encrypted, easily modifiable software, that opens such filesystem. This software can easily modified to perform evil maid attacks. However here we have a bootrom that we can take advantage of: A) Some lime2 devices do exist with both NAND, and a microSD slot B) Users have a recovery button that they can press. With that in mind, we could have the NAND fully encrypted, and use the microSD slot to hold the necessary software to open that encrypted filesystem. Note that the NAND is not viewed as a block device. Making cryptsetup work with it might be challenging. Alternatively versions of the lime2 do exist with eMMC. This has the same firmware issues than uSD, but tend to be more reliable. Once started, the device could even be rebooted remotely with kexec, assuming that it's robust enough. The main issue with such scheme is that an attacker can simply reboot the board, and access the full RAM content. uboot even has commands to dump the RAM. It is however advised to only reset the SOC and not the full board when doing it. To overcome this issue, we should look if the key retention mechanism of the linux kenrel supports way to store the LUKS key outside of the RAM, like for instance in the CPU cache, and also look if cryptsetup does support that. Reliability considerations: ========================== watchdog: --------- The A20 has a watchdog. If used with the nowayout=1 kenrel parameter, it will reboot the SOC if software(watchdogd or wd_keepalive) doesn't service it. If configured properly, this will reboot the board when it's hanged (for instance, due to a software bug). Special care must be taken to keep it being serviced when the system has a high load. To do that, the "realtime" and "priority" settings of watchdog.conf can be used. Since this is disabled early in the boot process, by the bootrom, this has to be enabled by Debian. Enabling it in uboot might not be a good idea: if a user is interacting with it, it could trigger a reboot at a moment that the user doesn't expect. It could also result in reboot loops if not implemented properly. It's probably wise to instead enable it late in the boot process, to permit the watchdog daemon to actually run. Storage: -------- MicroSD(uSD) tend not to be very reliable. Some research is needed to find out the state of affairs with filesystem support. It might be interesting to investigate how SSD friendly filesystems cope with uSD cards. Note that version of the lime2 do exist with uSD and either NAND or eMMC. Debian: ======= Debian usually have lax default configuration files in order to have a good compatibility with older software. For instance sshd or apache configuration won't have ultra strict ciffer selection. Practically speaking, configuration files of network facing services have to be reviewed. Comparing them with the ones used by security foccused GNU/Linux distributions(Like Tails) or configuration sets made specifically for that purpose (github.com/ioerror/?) Example of files to check: /etc/ssh/sshd_config, /etc/httpd/* USB: ==== The lime2 has both USB host and OTG. The USB OTG can act as both device and host mode. Testing the configuration related to USB host requires to have another device capable having USB OTG which is capable of running a mainline linux kernel. This permits to easily test several lime2 configuration, such as how it reacts to USB Storage, or USB Ethernet. Also note that the well most known device drivers like g_ether, or g_storage are less flexible than the usage of the USB function framework, which is more flexible. With it you can change more than just the USB IDs, and you can even mix userspace and kenrel space implementation of such protocols(like USB Storage). USB Storage: ------------ Look what the debian image will do to it. Will it automatically mount it? => Verify that it doesn't try to execute any software from it. => Note that if it does, but check the integrity of such software before, it then might be prone to TOCTOU attacks. To fix it, you should treat such storage devices as untrusted and verify the software after copying to a safer location. USB Ethernet: ------------- Again, look (with a packet sniffer like Wireshark), what debian will do to it. Will it try to dhcp on it? Does it instead uses autoconf(avahi)? Can the host device influcence it? USB Serial: ----------- Getting a console on it, out of the box is highly unlikely. With ACM, it will appear as /dev/ttyACM0 on the lime2, and would not automatically span a console. TODO: Look if some vid:pid can load drivers with the same /dev/ttyXXX as the A20 serial console. Note that even if no serial console do appear on it, some software typically probe such serial port. Examples of such software include network-manager and other software trying to autodetect if there is a 3G/data modem on the serial port. Other: ------ TODO: look in drivers/usb/gadget in the linux kenrel to indentify the drivers that can easily be used for testing. Note that "usb debug" or d_dbgp is typically used on x86 to get the linux kernel logs when there is no output on the display.