Hardware security


If you can boot from an SD card you trust, yes you could use that to read the internal eMMC, verify checksums and reflash if necessary. That may be the best defence the Pyra offers against "evil maid", and that is a way easier procedure than with most laptops, which unconditionally boot from internal SPI flash *before* you can boot from any external drive (malware could already be running while you try to verify or reflash).

Technically, the Pandora always initialises off code in the internal flash which supports SD cards as well as ubifs and is able to load and pass the process counter off to code from any source. To bootstrap any system you need to first run something that can grok SD cards before you can boot off an SD card, and that code could theoretically be malicious.
 
like like like like like. verry interesting topic!
 
Technically, the Pandora always initialises off code in the internal flash which supports SD cards as well as ubifs and is able to load and pass the process counter off to code from any source. To bootstrap any system you need to first run something that can grok SD cards before you can boot off an SD card, and that code could theoretically be malicious.

No, you can force the Pandora to boot from the left SD Card slot, ignoring the internal NAND completely by holding START while switching it on.
This is pretty useful, otherwise you'd have a brick if the device is configured to boot from the NAND and the bootloader is missing from there...

It will be similar on the Pyra.
 
Hmm, I forget the details, but someone did explain the steps in the bootloader to me once. There must be some code that can grok the FAT/ext filesystem and the autoboot.txt/boot.scr file before it can boot from SD, and I kind of expected that to be in flash of some sort (possibly a tiny bit of NOR flash in the SoC so it can be addressed directly and doesn't need to be copied to RAM by something first), but it's possible it's etched into the CPU as something like mask ROM - it's not something that can ever really have a security hole in it, since it's designed to give you bare metal access, and that beats root account access or anything else.

But now I am wondering exactly what Notaz reflashed in the 1.73 update that let slower/larger SD cards be used.
 
must be some code that can grok the FAT/ext filesystem and the autoboot.txt/boot.scr file before it can boot from SD

Right, baked into the SoC must be some microcode that can access various boot devices, understand MS-DOS partitioning, and FAT just well enough to load the MLO. The MLO probably implements the same functionality to load uBoot, which does all the rest - the files autoboot.txt/boot.scr are configuration for uBoot. So, whatever's inside the SoC is probably quite similar to the MLO, and I think that is only a tiny amount of code (I don't have a Pandora to check).

That code in the SoC is probably not replaceable, or else you'd be able to permanently brick it, and it would be a security issue too. The chip designer might allow signed microcode updates, but that adds a lot of complexity, and I hope they decided it wasn't worth it and didn't bother. It might be one-time programmable in the factory.

The situation with modern laptops, with UEFI and "Secure Boot" - trying to implement a 2000+-page specification - has been a long history of security flaws. Unless you physically open the laptop, attach a clamp to SPI flash and rewrite it, you are otherwise forced to trust UEFI, its security, and that it is not tampered with (since malware could hide itself in there permanently).

In the boot sequence, malware in the early stages can be harder to detect and eliminate, but might be limited it what harm it can do (especially if it is limited in size); malware that loads later on can be larger, more intelligent, and better make sense of data in memory, and do much more harm. So I don't worry much about microcode in the SoC that handles the very start of the boot process.

The brilliant thing with the Pandora is, and with the Pyra will be, being able to completely bypass at boot the internal eMMC, the MLO, uBoot image, kernel, initramfs - and be able to boot trusted ones from an external SD card. It minimises the amount of stuff you *have* to trust, when you first receive the device, or any time you suspect it was tampered with and want to reset it to factory state. This gives me a lot of confidence in its security because I no longer *have* to trust any of those things (a smaller Trusted Computing Base).

But now I am wondering exactly what Notaz reflashed in the 1.73 update that let slower/larger SD cards be used.

I guess that just updated uBoot, on the internal eMMC.

I'd like to produce an SD card image for verifying and/or reflashing the early boot bits on the eMMC, once I eventually get hold of a Pyra. Would be equally useful as either a repair or security tool.

Or a very secure way to use the Pyra might be: to only ever boot from removable SD (by holding START+POWER buttons), as then you could turn the whole internal eMMC into encrypted (and tamper-proof) storage for the OS and your data. I love security, as you can probably tell.
 
There was a laptop that had as part of the UEFI would open a network connect to the manufacturer and get a list of malware to check for and if it didn't find it on the system to install it.
 
security.png
 
There must be some code that can grok the FAT/ext filesystem and the autoboot.txt/boot.scr file before it can boot from SD, and I kind of expected that to be in flash of some sort (possibly a tiny bit of NOR flash in the SoC so it can be addressed directly and doesn't need to be copied to RAM by something first)
First step is the boot ROM. It is ROM, not flash of any kind, hard wired and unalterable. It is tiny and has just enough smarts to copy 64k from a specific point on the data source into RAM; this is called the X-loader, typically named MLO. Two things to note here: first, it has no concept of filesystems or anything like that, it literally just copies from X to Y from the selected data source directly. This is why the creating a bootable SD card must follow precise steps, with the first partition being FAT32 with specific block sizes and MLO being the very first thing copied onto it, so that the MLO will be placed where it's expected to be. Second thing is that this RAM exists on the CPU, this is not the external RAM, it is literally only 64k in size (at least I remember it being 64k, but could smaller); at this point in time the boot ROM has no knowledge about anything outside of its tiny ROM, tiny RAM, and the 64k it copies into it from a data source.
The second step, having copied the X-loader into RAM, is to run that X-loader. This is bigger. It has enough room to mount actual filesystems and navigate them, and the logic to look for and initialize various hardware (ie, the actual external RAM). Having done this, it looks for the boot commands, loads the uboot into external RAM, and jumps execution there. uboot takes over to load the kernel and everything else.
By setting different pins to high you direct the boot ROM on what source to load from: on the Pandora, the pin for "boot from SD card" was also connected to the start button. Presumably the Pyra will be done similarly.
 
First step is the boot ROM. It is ROM, not flash of any kind, hard wired and unalterable. It is tiny and has just enough smarts to copy 64k from a specific point on the data source into RAM

Brilliant! That's the simplest and best thing that I could hope for. The Pyra has incredible security properties then, if used the right way.
[doublepost=1463011215,1463010509][/doublepost]New question: what entropy sources are in the Pyra, that Linux will be able to use? Especially on first boot, when it needs to generate SSH host keys for itself (and hopefully generate different ones than every other device does). I think the OMAP5432 has a HW RNG but I'm not sure it will be used/supported?

Unless there's something robust, the user could be challenged to a game of Pong, using the volume control as paddle, while it reads entropy from the ADC attached to that potentiometer... ;)
 
Unless there's something robust, the user could be challenged to a game of Pong, using the volume control as paddle, while it reads entropy from the ADC attached to that potentiometer... ;)
Well there are accelerometers as well...
 
Last edited:
We were already discussing it. Pong and breakout are two that I am looking forward to.
stevenc99 wasn't suggesting it as an actual game in this case, just a mini game on first boot to get the user to input some randomness for generating keys.
 
stevenc99 wasn't suggesting it as an actual game in this case, just a mini game on first boot to get the user to input some randomness for generating keys.
Right, but I was replying to Elw3's comment which only quoted the game part...lemme nest the quotes for you (I wish it was enabled by default for at least a couple posts, and older ones were hidden in spoilers):
the user could be challenged to a game of Pong, using the volume control as paddle
We definitely need this for real.
 
Last edited:
stevenc99 wasn't suggesting it as an actual game in this case, just a mini game on first boot to get the user to input some randomness for generating keys.
Don't forget the nubs too... gyros + nubs could yield varying points in a 5th dimensional space. Add compass, barometer, gps... 10 dimensions to generate a seed?
 
Right, but I was replying to Elw3's comment which only quoted the game part...:
Yeah, I know. I may have literally responded to you but it was a followup to both. You didn't need to pyramid the quote, he literally posted right before you, I saw it.
 
Back
Top