The kernel will work fine, but at minimum EL2 runs the Qualcomm Hypervisor (Gunyah) which prevents native KVM virtualization from taking place. This is true of all Snapdragon platforms.
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.
My experience from working a few years with qualcomm CPUs at a major home electronics brand:
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
Yeah. These days our operating systems don't actually operate the system anymore. Hardware manufacturers usurped our control of the machine. They think of Linux as the "user OS", to be virtualized and sandboxed away from the real computer.
And frankly that is as it should be. The OS has enough responsibility trying to arbitrate the collection of hardware resources while providing its own set of abstractions (filesystems, processes, etc) to the application layers.
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.
Not on Rockchip platforms as far as I am aware. The RK3588 is one of their highest performing SoCs, it has 4 Cortex-A76 cores running 2.4GHz thus making it somewhat close to desktop performance, without any of these blobs or locked down bootloaders. And mostly complete documentation[1] is available.
Assuming you can verify the signed blob identical to the one you can build yourself, you can verify there's no intentional back doors or unintentional security issues.
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.
Yes, I agree. Source code and reproducible builds which can be cryptographically verified to be equivalent to the signed blob would go a long way towards making them trustworthy. Still denies us the freedom to modify them but at least trust could be assured.
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
And you probably still have firmware on the main machine. Just about every modern usb controller offloads the USB packet arbitration/sequencing behind a microcontroller and a pile of fw. Ex XHCI is usually a 8051 and some firmware sitting on the other side of the XHCI register description. Its probably the same on the actual USB->ethernet device, where there is conceptually something like the cypress FX3 integrated with a ethernet mac/phy in the chip an a couple arm's running firmware to respond to the USB packets and act as a control plane for the data being DMA'ed to/from the ethernet buffers. Same with the disk, does it have NVMe, SD, emmc? Then likely there is another handful of arm device doing the load leveling and flash management on the "disk". Or for that matter the battery and charge controller might look dumb but has a little microcontroller integrating instantaneous charge/discharge information and adjusting charge current/etc.
Agreed, people seem to only see blobs when they run on x86. A typical PC system probably has at least two dozen ancillary CPU cores spread out among the IO and peripherals alone.
If I had a dollar for every 8051 that turned out to be inside a chip I designed around...
Exception Level 2 [1] They're analogous to "protection rings" on x86. Generally, EL0 is usermode, EL1 is kernel mode, EL2 is hypervisor, and EL3 is the "secure monitor"/firmware code, closest analogy I think would be SMM on x86. On top of all of that there's also trustzone with its own EL0 and EL1.
As a practical matter, I think the article happens to describe the steps to test it out yourself. I suppose the absence of a mention of binary blobs doesn't necessarily mean that they're not being used, I think it's plausible that there aren't (m)any.
> 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.
Those blobs, if backdoored, could have massive security implications.
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.
AMD and Intel both have their share of proprietary blobs, in their "open source" packages, including microcode. Where do you see a secure path, for any computing, especially high performance?
> Where do you see a secure path, for any computing, especially high performance?
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.
I do in fact have a Power9 workstation next to my desk, though sadly not in use as the biggest security wins for my workflow come from QubesOS which cannot run on Power9, yet.
People rightly disapprove of the AMD and Intel blobs and do what they can to disable or remove them, but at least those have stable interfaces that don't decay when there is a new kernel version. Basically every x86_64 processor ever made can run the latest version of the Linux kernel. Would that it were for Qualcomm.
Intel microcode is signed so you can't run open source microcode even if you were able to create it, and the microcode is encrypted so you can't reverse engineer it anyway.
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.
> 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.
Is this true for the blobs in the Snapdragon 8 Gen 3 Mobile Platform?
Isn't it true that even if the firmware was open, as long as the hardware is closed it could still be backdoored and doing things you don't want it to? Where do you draw the line?
Because Purism cheated and just moved the blobs into a chip that you can't update and made it go through a separate processor[1]. FSF-endorsement is meaningless. This is worse than having a loadable blob from a kernel.
You can't update the firmware at all and you are still running it.
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.
They don't have spare parts in the online shop, but people on the forum were able to buy them or repair the devices by contacting Purism directly. AFAIK in case of a larger demand, Purism promised to provide spare parts more explicitly.
It is the closest we have to a freedom respecting device. The baseband processor is still a closed blob but it is a lot better than pretty much everything else out there. Maybe Pinephone eventually will get there as well.
It's honestly incredible how much progress the Asahi team have made with Linux on Apple Silicon. In a few years I imagine we will have Vulkan support, external displays, bluetooth and good performing drivers for most of the hardware.
I swear, the MBP running Linux would be an unstoppable development environment - at least as far as ultrabooks go.
With the developments in Proton, FEX (x86 translation), and usability improvements in desktop linux (Gnome 4x and KDE); I'd go as far to say a MBP running Linux with full hardware support would be the best gaming and general purpose ultrabook on the market.
For now I am testing Asahi but daily driving MacOS.
The title is upstream support available, yet when I look at the tree in the article it is a 6.6 rc, and a bunch of public patches under review. I don't see a -next branch its on, and I don't see it in the 6.7 merge list.
I agree: it's not at all clear from the title, it sounds as if it's truly "upstream."
But patches based on an upstream tree (as opposed to any forks intended for Android) are pretty useful IMO. They're not accepted/landed but you can use them now and I'd wager good money that they'll continue rebasing them until they land, so you should expect to be able to use them for the foreseeable future.
Heh, and then I'm on the opposite end of the spectrum: I can happily get by with the CPU power offered by Skylake (or maybe even older) devices, but need 32GB RAM to be "mostly comfortable, usually" in my developer workflows. I could easily make use of 64GB. I'm considering putting 96-128GB in my next desktop build for some future-proofing.
And yet laptop manufacturers seem hellbent on insisting 4GB is still acceptable to ship at all, and even still market 8GB machines to professionals. Folks, "professional software" like Slack takes hundreds of MB of RAM to even render the splash screen these days, it should be nearly criminal to ship a consumer device with less than 16GB now (alternatively, we should be taxing software companies for the negative externalities their waste produces, but that's a messy political fight)
> Folks, "professional software" like Slack takes hundreds of MB of RAM to even render the splash screen these days, it should be nearly criminal to ship a consumer device with less than 16GB now
Maybe the problem is slack (and every other program hogging your RAM). Just because we can doesn't mean we should. I get that some workloads need RAM but consumers and not even every professional needs it. There are still jobs where you mainly work with an e-mail client, normal sized documents and a browser.
Blame bad developers for developing terrible software, not the companies providing cheap computing for the masses. There can even be an environmental argument against it. I don't even bother downloading the Slack app, I use it on the web for work, but I refuse to install it. Not going to happen, why would I? You shouldn't either.
I don't use the app, I use a tab in Firefox. I even alluded to "alternatively, we could tax software companies for their waste". We're on the same team, bud, I just also have to accept the reality I currently live in: to pay the bills, I need a job (I'm not an indie developer yet, though one day I might like to be, and work on patronage or something!), and to do that job I have to use whatever the corporate chat app du jour is. Sadly, I will likely never be in a position to pitch anything for that; these decisions are made by non-tech-geeks for the most part, and so I'll rarely, if ever, get to use eg. Zulip or IRC in a corporate setting again. It's Slack, or Teams, or some other heavyweight mess, all the way down. And so I need the RAM to render it, and thus I need laptop manufacturers, and mini PC manufacturers, and etc., to get their shit together and either: (a) stop soldering RAM down, or (b) provide $LUDICROUS_NUMBER amount of it, and to stop pretending pittances of RAM are acceptable for professionals in nearly-2024.
> it should be nearly criminal to ship a consumer device with less than 16GB now
I assume you were just being hyperbole because now you're talking strictly professional devices. You can and should give your expertise when non techies have opinions, one could even argue it's in our job description. You seem to have just caved and buy more RAM. I took the other more painful route, scrapped every electron app, learned vim, and am very vocal about the issues at $DAY_JOB. If more people did the same would we be in this situation today?
If you're compiling huge programs I get the need for ridiculous amounts of RAM, but consumers should absolutely be fine with 8GB, many even with 4GB. I work in VMs with 4GB daily and it's no problem using my normal stack, a few terminals, a browser window with a couple of tabs. It doesn't break a sweat so it's difficult to relate.
I'm not a big fan of any SoCs which have soldered-on RAM or storage, but I find it an odd point to argue that I'm supporting Apple's ecosystem overall when all I did was buy their hardware on sale. Their App Store is by far their biggest money-maker.
I would say it doesn't count because they're all "evil". Apple, Intel, AMD, Qualcomm, Microsoft... The only stuff that's close to being truly open like Freescale and Talos is completely obsolete and overpriced.
Having used GNU/Linux since kernel 1.0.9 and subscribed all Linux User Journal issues since the 5th issue until their insolvency, I am quite aware of I am talking about.
What FUD, when the Framework themselves admit none of the provided Linux distributions support 100% of the hardware features they are selling?
We already had white brands doing the same 20 years ago during the dot-com wave.
No it's not. They've changed their policies retroactively multiple times. When people originally ordered the Purism 5, they could get a refund at any time. Then they changed it multiple times, and now you can't get a refund at all.
Soldered CPU/memory makes sense for performance. Part of why Apple's M SoCs blow Intel/AMD away so hard is that the physical signal paths are incredibly short and don't have physical sockets in their way, so way better signal integrity and less worrying about EMI.
