TommyTran732
With that being said, yeah, he's being disingenuous as per usual for sure. Part of Qubes hardening is trying to not allowing an attacker to gain root to make it harder to attack Xen, but our evangelist here claims it doesn't matter if an attacker has root :)
Yup, that's part of it.
But remember, even if they didn't do it, there's still a matter of them by using components with internal flash storage for the firmware instead of shipping firmware with the OS and letting the OS upload them. Like that's not a hackjob like the /lib/firmware or /run/firmware stuff or anything, but it's not like it's any more "open" than any other system, if not being a bit more opague. Of course the marketing would still be deceptive then.
Accusing me of your own sins.
> What do you mean by "tampering" here? Is uploading firmware to peripherals a "tampering"? Why is this a problem, compared with other devices? Does anybof those blobs run on the CPU? I don't understand what you are trying to say.
On the laptop, messing with the system memory (/run) and dumping firmware packages in there instead of just shipping it with the OS using a sensible approach like the linux-firmware package is a hack-job and nasty practice. And since it's messing with system memory, that's your "tampering" right there.
On the phone, once again, instead of using a normal, sensible approach like the linux-firmware package on desktop Linux or the vendor partition on Android, they just store the firmware in some chip, then have the OS (or more accurately, the initramfs) mount the content of the chip using overlayfs in /lib/firmware anyways. It's another implementation of the same hackjob. That, and they combine it with using peripherals whose firmware are stored inside of internal flash chips so the OS doesn't have to be shipped with firmware packages that it then needs to load into the peripherals.
What does this entire exercise do for freedom or openness? *Asbolutely nothing*. It's called shuffling the firmware storage around so you can market the OS as "blob free" when it's literally meaningless. If anything, it makes it harder to audit and figure out which firmware version is being run than if the firmware were to be shipped along with the OS.
---
To dumb it down a notch if you really do not understand what I am trying to say:
This makes about as much sense as if I were to take the SSD out of my laptop, destroy the M.2 socket, then advertise it as a "storage free and OS free laptop". To use the laptop, you must plug in external storage through the USB port and load up an OS. But hey, since there is no SSD or OS on the "main" part of the laptop, I am now qualified for some made up certification and can advertise my stuff as "freeing" the user from the shackles of the evil storage system and nastiness of having an OS. Definitely more "open" than other laptops.
The actual admission (requires a login): https://forum.qubes-os.org/t/how-exactly-is-heads-pureboot-s...
His words, not mine:
> The goal of Heads is to bring reasonably trustworthy firmware on reasonably open platforms to boot reasonably secure OS, enforcing best effort user controlled atteststion, compartmentalization and prevention. Never is it written anywhere that the firmware is tampering resistant or tampering proof: we lack open source implementation in hardware to have root of trust in hardware. Heads is best approach on what is available, the anchor of trust being in the bootblock, not in hardware. The chain of trust lies there. Of course an evil maid could craft a firmware that would lie about its measurements in the bootblock, raminit, romstage and the payload. But as today, no PoC has even been made public, showing it being actoinnable, and by nature of TPM extend operations is nothing easy to realize, while possible.
I am just gonna highlight the critical part here one more time, since I sent you the same thing before and you didn't read:
> *Of course an evil maid could craft a firmware that would lie about its measurements in the bootblock, raminit, romstage and the payload.*
Yeah, I wouldn't call heads "best approach on what is available" and I do think Boot Guard is better, but at least he is honest about the actual mechanism and the very obvious attack vector.
Read the code posted above.
https://news.ycombinator.com/item?id=47953726
It is exactly how it works. Read the actual code for yourself: https://source.puri.sm/Librem5/librem5-fw-jail/-/blob/pureos...
If you can't read code, here is the marketing material: https://puri.sm/posts/shipping-new-sparklan-wifi-cards-with-...
If you don't know that the firmware for components/peripherals can either be uploaded to them by Linux or just stored on some flash chip on the component, read: https://www.chromium.org/chromium-os/developer-library/refer...
On the Librem laptop, the tampering is done by PureBoot and inject into /run/firmware. The other user was linking the stuff with the laptop.
*On a Librem 5, it is stored on a separate chip, then they read it with the initramfs, then mount it on top of the regular filesystem at /lib/firmware*.
Like I said, it's just shuffling stuff around.
Here is the actual code, if you care enough to read it: https://source.puri.sm/Librem5/librem5-fw-jail/-/blob/pureos...
If you can't read code, here is the marketing material: https://puri.sm/posts/shipping-new-sparklan-wifi-cards-with-...
If you don't know that the firmware for components/peripherals can either be uploaded to them by Linux or just stored on some flash chip on the component, read: https://www.chromium.org/chromium-os/developer-library/refer...
And the firmware for Bluetooth/Wifi is loaded in by having the initramfs read it from the NOR flash, mount it in /lib/firmware, then it is business as usual like a desktop Linux distribution.
It's not something special. It's just a hackjob. They shuffle the files around and made it much harder to update.
https://source.puri.sm/Librem5/librem5-fw-jail/-/blob/pureos...
https://puri.sm/posts/shipping-new-sparklan-wifi-cards-with-...
I can use GrapheneOS with the global mic toggled off and sensors toggled off/denied to apps. I can still text, browse the internet, and check my emails while talking to my friends. I can go about my day, receive notifications, be a productive member of society while being reasonably sure that no apps on my phone is snooping on my convos.
This is what most people expect of a "microphone killswitch". Unfortunately, the hardware killswitches on the Librem cannot provide even remotely the same level of assurances as even a software killswitch.
The Librem 5 is either fully offline or something can snoop on the convos while internet is on. How is that a sensible implementation?
> I am using a phone with the kill switches off in a meaningful manner all the time. It is a full computer running a desktop OS and can run any apps, including listening to music from a microSD card, reading saved text/pdf files, showing presentations with original LibreOffice, programming in any language with standard tools, and so on.
Yeah, I am sure this is what a sane person expects a functioning phone with a "microphone killswitch" to be - an offline pocket sized computer instead of a device for communication 99% of the time.
> Even though the phone in the lockdown mode (with all three kill switches off) has no connections, if I'm ever in emergency and need some help, I can turn the phone functionality back on and call for the help I need. Obviously, privacy in such case would be secondary after health.
Yes, I am sure the purpose of the phone is to make a call instead of being used for texting/receiving notifications when you are out and about.
> Unlike for GrapheneOS, there is no way to hack my kill switches for any money. I can be 100% certain that they work as intended, even if a state actor is against me. Yes, everything else might be compromised in such case but not the tracking and listening to me when I need true location and microphone privacy.
Ever considered that maybe, just maybe, a valid use case for most people is not necessarily to hide their location from the carriers 24/7 but to not have their private conversation snooped on?
Or perhaps, another valid use case that some people might want is the ability to be connected to the internet via Wifi while not having their location tracked by the carrier or their private conversations snooped on? I can give you another detailed explanation as to how standard Android has a location toggle that works while your desktop-Linux-in-a-phone can easily have the location tracked when Wifi is on (and without an OS compromise) if you'd like ;)
Both the Pixel and Librem 5 have firmware baked into the SoC that is executed.
On GrapheneOS, the firmware is signed and updated along with the OS.
On the Librem 5, the firmware for Wifi/Bluetooth is stored on a NOR chip, which is read from and mounted into the OS by the initramfs into /lib/firmware.
Not-withstanding the above, Librem 5 components such as the USB controller, touch screen controller, radios, battery, etc simply have closed-source firmware baked in (stored on some flash chip on these components), but it doesn't mean that they are not there or in use.
In both cases, components either do not get proper firmware updates from the OS, or they are too old/low quality to get any firmware updates from the vendors to begin with. Storing firmware on the component is also a less secure approach than having signed firmware loaded by the OS, as it now means that these components have persistent storage which can be attacked.
Aside from all of the above, they also use a dedicated CPU core to run firmware blobs for things like memory training.
In essence, what the Librem 5 has achieved is shuffling proprietary firmware storage around instead of eliminating their existence or execution. It is not any more "free" or "open" than anyone else while also being less secure.
Instead of loading firmware in sensible manner like GrapheneOS or desktop Linux distros with the linux-firmware package, they keep PureOS "free of blobs" by having the bootloader inject all of the blobs into memory in an extremely shady manner. Since when was having the bootloader tamper with system memory about freedom and openness?
Oh, and they even have the audacity to market this as the "firmware jail" as if it is any more contained than the linux-firmware package too. Truly impressive stuff.
I did reply to them plenty of times. Here you go doing the exact same thing again - ignoring 100% of what's being said, then claiming "no one can respond".
> You only talk about the lack of security of Pureboot and never showed the code breaking it.
If you think a piece of code is needed to understand why it's a joke, then I don't even understand what is wrong with you. LMAO. The whole thing is conceptually botched, and they pretty much admitted as much.
1. Boot block performs measurements of itself, its settings and everything down the chain for attestation.
2. There's nothing protecting the boot block.
3. A malicious boot block can lie about measurements.
4. If the goal is to defend against an attacker who tampers with the BIOS chip - then it fails at doing so miserably because an attacker can just use a boot block that lies about the measurements.
Seriously, what good is showing you the code if you don't even conceptually understand how the thing works?
You know, there is a famous saying: A farmer does not need to know how to lay eggs to know whether an egg is good or bad. In our case, the egg is already rotten from the get-go. This is not a "Ohhh something has such bad code I can attack it using XYZ method, wait and see!" situation. This is a situation where "Your logic doesn't even make any sense to begin with."
Perhaps, just perhaps, you can benefit from just spending 5 minutes thinking a bit about how the whole thing actually works at a very high level and read what I said above.
I don't even feel like arguing against the absurdity of your arguments anymore. This is my last attempt at dumping it down a notch:
A "microphone killswitch" is supposed to protect the user against having their convos being snooped on when it's toggled and still be able to use the phone in a meaningful manner. A "microphone killswitch" that doesn't really function on its own and requires turning the entire device into a brick is non-fuctional for all practical purposes.
I might as well just invent a "microphone killswitch" that requires people to pull out the battery to make sure that they are not snooped on at that point.
Everything else is pretty much the argument though - who buys a phone with a microphone killswitch so good that for it to actually function you must also flip the other killswitches to kill both wifi and cellular connection? A microphone killswitch so impeccable that in order for you to not be snooped on you also have to give up texting and browsing the internet. Truely impressive stuff.
Unfortunately he will just ignore every single counter argument ever made and blindly believe these companies because their marketing material has "freedom" and "FOSS" in it.
Does that really sound like a functioning "killswitch"?
CopperheadOS was always's Micay's project and used his own signing key. The key never belonged to Copperhead the company afaik.
It doesn't prevent audio recording in the super paranoid "oh, the whole phone has been compromised" scenario because it is bypassable via the sensors.
In fact, it doesn't even protect the phone in normal operation, because apps with device=all can access the sensors without the whole phone being compromised.
It doesn't prevent audio recording with any normal usage either because the OS is incapable of protecting private conversations thanks to the PulseAudio socket. "Exploiting" this is significantly easier than any of the stuff involving the sensors.
By that logic, you might as well just not have the killswitch at all. Everything is magically "trusted", right?
Yes, I do understand that threat models can vary. Please give an example of a threat model where it makes more sense to use a phone which cannot protect any private calls over a functioning phone that has real protection.
If you are going to say "oh, when you never talk on the phone at all" then you might as well just remove the mic. It's not hard.
As usual, there is nothing that GrapheneOS or Micay says regarding the Librem or Pinephone that is inaccurate. You are just saying stuff that doesn't even remotely make any sense. Perhaps you are being deliberately disingenuous. Perhaps you are just so blinded by an ideology that you cannot see that what you say is just nonsense. I wouldn't know.
> I choose to dispute false information. I don't care about any personalities.
Doesn't seem to be what you are doing here.
Hardware kill switches are nice-to-have, but they are significantly less important than the OS actually protecting the mic. With your Librem/PinePhone, you cannot even reasonably expect your calls with end-to-end encrypted apps like Signal and Element to be protected. Any app with access to the PulseAudio socket (which happens to be anything that you want to have audio playback with) can snoop on your mic at any moment in time. This does not even require an OS compromise.
This has been pointed out to you repeatedly and yet you choose to ignore it, and instead you just do character assassination whenever a post regarding GrapheneOS or Daniel Micay shows up because what Micay says goes against your favorite ideological products...
Quite frankly, anyone looking at that subreddit will know that it's just a bunch of incompetent and incoherent rambling from a few guys with quite literally no technical understanding. They been doing this for years now, spreading terrible privacy and security advice and spearing developers with these cheap shots when they cannot argue on the technical front.
PrivSec is not a part of either PrivacyGuides or GrapheneOS. I am currently a moderator on GrapheneOS, and have not been associated with PrivacyGuides for almost a year now.
Interesting. Are you sure about this? The Wiki says it can be deleted and I did not see it coming back during my time with openSUSE. I can check it again later though.
Essentially, anyone with access to Google's web servers and physical access to your hardware can just unlock and decrypt your device.