Upstream Linux support available for Qualcomm Snapdragon 8 Gen 3 Mobile Platform | Hacker News Reader

Upstream Linux support available for Qualcomm Snapdragon 8 Gen 3 Mobile Platform

linaro.org

183 pointsfsflover98 comments

With or without binary blobs and undocumented registers/IPs?

Naive question. What's the practical impact for not having these? It seems that AMD and Intel are also guilty.

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.

> and a big reason why I gave up on smartphones entirely

This is not necessary: my Librem 5 doesn't rely on blobs in kernel and runs FSF-endorsed GNU/Linux, PureOS.

Pixels may also be an option -- though Librem 5 is, in this context, better.

Pixels Pro have now... 7 or 8 years support.

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.

[1]: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...

I don't see how it's worse. As a consequence, it's the only phone that can run fully free OS and have lifetime updates.

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.

> Will you want to use Librem 5 in 7 years?

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.

How will you fix it in 4 years? I don't see were they sell spare parts.

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.

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.

> do what they can to disable or remove them

Is there open source microcode, at this point? I can't find anything that suggests there is.

The parent probably speaks of Intel ME neutralizing/disablement.

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:

https://github.com/RUB-SysSec/Microcode

The Raptor Blackbird and Talos systems might qualify: https://www.raptorcs.com/content/base/products.html

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...

> 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?

You don't draw the line: you support practical, existing systems that are as open as possible. Also, there is Precursor, which is open hardware.

https://www.gnu.org/philosophy/free-software-even-more-impor...

Someone knows Qualcomm.

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.

This is quite refreshing! Thanks for the details

At minimum i expect QSEE and all their TAs to remain binary blobs, like the keymaster for example.

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.

What's EL2 exactly?

> What's EL2 exactly?

Probably execution level 2.

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.

1: https://developer.arm.com/documentation/102412/0103/Privileg...

> In practice every single modern system is running tons of binary firmware blobs

This is a problem we should be loud critics of. Proprietary firmware hurts us all, and practically benefits no one.

It's a bit better in Pinephone: https://news.ycombinator.com/item?id=36659544

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.

https://youtu.be/36myc8wQhLo

Only a secret and privileged few actually get to boot and talk to a modern physical CPU. The rest of us only get to run on top of an abstraction.

Wake up, Neo. The Matrix has you...

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.

What good is open source firmware when the hardware only accepts cryptographically signed proprietary blobs?

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.

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.

1. https://github.com/FanX-Tek/rk3588-TRM-and-Datasheet/tree/ma...

I believe DDR training and USB have blobs:

https://gitlab.collabora.com/hardware-enablement/rockchip-35...

I wish the rk3588 was blobless, sadly not.

Nice little widgets, crazy faster than a pi4.

  > In practice every single modern system is running tons of binary firmware blobs

This one does not: https://www.amazon.com/ASUS-C100PA-DB02-10-1-inch-Chromebook...

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

Even the broadcom-based wifi card? my read of https://wireless.wiki.kernel.org/en/users/drivers/brcm80211 says for the 4354 in the c100, you need firmware, for brcmfmac.

You are right.

(I use a usb-to-ethernet dongle and the wifi card is disabled, but you are right in theory)

Try this one: https://www.crowdsupply.com/sutajio-kosagi/precursor

Although "modern" is debatable.

Merely 6x the cost :)

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.

https://blog.einval.com/2022/04/19#firmware-what-do-we-do

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...

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

The GPU probably runs a firmware blob. Other than that Linaro is serious about upstream support.

Will this help bring Linux to the upcoming Qualcomm Elite X laptop SoC?

A viable Linux ARM laptop would be cool, especially if it promised high performance and long battery life!

Asahi is very close to daily driver material so it's likely that Macs will be the first viable ARM Linux laptops, funny enough.

But it would certainly be great to see more variety, and with a standard (ie: UEFI based) install process.

I would already be rocking an X13s if the Linux support was there.

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.

> Asahi is very close to daily driver material so it's likely that Macs will be the first viable ARM Linux laptops, funny enough

I've been daily driving my pinebook pro since 2020.

Fair. The raspberry pi-esque performance is a deal breaker for me personally though.

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.

Its not actually upstream, is it?

SOS then?

> Its not actually upstream, is it?

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.

I haven't checked but you may be correct, but Linaro has a stellar track record. These patches will land upstream if they haven't already.

It doesn't cover either GPU or ISP (image processing unit). Not sure about NPU. Does Hexagon support cover that?

It's still a nice progress though.

ISP won't happen. GPU is just a matter of time, and has been enabled for previous platforms.

Perhaps with this, the Microsoft Dev Kit 2023 will turn out to be a decent option for Linux on ARM.

Meh, still worse than a 2020 M1 Mac Mini

Unless you like RAM. The Dev Kit comes with 32GB as standard.

Fair point. For my workloads compute matters a lot more than RAM, but it's not as straightforward a trade-off as I was initially thinking

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.

The part I'm reacting most to was this:

> 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.

If you want to support an ecosystem that goes against your own interest. Sure, but what would cause you to be that shortsighted?

I run my M1 Mac Mini with Asahi Linux?

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.

You are supporting the biggest threat to the open platforms we have. And you are actively not supporting the ones that keep it alive.

How is that an odd argument? Voting with your wallet suddenly doesn't count because shiny?

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.

Purism, System76, Framework etc. are not evil.

If only the hardware on their laptops would be 100% functional.

Works quite well for me.

As in, "the hardware features that don't work are irrelevant to me", or "I enjoy tinkering"?

https://frame.work/de/en/linux

Are you making such a big deal out of the fingerprint reader?

When I pay for something it better either everything works, or money refund.

To get GNU/Linux going without proper hardware support I can do it myself, no need to pay extra.

I don't think you understand the value proposition.

But you can at least try to be honest and not spread fud.

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.

Eventually tinkering becomes tiresome.

> when the Framework themselves admit none of the provided Linux distributions support 100% of the hardware features they are selling?

Which means you get exactly what was advertised. Try the other two companies in my list.

The standard reply, here

https://www.reddit.com/r/System76/s/dohrbjShW6

Great experience for Apple like prices. /s

Purism are unethical scumbags.

This is FUD. I flagged your post.

Also: Please don't post shallow dismissals, especially of other people's work.

https://news.ycombinator.com/newsguidelines.html

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.

https://forums.puri.sm/t/estimate-your-librem-5-refund/16227...

Yeah, no, that is delusional.

Sure, you can go the purist route if you want. But it is not either or, few things in life are.

Intel and AMD aren't so bad for openness

> I'm not a big fan of any SoCs which have soldered-on RAM or storage,

Funny way of putting "I am stupefied people pay actual, real world money for a laptop with soldered on storage".

Laptops may still make some sense, but a desktop!! You can easily get 2x value going with an assembled.

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.

> Soldered CPU/memory makes sense for performance.

And I have talked about storage.

You wrote "soldered RAM", and besides, the argument is just as valid for storage given today's transfer bus speeds.

that was my parent, I didn't.

Wow this is fantastic (assuming the matches get merged).

Anyone have a picture of how likely/soon we can reach a future where mobile devices get kernel upgrades in the mainstream market?

I hear graphics drivers are getting pretty isolated now so is it even possible without open graphics?

PostmarketOS is pretty mainline, and comes with a nice Phosh interface, but smart battery support remains an issue on a lot devices

I wonder if one can run GNU/Linux like PureOS on the respective devices.

Reply on news.ycombinator.com