With or without binary blobs and undocumented registers/IPs?
Windows supports virtualization on the 8 Gen 3 only because they use a custom setup to load a signed binary blob ("applet") into the EL2 hypervisor, whose signature it is is hardcoded to accept, and that blob/applet then can be used by Windows as a kind of shim into EL2-land to spawn VMs, etc. But Qualcomm's hypervisor is always present and enforcing its security policy.
In practice every single modern system is running tons of binary firmware blobs, it's mostly where you draw the line on functionality and isolation of components (security, integrity, availability.) Here, Qualcomm does intentionally reduce some functionality, which is pretty bad when you consider that the UEFI spec for ARM mandates EL2 handover, I think, and they just ignore it.
1. Half of the EL3 and EL2 code is so old, it has to jump between aarch32 and aarch64 multiple times during the boot process.
2. The silicon is full of errors. There are also major security vulnerabilities due to Qualcomm doing their own slightly modified version of everything.
3. Not even their biggest customers (e.g. Samsung) is given the source code for the magical blobs used during boot.
4. Given these issues, the EL2 code is basically there to hold things together. It will never go away and they will never show you what it contains
This is a problem we should be loud critics of. Proprietary firmware hurts us all, and practically benefits no one.
Wake up, Neo. The Matrix has you...
These computers are no longer simple cores with simple devices. If you want that go buy a DOS machine from the 1980's, or a arm7TDMI.
The problem though is that companies invest in all this firmware, and become convinced that DIMM training, signal integrity/phy training, and algorithms which estimate the cooling capacity and thermal mass of the attached heatsink, or any of a hundred other things are somehow competitive advantages and deserve to be locked up behind closed doors rather than opensource. In some cases they are right, but that shouldn't keep them from publishing reference firmware sources and register documentation.
So, really people complaining about proprietary firmware are sorta missing the point. Complain about the lack of documentation to create your own firmware, not that the company thinks they have a competitive advantage in that firmware.
And also admit that what one needs is hardware/firmware abstractions that allow big kernels like linux to communicate with all the little cores in the machine working on specific tasks, be that NVMe for disks, AT command sets for modems, or ACPI for power management.
1. https://github.com/FanX-Tek/rk3588-TRM-and-Datasheet/tree/ma...
https://gitlab.collabora.com/hardware-enablement/rockchip-35...
I wish the rk3588 was blobless, sadly not.
Nice little widgets, crazy faster than a pi4.
Not as good as being able to sign it yourself, but way better than not having the source.
It also prevents an attacker from hacking the hardware in a way that would persist after a full reinstall of the OS.
> In practice every single modern system is running tons of binary firmware blobs
The SoC's boot ROM is 32K, fully inspectable, does not linger once the OS is booted. Every other software component is built from source and you can replicate it
(I use a usb-to-ethernet dongle and the wifi card is disabled, but you are right in theory)
If I had a dollar for every 8051 that turned out to be inside a chip I designed around...
Although "modern" is debatable.
1: https://developer.arm.com/documentation/102412/0103/Privileg...
Probably execution level 2.
> How do I run AOSP using Mainline?
> One might think it is quite hard to run AOSP with mainline on such a new platform, but in reality, not at all! Thanks to the long term effort of Linaro and Google engineers making it possible to run AOSP with vanilla Linux releases. Thanks to Amit Pundir for providing a helping hand to get AOSP on this platform.
> To generate an AOSP image for the Snapdragon 8 Gen 3 Qualcomm Reference Device using the current set of patches available on the mailing list, use the following instructions, which are derived from here https://source.android.com/docs/setup/build/devices with some small changes.
Also those blobs are often targeted at specific kernel versions, so in 2 years when the upstream vendors stop releasing updated blobs, then it no longer becomes possible to upgrade the kernel, making it very very hard to keep last gen devices secure.
This exact problem is why I was forced to admit there is no secure path to use Android today, and a big reason why I gave up on smartphones entirely.
I believe POWER9 is the only modern option that doesn't use blobs? Of course that doesn't remove the possibility of hardware backdoors (nothing does, except maybe an electron microscope and a lot of free time), but that's a higher bar.
Is there open source microcode, at this point? I can't find anything that suggests there is.
On long obsolete AMD K8 CPUs, there was some work on reverse engineering the microcode back in 2017:
Not sure if the Broadcom GbE NICs they use require firmware. It would seem odd to me that they'd go so far as to include an open FPGA[0] for board management and system bringup to avoid closed firmware blobs, only to then rely on a network interface with firmware requirement.
[0] https://www.crowdsupply.com/raptor-computing-systems/talos-s...
Is this true for the blobs in the Snapdragon 8 Gen 3 Mobile Platform?
This is not necessary: my Librem 5 doesn't rely on blobs in kernel and runs FSF-endorsed GNU/Linux, PureOS.
[1]: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...
Librem 5 has very dated hardware that barely runs. It has only Cortex A53 cores @ 1.5 GHz that were released in 2012. You will see it even lag in Purism's videos.
Modern Android phones have better OS, hardware security, battery life and will be useful for longer and cheaper.
Librem 5 now costs 1000 USD, the same price that Google Pixel 8 Pro costs which also has guaranteed 7 years of OS support. Will you want to use Librem 5 in 7 years?
Also let's not forget how Purism took forever to ship the devices and was declining refunds from people that didn't even get sent the device and waited way over a year.
Oh and there are Android phones that can run on mainline kernels.
Yes: Librem 5 is a full desktop, with my full control, "Thinkpad T400 in mobile". It will always run latest Linux and all desktop apps. I can use it as a full desktop connected to keyboard/screen. On the other hand, Android is not a general purpose computer, which only runs what Google allows you to run.
You should try SXMo if you want to see how smoothly Librem 5 and even Pinephone can work if the software is optimized.
> You can't update the firmware at all and you are still running it.
Is there even theoretically an attack vector here?
Yes, Purism has been having problems with refunds. It doesn't affect security or freedom of they devices. Don't buy from them if you will want a refund.
Pixels Pro have now... 7 or 8 years support.