How does the Pyra install the OS?

[Grench]

Pyra will have two primary uboot targets (internal eMMC, left SDXC card).
uboot cannot live within an encrypted volume. I don't know if it can launch an engine to utilize an encrypted volume.
Pyra will ship with the OS pre-installed to the eMMC.
The eMMC will ship as a single partition with both uboot and the OS in it.

To create an encrypted OS on the eMMC, then, the shipped OS will need to be overwritten.
An SD card with uboot and the OS installer in the left SD slot will boot the unit.
The user can then repartition the eMMC to two (or more) partitions:
-uboot can have it's own outside of decryption
-an encrypted volume can be created for the install target
User installs the Os from the SD to the encrypted volume.

The part I'm not sure on is whether or not uboot can launch an OS that resides in an encrypted partition or if you would need a tiny OS core that boots, opens the encrypted volume, transfers control.

 

[azz]

Pyra will have two primary uboot targets (internal eMMC, left SDXC card).
uboot cannot live within an encrypted volume. I don't know if it can launch an engine to utilize an encrypted volume.
Pyra will ship with the OS pre-installed to the eMMC.
The eMMC will ship as a single partition with both uboot and the OS in it.


The part I'm not sure on is whether or not uboot can launch an OS that resides in an encrypted partition or if you would need a tiny OS core that boots, opens the encrypted volume, transfers control.

Does this mean that OS is not installed in the hardware itself, but in the MMC card? And thus the OS can be by putting it out from the Pyra? If that's true, that would be very nice. Also, there is a second MMC, which I assume is targeted for additional storage.
[doublepost=1492534592,1492532697][/doublepost]I found this on the... well the internet of course:
I don't have the knowledge to know all what they are saying, but the following quote gives hope:

"The default memory layout of the Freescale U-Boot port can be modified to meet the encrypted boot requirements."

Please reade more on this matter: https://community.nxp.com/docs/DOC-332147

IF it's possible to have an fully encrypted OS, I would encourage the ones who are responsible for to implement it, or make it at least as an option.
My main reason to have a portable GNU device instead of a "Don't be evil" device, is because of data integrity.
And it gives me more confidence when it has a proper data encryption.

 

[TrashyMG]

Does this mean that OS is not installed in the hardware itself, but in the MMC card? And thus the OS can be by putting it out from the Pyra? If that's true, that would be very nice. Also, there is a second MMC, which I assume is targeted for additional storage.

the eMMC is a chip soldered on the CPU daughter board. You can run an OS off other the other SD card slots, USB or the SATA port. It just requires u-boot to be on either the eMMC or Left SD card slot.

It's likely you can boot an encrypted OS on an SD card, you just need to customize the u-boot boot environment to do so, it's not an easy turn key solution.

 

[Grench]

Does this mean that OS is not installed in the hardware itself, but in the MMC card? And thus the OS can be by putting it out from the Pyra? If that's true, that would be very nice. Also, there is a second MMC, which I assume is targeted for additional storage.

Sounds like there is some confusion - I'll try to help clear it up. Someone else should feel free to correct me if they know better.

The Pyra has 4 native media devices not counting USB and eSATA. They are:

1. Internal eMMC. Essentially this is a soldered in-place SSD equivalent. This is where the shipped OS will reside. uboot can live here. This is not a removable MMC card. It uses a double width MMC data path - which may be where the confusion starts. Think of the eMMC in the same way as the on-device storage in your cell phone. It is where the OS resides, but is large enough to hold some additional programs & data. This is the -fastest- media device on the Pyra.

2. Left SDXC slot. This is the 2nd place where uboot can live. You can thereby uboot with removable media. If you want to replace the OS on the eMMC, this is the slot that you would boot from in order to do that.

3. Internal(ish) microSDXC slot. This is behind the battery and lives in the same cage structure as the SIM slot in an over/under fashion. An OS can live here, but uboot may not be able to - it is unclear if the presence of a microSDXC flips the uboot check from the eMMC to the microSDXC. It shares pins with the internal eMMC and a MUX electronic switch flips the data lines between this and the internal eMMC. The original idea was so that the internal microSDXC presence detection would disable the internal eMMC. Later one of the system designers thought it should be possible to make the switching dynamic so both could be used in a single session. Enabling dynamic switching, though, would require more post-shipment software development. If you intend to be able to pull all removable media and have a 'clean' device, put your OS here and ignore the eMMC. The drawback is decreased data speeds when compared to the eMMC - how much slower is yet to be determined.

4. Right SDXC slot. In theory an OS can boot from this IF the uboot has been found on either the internal eMMC or the left SDXC slot. Otherwise it's pretty much a great place to house data. It could be somewhat slower than the other storage devices.

I found this on the... well the internet of course:
I don't have the knowledge to know all what they are saying, but the following quote gives hope:

"The default memory layout of the Freescale U-Boot port can be modified to meet the encrypted boot requirements."

Please reade more on this matter: https://community.nxp.com/docs/DOC-332147

IF it's possible to have an fully encrypted OS, I would encourage the ones who are responsible for to implement it, or make it at least as an option.
My main reason to have a portable GNU device instead of a "Don't be evil" device, is because of data integrity.
And it gives me more confidence when it has a proper data encryption.

I'm betting that the default & shipped configuration will be for uboot and the OS to be installed in an unencrypted partition on the eMMC. Encrypting the boot partition on the eMMC would require repartitioning the eMMC and reinstalling the OS from the left SDXC slot. I would call this an advanced topic. It is something that an advanced user could work out, but would potentially be a confusing mess to do it by default. There isn't anything preventing you from doing this - but it's probably not going to be that way from the factory.

 

[azz]

So, what's left to be easy done is a encrypted home partition.

 

[Grench]

So, what's left to be easy done is a encrypted home partition.

I see it as highly likely that at some point someone will figure out a solid method and create a guide to doing that. It will still require either re-partitioning the eMMC or figuring out a way to shrink the size of the default partition then create a 2nd and re-point home to that. I don't see any 'easy' way to do it, but a guide to walk someone through doing so is feasible. It would still be classified under 'advanced uses' and require the appropriate 'at own risk' caveats. But - since the Pyra isn't going to have anything resembling the locked bootloaders found on many mobile phones, there isn't going to be anything to directly prevent you from being able to do so.

 

[azz]

I see it as highly likely that at some point someone will figure out a solid method and create a guide to doing that. It will still require either re-partitioning the eMMC or figuring out a way to shrink the size of the default partition then create a 2nd and re-point home to that. I don't see any 'easy' way to do it, but a guide to walk someone through doing so is feasible. It would still be classified under 'advanced uses' and require the appropriate 'at own risk' caveats. But - since the Pyra isn't going to have anything resembling the locked bootloaders found on many mobile phones, there isn't going to be anything to directly prevent you from being able to do so.

My opinion on this, is that encryption should be a default option nowadays, especially on expensive device like the Pyra.
So hopefully someone who's experienced on this matter would take effort to make a workaround on this.

I'm the only one who find this an issue?

 

[TrashyMG]

My opinion on this, is that encryption should be a default option nowadays, especially on expensive device like the Pyra.
So hopefully someone who's experienced on this matter would take effort to make a workaround on this.

I'm the only one who find this an issue?

I don't quite see the point honestly, if I kept sensitive data on it sure, but I won't. statistically you're more likely to unintentionally leak sensitive data out through the internet encrypted drive or not. If stolen by a random person the Pyra is such an odd device running Linux, then being ARM based on top of that they would stumble at even using it let alone steal any info on it. If they do have any clue on how to use it, It's more likely they will just do a full OS install process that will wipe the eMMC and start on a fresh install formatting over the encrypted partition. Also generally encrypting will bog down the performance a little bit too.

 

[slaeshjag]

(although the OMAP5 does have a crypto block that should be able to keep up with the eMMC)

 

[Grench]

My opinion on this, is that encryption should be a default option nowadays, especially on expensive device like the Pyra.
So hopefully someone who's experienced on this matter would take effort to make a workaround on this.

I'm the only one who find this an issue?

A potential solution...
Leave the stock OS on the eMMC as is so the device default boots to it should it be out of your control.
Install your secured version of the OS onto a microSDXC card. Special key sequence during uboot should pop up a menu giving that as a choice - reboots should be rare.
What you sacrifice in speed from the eMMC you will gain in security using an encrypted OS on the microSDXC.
If you're ever overly concerned, pop out the microSDXC and the device is still 'usable' but doesn't even house your version of the OS.

The microSDXC slot isn't designed for frequent use though. Alternatively you could do the same as above only use the left SDXC slot as your uboot & encrypted partitions. Far easier to shut down the device and pop out the card that way. If the physical size of an SDXC card is an issue, then use a microSDXC card in an SDXC adapter. The adapter can just hang out in the SDXC slot empty.

Another consideration - if the device is encrypted by default there are disadvantages. If security personnel know that the device is always encrypted by default, they may simply confiscate it. In some regions merely possessing an encrypted device is enough for the rubber hose password cracking method to be applied to it's owner. If installing encryption is an 'advanced option' and not the 'norm', then the device may not get the instant reputation as 'bad'.

From a device support perspective, if someone blows up the OS on the eMMC by deleting a critical file or an update gone bad, fixing it via booting on the SDXC and copying over a file or hundreds is possible. If the OS partition is encrypted, it isn't nearly as easy and may not even be possible. Keeping the default configuration simple for new users and those who want to use it without studying advanced topics in GNU/Linux is a -good- thing for the project. Retaining the ability for advanced users to go 'full secure' is also a -good- thing. Forcing encryption and it's overhead and potential headaches on everyone isn't really a sound plan.

 

[gpb]

This guide should work for us pyrates, too:
http://paxswill.com/blog/2013/11/04/encrypted-raspberry-pi/

They don't use u-boot, but it should only change the location to place the kernel command line.

Repartion the rootfs on eMMC might be a little bit more complicate, but you can do that live within a running system.
Of course, I would prefer a eMMC shipped with two partions (three, if u-boot is "hidden" at some magic offset, I am not sure how the OMAP boots)
A small "/boot" and rest for "/", to make the repartion less error prone. Shouldn't hurt the average user but helps the paranoids.

@TrashyMG while I agree encryption don't have to be the default. I don't think it's a good idea to trust "Linux encryption". Even if that worked one time for me. Lost my "Linux encrypted" Laptop, but got it back a few days later from the police. Checked the logs and saw someone tried to login and finally gave up. That was the point in time, when I started to encrypt "/".