Linux Users Group Bulgaria annual meeting is April 6th in Plovdiv


LUGBG_1

Linux Users Group is annual meeting of people who use and develop with Linux in Bulgaria. The LUG-BG meeting this year is on 6th of April in Plovdiv. The web page of the meeting is here.

I signed for discussion about how to make one ARM Linux system tamper proof.

This is topic which is very interesting for all our OLinuXino customers. OLinuXino is used in many industrial product and machines and the designers want to be sure that no one except them can change the Linux image as these machines pass safety approvals etc and any intervention in the code is illegal.

The Allwinner SoCs do have TrustZone support and also crypto hardware to support a secure boot path for it, but parts of the ARM TrustZone specifications is under NDA and no one has seen it. The secure boot paths are also undocumented. Last time I attempt to receive any useful information about this I got reply: A20 is 5 years old processor and we do not offer technical support for the old processors, when I asked them for info how TrustZone and Secure boot is implemented in their newer processors I didn’t got any reply. My guess is this is something licensed from ARM which they never used so can’t support.

Currently all Allwinner SOC boot without using TrustZone and Secure boot path, they has so caller BROM a small code located in SOC ROM, which initializes the memory and processor registers with some safe values then try to boot from different peripherals. If UBOOT GPIO is held low they enter FEL mode where you can type some commands and load code via USB, else they try to boot from SD-CARD, if fails then try -> internal NAND Flash if fails then try -> SD-CARD2/eMMC, if fails then try -> SPI Flash, if all fails it go in FEL mode.

This is done intentionally so you can never brick your board if internal NAND or EMMC or SPI Flash get corrupted you can always boot from SD-card or USB and replace the image. This of course is big security hole, as anyone with physical access to your board can always replace your images with his own.

The TrustZone and Secure boot path solve this issue, but no one has documentation how this is done on Allwinner SOCs.

I hope to get some interesting ideas how this could be solved, one radical approach is to remove physically the SD-card connectors 🙂

1 Comment (+add yours?)

  1. Bystander
    Mar 19, 2019 @ 21:34:13

    For an in-depth look at TrustZone, the Genode developers have some insights: https://genode.org/documentation/articles/trustzone

    You won’t be able to use it with every SoC. To quote from the article: “Even though the principle TrustZone mechanism for dividing control between both worlds is unified, it is up to the SoC vendor to implement their respective interpretation of security. I.e., the assignment of devices to the bits of a protection controller, the signalling mechanism for violations, the handling of the NS bit by the devices, or additional TZ-related bus components are not standardized. Hence, the mere claim that a product uses TrustZone does not automatically imply the presence of any meaningful security mechanisms. This is unfortunate if the use case of a product has not been envisioned by the SoC vendor.”

    Another quote from the article’s last section about secure booting: “As a precondition for the use of TrustZone for secure booting, the code running in the secure world must be bootstrapped in a secure way, which is SoC-specific. For example, the i.MX family provides a high-assurance boot (HAB) feature that could be used to securely bootstrap the secure world. Alternatively, the secure software could be fixed in a chip-internal flash or ROM at production time. For example, the popular range of low-cost ARM development boards such as Pandaboard come with a fixed ROM boot code that implements several hypercalls and switches to non-secure mode right before starting the u-boot boot loader. Because the internal ROM code cannot be bypassed, there is no way for any system booted on such devices to access device resources that are preserved to the secure world.”

    If you consider removing the SD card connector a solution to your problem, then your problem is easy: just insert the SD card with your checked image and seal it with hot glue. Problem solved. Of course, someone could remove the seal, but if somebody has physical access to the board, he could exchange the entire board. Removing the SD card connector wouldn’t protect from such an “attack”. A steel cage with a good lock might be a solution, depending on your threat model.

    If only the removable nature of an SD card bothers your customers, another way to only boot a known image would be to store a first stage boot loader on non removable storage and have it load a signed image from SD card. That way, if your customers don’t lose their signing key, only they can change the SD card image, because wrongly signed images would not be loaded. Of course, this does not prevent sophisticated attacks like reflashing some soldered chips on the board, but as I mentioned earlier, you need physical access control to prevent such scenarios. If your only problem is to get some certification company’s safety pass seal of approval, the first stage bootloader on soldered flash should be good enough, if only the board and not the whole production site is the scope.

    That said, I would very much like to see an OSHW board, that allows to implement more sophisticated, user-definable scenarios with a sane TrustZone implemention. It would be nice, if you could consult with the Genode developers about choice of SoC and components to connect to allow for such an implementation, if you intend to design a new board in the future, because I would really appreciate Genode support for an OSHW board. At the moment, due to scarcity of resources, they mostly only support i.MX devices, but if there is commercial interest, that could change. I haven’t checked any details, but the recently announced STM32MP1 might be sufficiently openly documented for that purpose, and as an additional advantage comes with a Vivante GPU, which was also used in i.MX devices, which would make porting cheaper (you can read in earlier of Genode team’s articles, that they had implemented a native driver for some Vivante GPU back then). And hey, if you use Octavo Systems OSD32MP15x SiP, you might not even have to put much work into designing a board, besides the breakouts (in case the STM32MP1 proves itself a suitable platform for the endeavour).

    I think, since recent members of Cortex-A (e. g., A7, A53) include hardware virtualisation support, the approach of a small, checkable base and the virtualized execution of uncheckable (because of millions of lines of code) legacy kernels like Linux and their also uncheckable userland stacks ought to be feasible without prohibitive performance degradation and must be considered the right approach. I have no involvement with the Genode team, but follow their work for a long time, and I am very impressed about what they were able to achieve so far with the resources they have.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: