Flashing From/Interacting With Non-Free Hardware

Hardware Librem 5
7

I appreciate the reflection.

Its frustrating but I guess I have to accept that. Though it would have been nice if purism would have set up a recovery partition or prompted me to set one up.

Agreed on the shades of grey, probably wouldn’t bother with it, thank you for answering these questions.

I appreciate your analysis and explaining that.

Thats interesting, can you explain please? :slight_smile:

I think your right about that.

I think firmware implants (or using devices like this to exfiltrate data from existing implants) could be used as a form of mass-surveillance or cyber warfare. But its really speculation.

In the case of the librem 5 with mostly open firmware (or generally firmware from the companies that are willing to work with Purism), I trust the firmware on the internal eMMC more than the proprietary blob or silicon on the closed-source SD card.

Its an option :thinking:

I’m aware this post is a bit paranoid, I’m frustrated with the situation but it is what it is. Thank you taking the time to respond.

1 Like
8

Too much money, though anything with a similar degree of openness would likely do

1 Like
9

It would be cost-efficient to send your Librem 5 back to Purism under warranty then.

1 Like
10

My understanding is that the boot goes straight from boot ROM (read-only, can’t be compromised in the manner contemplated here) to code loaded from the eMMC drive (software). So there’s no writeable firmware to compromise. It is of course all in the choice of terms. What I am calling “not firmware” someone else may choose to call firmware.

Yes, with the benefit of hindsight.

I guess a recovery partition would have been controversial, given the small size of the main disk (the eMMC drive), and given that for most customers recovery via uuu is acceptable.

Also, at the time of initial release there was no support for booting from the µSD card - and hence they could not sensibly have prompted you to set up a recovery partition on the µSD card (where there can be oodles of available disk space for a recovery partition).

I don’t see why. The eMMC drive contains its own computer running closed-source code, in order to implement the eMMC drive. The standards for eMMC may be open but any actual implementations are just as proprietary as anything else that is closed, just as blobby, as far as I know.

Maybe we are talking at cross-purposes though.

I don’t see why it would be under warranty. The OP broke his/her phone doing something that was expressly advised against by at least one other forum user.

Sending it back for Purism to reflash (if inside the US), and paying for that, is likely to be cheaper than a second phone though.

2 Likes
11

Hey i have few Petitboot machines too. :wink:

2 Likes
12

Thats interesting, and comforting, though is this where the firmware discussed here including u-boot resides?

Also it seems like it can be flashed, so could you clarify what you mean by non-writable?

Yep.

Those are all good points.

I think I had a misunderstanding, I thought the only closed source blobs the L5 had were for the 4G modem, because purism could not find a manufacturer willing to work with them. After looking into it I realized I was wrong. Though I have the understanding the Purism has looked specifically with manufactures who are willing to work with them (lowers risk in my opinion), and stores proprietary firmware on a separate flash chip, I think your more or less correct here. Any differences assessing the threat level would be down to the use case of an eMMC drive vs an SD card. Where and SD card is lower cost and likely to move from computer to computer, the eMMC drive is likely to stay in one machine and is higher cost.

Guess I will find out :person_shrugging:

1 Like
13

I briefly looked into Petitboot after I saw your post, I’m curious, could you elaborate, do you feel this increases the trust level you have in your machine?

2 Likes
14

I think you’ve got the wrong end of the stick here.

There are many places that peripheral firmware could be stored:

  • embedded within the peripheral that needs it itself - and no action by the operating system is required at boot time (the peripheral firmware is already where it needs to be)
  • on a separate, dedicated flash chip that exists largely or solely for the purposes of holding firmware (aka firmware jail) - and the peripheral firmware is copied by the operating system from the flash chip to the peripheral at boot time
  • on the operating system disk - and the peripheral firmware is copied by the operating system from the disk to the peripheral at boot time

The primary goal of Purism’s design is to avoid specifically the third of those options i.e. no peripheral firmware on the disk.

It is also noted that for peripheral firmware that relates to the boot disk, it is difficult or impossible to have the firmware on the disk anyway (chicken and egg problem). So most storage devices opt for the first of those options.

The approach taken will differ from peripheral to peripheral, and from product to product.

Also note that, regarding the first option, it may or may not be possible to update the firmware at all. It is assumed that there is some way of updating the firmware with the second option. It is obvious that the firmware can be updated with the third option.

That’s definitely not right. In any modern computer, there are a heap of blobs, although some of them may be invisible and some of them may not in practice be able to be updated (for a variety of reasons).

At a minimum, the WiFi card has a blob (but the source of the blob differs between the original WiFi card - blob is embedded - and the more recent WiFi card - blob is in firmware jail) - but also the power delivery controller has firmware, the touchscreen controller has firmware, the GPS module has firmware, the smartcard reader has firmware, and of course the cellular modem has firmware. And as discussed the eMMC drive would have firmware. Maybe I missed some.

With all these blobs, and all these potentially hostile peripherals, different strategies are employed to manage that. One of the main strategies is that the peripheral does not have direct access to memory - a communication bus can only be used where the host can only ever be the bus master etc.

Another strategy, as used with WiFi, is that ideally all traffic is encrypted by the host (so even if the hostile blob is snooping, the content is meaningless). The same strategy, as used with disk storage, is that ideally all content is encrypted by the host (so even if the hostile blob is snooping, the content is meaningless). In either case, ideally content is also integrity protected (so even if the hostile blob is maliciously altering content, the host can detect that). By default that does not occur with disk storage although theoretically LUKS has an option for the brave for that.

My understanding is that uboot resides on the eMMC drive. So it is more in the nature of a primary bootloader than firmware. Being on the disk, it can of course be written to.

The terms “flash” and “reflash” are confusing here - because noone ever talks about reflashing a USB flash drive, we just talking about writing to it - even though all of the following are in fact flash storage: NVMe disk, SATA SSD, USB flash drive, USB portable SSD, eMMC drive, SD card, flash chip. There are great differences in how they are accessed but ultimately they are all flash storage.

1 Like
15

This is getting to be a very interesting conversation! :smiley:

Part of my issue here is, Im a software person, the firmware, the chips, etc. to some extent are a scary black box too me. To an extent I dont know the limits, or how really to evaluate their capabilities. I have been able to piece together most of your information here, but it is very helpful that you have laid it all out and explained that its normal to have a combination of these things, thank you.

Does this mean its on the blob is still on the perhipheral in the most recent version? Im not really familiar with firmware jails.

So perphirals with propreitary firmware hosted on them (or with just proprietary firmware) on the Librem 5 dont have direct access to memory? Thats so cool actually.

That’s actually awesome.

Thank you for explaining, but there is a bootloader on ROM to load u-boot?

One thing I dont understand about the verified boot here, is it all self signed? What am I confirming the integrity of exactly or comparing it too (last boot? what about after flashing?)?

Suppose the u-boot on disk was an evil maid, how would I know? Is there a way to detect if the u-boot I would write to disk I flashed the phone is “tampered” with respect to the u-boot that was on there before?

Also, if I wanted too, is there a way to sign an image such that it can be checked using the pgp card?

It is a bit vague too me, does any firmware (from the first two types you mentioned) actually get written when we “flash” with jumpdrive (is it even really possible on the L5?)? Or are we just writing files to disk? Also since the USB controller has a proprietary blob, does that mean that it does not have direct access to memory? If so, in turn, does that mean a connected computer does not have direct memory access?

From what your saying it seems: so long as the integrity of the OS image and bootloader are secured, even if there are malicious blobs on (or sent too) the L5, they cant really do anything because of the steps taken to frustrate anything evil they might do?

Also is all the free firmware contained in the OS image? Or is it also on a flash chip (or ROM)?

1 Like
16

My understanding is “no”. The blob is in the firmware jail with the most recent (second) WiFi card.

I guess though even peripherals that operate like that must have some mini-blob embedded in the peripheral and the mini-blob is capable of handling the blob that is sent by the operating system to the peripheral.

It does of course come at a performance cost. That probably doesn’t matter on the Librem 5 where shifting GB of data 24x7 isn’t a goal.

That is my understanding.

This is a major area that Librem 5 (right now) departs from the bigger Purism devices. What is your reason to believe that that functionality exists?? Documentation link?

One reason that it is less critical as far as the Evil Maid goes is that you can keep a phone on your person for much more of the time than you can keep a laptop.

You wouldn’t normally (re)flash with Jumpdrive. You might image the disk with dd using Jumpdrive and then later on therefore you might restore the entire disk with dd using Jumpdrive, if you stuffed something up badly - which is a kind of reflash.

But let’s rewrite the question as: does any firmware get written when we reflash a Librem 5? My answer would be ‘no’. It just rewrites the contents of the disk. So it’s more like a wipe-and-reinstall-the-operating-system.

Most of the peripherals have embedded firmware - except the 2nd kind of WiFi card where the firmware is in the firmware jail. So reflashing won’t change any firmware either way - which is a good thing and a bad thing i.e. a design trade-off.

A connected computer most definitely does not have direct memory access. All it can do is send and receive packets over USB. However, were you to put your phone in serial download mode (in preparation for using Jumpdrive or reflashing or other things), the effect of sending and receiving packets might well be to alter the contents of memory (as well as to alter the contents of the disk). So I guess you shouldn’t connect your phone, when the phone is in serial download mode, to an untrusted host computer.

I don’t know. There isn’t a lot of free firmware around though for mainstream peripherals - and even less that would be relevant to the Librem 5. All I can say is that if the firmware is open source then it is within Purism’s principles to include it within the operating system disk image.

1 Like
17

Thank you for the reply!

Interesting okay, so the “firmware jail” is that second flash chip I mentioned earlier (so this is effectively the “second kind” of firmware from your list)?

Figured as much, but the L5 is more about privacy/security and less about raw computational power. Wortwhile tradoff as far as Im concerned.

For some reason I thought it did and that was part of cryptsetup, also posts like this discuses secure boot related topics and how the pgp card is an alternative to a secure enclave/tpm. The post specifically mentions firmware and software verification, and discuses using the pgp card for disk unlocking as well (which in my mind is related). I think I took this to mean that the smart card was used as purism’s version of a tpm for verified boot, but your right, it never actually that it is used for secure boot specifically. Though that would be cool (and a feature I really would want)!

Yes. I think I mentioned it however thinking that the bootloader did verified boot, so it could load a malicious OS if you can just write the bootloader to disk (assuming its out after the OS loads and doesn’t do anything malicious beyond that point).

It would be nice if I could do something like: create a key pair and extract the public key, then sign the desired OS image with it, write it to disk using a computer (or SD card or USB stick as previously discussed), then unplug it and verify the image once its actually on the device before booting from the image. Or if purism pre-installed a key I could optionally use to verify their images. Or even store a hash for a checksum.

But what your saying is: there is no way to verify the image once its on the device (except by perhapse using another image on an SD card, or using the booting image and having it check itself on disk)?

Thats good to know, so basically a zero-day (or something very advanced, which was my guess) would be required to attack most of the peripheral firmware from the computer? We have already discussed the L5’s resilience to malicious firmware. Though if both the on-disk bootloader, OS and the firmware can be compromised that would be an issue

Thank you. It would be nice to be able to verify the full disk image (nothing hidden in the OS). I suppose you could verify that only what you wanted written was written by monitoring the current/voltage in the USB cable :sweat_smile:

Okay, so is this is what is required to “flash” the OS to the disk using uuu right?

Thanks for answering that.

P.s do you happen to know if using an x86 computer with jump-drive is a hard requirement? And if so why?

1 Like
18

Jumpdrive is not a hard requirement at all. I certainly would recommend it as a good tool to have though. Jumpdrive is the easiest way of doing backup and restore in a reliable way and almost all computers should have some kind of backup strategy - and the onus is on you to decide whether to have a backup strategy, what that strategy is, and to execute that strategy.

I would say that being able to reflash the phone is (close to) a hard requirement.

Reportedly you can reflash from an ARM computer - so x86 is not a hard requirement. Reflash from ARM (e.g. Raspberry Pi or another phone) is not something that I have done though.

The key requirements for reflashing are a computer that has available: a working git command, a working uuu command, working Python3, and obviously an internet connection. It is unlikely that many people would want to attempt to achieve that on any computer that does not run Linux.

The exact boundaries of how adventurous you can get in trying to meet those requirements are unknown. I’m happy for someone to use WSL under Windows combined with brute force and hackery - and demonstrate that you can reflash under Windows. :wink:

Do you want your life to be simple? Do you want to be able to focus on more productive challenges?

The actual files that get downloaded and then written onto the phone can basically be treated as opaque data.

If you can’t reflash your phone then you have to guarantee that you will not break your phone (it has happened e.g. through tinkering) and you have to guarantee that a Purism update will not break your phone (that has happened too although I would say that as the product matures that will become less likely).

If you can’t reflash your phone then you will find it more difficult or even impossible to perform a major version update (e.g. amber → byzantium → crimson). Again, as the product matures it is likely that in-place major version updates will become more straightforward.

Yes, serial download mode on the phone is necessary in order to reflash the phone and is necessary in order to boot Jumpdrive on the phone and is necessary for some other low level operations.

Fair enough. I can see why that text could be confusing. It’s not wrong. You can certainly use the OpenPGP card for verification and authentication - but not for the boot path, not for the operating system itself - because it would be too late. The Librem 5 simply does not work the same as the bigger computers at the current time as far as Evil Maid goes.

Reportedly it is possible to use the OpenPGP card to unlock the LUKS container, although that is not something that I am currently doing.

However it is important to note that the default LUKS configuration (on any Linux computer) does not contain integrity functionality, regardless of whether a card or a passphrase will be used to unlock. So someone with physical access to your computer could alter your encrypted file system. There is a high likelihood that they would just corrupt some file or corrupt the file system and the alteration would likely be being done blind. However only the corruption would alert you to the alteration. The alteration would not itself trigger any failure.

1 Like
19

I can understand from the phrasing of the question and the context, why you thought if I was asking if jumpdrive itself was a hard requirment, I meant only to ask if it was a hard requirement to use an x86 computer with jumpdrive. You answered that as well so thank you.

The answer to the last is yes haha

Is this the normal update mechanism

So it is required for all operations concerning jump-drive?

1 Like
20

I struggle when reading this to shake free of the notion that even on the Librem 5, at some low technological level, humanity loses.

After Purism announced the Firmware Jail coming to Librem 14 (Intel AX200 Wi-Fi/Bluetooth Shipping for New Orders – Purism) they endorsed the idea that it’s a good thing if the user is “free” to replace the firmware of their WiFi with a new blob, even though none of us users have the source code of these firmware blobs.

So, everyone is free to replace their firmware, but some people are more free than others if they are government 3-letter agencies with the blob sourcecode.

The Librem 5 is fun because it usually philosophically tries to be better than the grotesque of Android and iOS that we are all jedi mind tricked into thinking we should use.

But at the end of the day, it’s unlikely for users who want the privacy necessary to sleep at night to win the information war against governments who make it their active goal to secretly treat every living human like a criminal in case they might become one.

What makes you think you can win? I learned enough software to believe that at the hardware level I probably already lost, so all I can really do is take solace in winning the imaginary battles in the simulated software space that I was trained to understand. How can we verify hardware? How do we know it’s not all calling home to its creators in China? It’s fun to use a Liberty Phone and aspire to believe that maybe the mostly-for-show made “mostly” in USA branding will protect me. But whenever I open the back, it says Zhonshan manufacturing because the batteries are cheap China junk. If I were China, I would probably but some cellular call home machine into there. Why not? There are so many possible vectors.

2 Likes
21

At the current time, yes.

There’s no intrinsic reason for that. Booting Jumpdrive on the phone is just booting something other than the normal operating system. However

  • Jumpdrive wants to expose the disks as USB mass storage class devices, therefore however you boot Jumpdrive, the running software must have completely finished using the disks. An advanced user might well be able to package up Jumpdrive to boot from the eMMC drive or boot from the µSD drive.
  • Users might not want Jumpdrive occupying space on the eMMC drive if they aren’t using it.
  • Booting via uuu covers cases where you have more comprehensively borked your phone. :wink:
1 Like
22

Whether the blob is in the firmware jail or the blob is in the WiFi card … the blob is still there, the blob is still blackbox, and the blob may still be able to be replaced. And in the case of being in the WiFi card, three-letter agencies may have a better shot at that than you do. (Whereas in the firmware jail you have the same shot at replacing the firmware - it’s just that you can’t get new firmware to use as the replacement, whereas the manufacturer and the government may be able to do so.)

That’s why you need: hardware kill switch, isolation and encrypted traffic only (regardless of where the blob is).

Personally, I don’t buy the “it’s a good thing” argument. I buy the “it’s a necessary thing” argument. The old WiFi card simply didn’t work ideally, and getting further behind as WiFi standards move onwards and upwards. (You can argue that on a phone you may not need the fastest possible WiFi and you aren’t going to get it anyway - but on a laptop where you can shift serious amounts of data it becomes harder to support the idea of using older WiFi standards.)

1 Like
23

jail it is nothing and moreover wlan controller may have microcode too.

this is ridiculous, as the slave it depend on master so high speed wireless no make sense either where freedom and security it mandatory via Gnu System.

1 Like
24

Digressing onto future hypothetical possibilities … because the boot disk is eMMC, it could be possible for the boot path to be fully secured against the Evil Maid … using the RPMB area of the eMMC drive. This area is protected by a one-time programmable, write-only secret key, which key is used to sign any content that is written to that area - and you simply can’t write the RPMB without possessing the secret key. So if uboot were written to the RPMB area (it does appear to fit comfortably) then it could not be altered by the maid - and then because uboot has integrity it could in principle verify the integrity of the /boot partition using more conventional verification.

Note that in that case, the eMMC drive ought to arrive from the supplier with the secret key not programmed - and you must then generate a random secret key and arrange the above. So it’s self-signed, which is exactly what you want (rather than Big Tech-signed or Purism-signed). However that means that Anti-Interdiction would require some other mechanism.

There are no doubt gaps in this but it’s food for thought.

3 Likes
25

Thanks for the response!

That is so cool, a whole new thing to learn about! Thanks for bringing this up! Its so interesting hardware devices literally have spaces in them we just have no idea about (for better or worse) or are more or less invisible too us even as programmers.

I wonder what a good channel for learning this kind of thing about hardware is, or how it might be discovered by your OS.

I like the idea of self signing in particular also if I can verify the software from the vendor. I actually would like the ability to (perhaps optionally) store additional keys in there say from purism or I have noticed purism seems to have some support for Quobes OS. Self signing would at least confirm however that data-integrity was preserved after write, and would help detect tampering.

That would require some work

A couple I things that came to mind:

  • I did read this uses symmetric encryption which may be a bit tricker because this would be a highly sensitive key , but at the same time if its long enough that makes it quantum resistant (not that I am that concerned about a relevant quantum computer at present, but good to plan for the future).
  • Weather the encryption is symmetric or a public key (which in theory could be extracted given encrypted data) you would not want to use the key with an un-trusted device, when it has the key, it can flash whatever it wants, this may be a good reason to be able to use vendor keys, perhaps with the hashes encrypted by the vendor (but that would require public key-cryptography)
  • I think there is some marginal benefit to using public key cryptography: the public key is less sensitive and be safely exported/viewed (for example, I guess private keys generally cant [unless perhaps you have a lab where you dissect it or something] be exported), and the boot part of the disk is read proof (if the private key never leaves the device for instance)
1 Like
26

ls -l /dev

on your phone would reveal the 4 distinct areas of the eMMC drive (only one of which, the normal data area, is currently being used). NB: I am using the term ‘area’ here as distinct from ‘partition’. The normal data area is itself split into two partitions but that is different and more vanilla.

Ah, well, being quantum resistant may go beyond the scope of this topic. The key is 32 bytes (256 bits). It’s not an encryption key though. It’s a signing key. The readable content of the RPMB is in plaintext (unless of course the actual original content that you wrote to the RPMB were first encrypted).

The goal of the RPMB is integrity, not confidentiality.

Yes, you must protect this key (keep it secret) for this functionality to be useful. However you don’t need the key to reside anywhere on the phone except when you are actually updating e.g. uboot, which would be infrequent. (So you could e.g. keep it on a flash drive and just plug the flash drive in on the rare occasions that you would use it. Of course it is also essential to keep some kind of backup copy of the key if you intend to use the key.)

I think I am right in saying that Jumpdrive does not (yet) support the RPMB area. The area is not exposed and probably the necessary specialised read and write commands are not supported. So this would mean that you can’t delegate maintenance of the RPMB area to the host computer.

As a hypothetical, you could make the RPMB completely and irrevocably read-only by generating the key, sending the key to the eMMC drive, writing the RPMB area once, and then throwing away the key. For some threat models that would be good.

Vendor keys are, well perhaps I won’t say anathema but, not a good thing. It opens you up to having to trust the vendor. It opens you up to situations where the vendor gets taken over, goes out of business, obsoletes the product. It opens you and the vendor up to situations where the vendor is compromised, either by a hacker or by government coercion.

2 Likes