Get the top HN stories in your inbox every day.
bfrog
aseipp
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.
kramerger
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
thomastjeffery
> 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.
matheusmoreira
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.
fsflover
It's a bit better in Pinephone: https://news.ycombinator.com/item?id=36659544
dmitrygr
> 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
fragmede
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.
asddubs
What's EL2 exactly?
Avery3R
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...
baby_souffle
> What's EL2 exactly?
Probably execution level 2.
wyldfire
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.
spookie
This is quite refreshing! Thanks for the details
nomel
Naive question. What's the practical impact for not having these? It seems that AMD and Intel are also guilty.
lrvick
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.
nomel
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?
jancsika
> 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?
surajrmal
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?
fsflover
> 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.
robert_foss
The GPU probably runs a firmware blob. Other than that Linaro is serious about upstream support.
almatabata
At minimum i expect QSEE and all their TAs to remain binary blobs, like the keymaster for example.
foobiekr
Someone knows Qualcomm.
apatheticonion
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!
seabrookmx
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.
camel-cdr
> 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.
seabrookmx
Fair. The raspberry pi-esque performance is a deal breaker for me personally though.
apatheticonion
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.
StillBored
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?
wyldfire
> 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.
robert_foss
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.
flakiness
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.
robert_foss
ISP won't happen. GPU is just a matter of time, and has been enabled for previous platforms.
neilalexander
Perhaps with this, the Microsoft Dev Kit 2023 will turn out to be a decent option for Linux on ARM.
entropicdrifter
Meh, still worse than a 2020 M1 Mac Mini
neilalexander
Unless you like RAM. The Dev Kit comes with 32GB as standard.
entropicdrifter
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
tjoff
If you want to support an ecosystem that goes against your own interest. Sure, but what would cause you to be that shortsighted?
entropicdrifter
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.
bjackman
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?
tetris11
PostmarketOS is pretty mainline, and comes with a nice Phosh interface, but smart battery support remains an issue on a lot devices
fsflover
I wonder if one can run GNU/Linux like PureOS on the respective devices.
Get the top HN stories in your inbox every day.
With or without binary blobs and undocumented registers/IPs?