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
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
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.
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.
Readit News
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.
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
> 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.
A viable Linux ARM laptop would be cool, especially if it promised high performance and long battery life!
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.
I've been daily driving my pinebook pro since 2020.
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.
Its not actually upstream, is it?
SOS then?
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.
It's still a nice progress though.
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?