AOSP is not proprietary. Also security is not achieved merely by the merit of being libre, see CVEs for sudo, glibc or Apache HTTP server or even the Linux kernel itself.
And when it comes to proprietary firmware updates, in case of x86 one such notable example is the microcode which is pretty important to keep updated for security.
Also security is not achieved merely by the merit of being libre, see CVEs for sudo, glibc or Apache HTTP server or even the Linux kernel itself.
Being libre is the basic requirement to even being considering something as secure, but it is not enough by itself. I agree.
And when it comes to proprietary firmware updates, in case of x86 one such notable example is the microcode which is pretty important to keep updated for security.
Generally that’s what people say, but is it really that simple? A new firmware version might fix some known vulnerability, but its developers might have also introduced a new one on purpose. So a known vulnerability might have been fixed, but you might have gotten a new one that isn’t yet known. So I don’t know if that’s really so much better. Also I assume that the only way to exploit those vulnerabilities is through malware? But if you only run free software, the risk of getting malware is very small.
I agree with you that every proprietary software must be presumed to be a trojan with a backdoor but still some critical, low level free software being decades old C codebases with oftentimes millions of LoC has proven to be a double-edged sword where on one hand most of it is super optimized (just compare launch times of lightdm or GDM to e.g. regreet) but on the other hand by pure probabilistics it’s more likely to contain some vulnerabilities accumulated over the years of imperfect code reviews.
Sure I believe it’s worth hoping and supporting initiatives that might one day bring us to something like RISC-V smartphone with high level of hardware security that’d run something like Alpine (a minimalist distro) but based on Redox OS. Maybe that’ll come true in a couple of years.
But right now GrapheneOS even despite proprietary hardware is the best option security-wise, unless you’re willing to tinker with hacking together some RISC-V SBC-based device (which might even have better battery life than most smartphones by up to 60%!), but the optimization of basically any software is going to suck so badly. And forget compiling any Rust code on the currently available RISC-V CPUs. want memory safety? pick something with a VM/GC instead.
You are right that some projects are more likely to have vulnerabilities than others. But at least with libre software any expert can look into it, fix it and distribute the patch to others.
I don’t have much hope for RISC-V, since most SBCs that use it seem to require a custom Linux kernel, so it’s the same problem that we have with ARM. Maybe things will get better at some point, but unfortunately most people don’t seem to care. I haven’t heard of Redox before. It looks interesting, but it’s a shame that it’s not under a GPL license.
But right now GrapheneOS even despite proprietary hardware is the best option security-wise
Maybe you are right and Graphene with F-Droid is the most secure option. I don’t think it’s necessary to have all of its features, since we don’t have them on desktop either, but it would be nice to have them on mobile for sure.
unless you’re willing to tinker with hacking together some RISC-V SBC-based device (which might even have better battery life than most smartphones by up to 60%!)
That’s crazy! Is RISC-V so much more efficient than ARM?
And forget compiling any Rust code on the currently available RISC-V CPUs
Apparently there are multiple crates but no official toolchain so unsure how that works in practice. You’re still limited to either waiting for hours or cross-compiling though since currently the best available RISC-V CPU is quad-core 2.5 GHz (which still looks hella promising, 2 years ago best we had was 1.5 GHz dual-core). This blog post by Drew DeVault goes into detail of how daily driving RISC-V looked like 2 years ago. I suppose these days it looks noticeably better, especially since Samsung and Apple have been eyeing RISC-V adoption due to ARM consortium doing some monopolistic shit with their licensing. But eventually, so far, not enough critical mass was attained and afaik the whole drama mellowed out a bit.
Regarding the energy efficiency, some experimental units managed to even be manifold better at this:
But on the other hand, studies involving some RISC-V models show quite the contrary when it comes to energy efficiency, although the thermal performance is much better:
And below is a screenshot from a comparison by Gary Explains using more microcontroller models. So it really depends on the specific model, but it seems like the design of RISC-V has some solid potential to beat ARM in terms of energy and thermal efficiency.
I didn’t know there was no RISC-V toolchain for Rust, that’s kinda weird!
You’re still limited to either waiting for hours or cross-compiling though since currently the best available RISC-V CPU is quad-core 2.5 GHz (which still looks hella promising, 2 years ago best we had was 1.5 GHz dual-core).
Compiling anything on PinePhone is also painful :D. But I suspect there is probably a lot more ARM packages available in distros and some app developers release ARM builds.
Those energy efficiency comparisons are pretty interesting! x86 is also improving, so I’m curious if there will ever be x86 phones.
AOSP is not proprietary. Also security is not achieved merely by the merit of being libre, see CVEs for sudo, glibc or Apache HTTP server or even the Linux kernel itself.
And when it comes to proprietary firmware updates, in case of x86 one such notable example is the microcode which is pretty important to keep updated for security.
I never said that it was.
Being libre is the basic requirement to even being considering something as secure, but it is not enough by itself. I agree.
Generally that’s what people say, but is it really that simple? A new firmware version might fix some known vulnerability, but its developers might have also introduced a new one on purpose. So a known vulnerability might have been fixed, but you might have gotten a new one that isn’t yet known. So I don’t know if that’s really so much better. Also I assume that the only way to exploit those vulnerabilities is through malware? But if you only run free software, the risk of getting malware is very small.
I agree with you that every proprietary software must be presumed to be a trojan with a backdoor but still some critical, low level free software being decades old C codebases with oftentimes millions of LoC has proven to be a double-edged sword where on one hand most of it is super optimized (just compare launch times of lightdm or GDM to e.g. regreet) but on the other hand by pure probabilistics it’s more likely to contain some vulnerabilities accumulated over the years of imperfect code reviews.
Sure I believe it’s worth hoping and supporting initiatives that might one day bring us to something like RISC-V smartphone with high level of hardware security that’d run something like Alpine (a minimalist distro) but based on Redox OS. Maybe that’ll come true in a couple of years.
But right now GrapheneOS even despite proprietary hardware is the best option security-wise, unless you’re willing to tinker with hacking together some RISC-V SBC-based device (which might even have better battery life than most smartphones by up to 60%!), but the optimization of basically any software is going to suck so badly. And forget compiling any Rust code on the currently available RISC-V CPUs. want memory safety? pick something with a VM/GC instead.
You are right that some projects are more likely to have vulnerabilities than others. But at least with libre software any expert can look into it, fix it and distribute the patch to others.
I don’t have much hope for RISC-V, since most SBCs that use it seem to require a custom Linux kernel, so it’s the same problem that we have with ARM. Maybe things will get better at some point, but unfortunately most people don’t seem to care. I haven’t heard of Redox before. It looks interesting, but it’s a shame that it’s not under a GPL license.
Maybe you are right and Graphene with F-Droid is the most secure option. I don’t think it’s necessary to have all of its features, since we don’t have them on desktop either, but it would be nice to have them on mobile for sure.
That’s crazy! Is RISC-V so much more efficient than ARM?
Is that not possible?
Apparently there are multiple crates but no official toolchain so unsure how that works in practice. You’re still limited to either waiting for hours or cross-compiling though since currently the best available RISC-V CPU is quad-core 2.5 GHz (which still looks hella promising, 2 years ago best we had was 1.5 GHz dual-core). This blog post by Drew DeVault goes into detail of how daily driving RISC-V looked like 2 years ago. I suppose these days it looks noticeably better, especially since Samsung and Apple have been eyeing RISC-V adoption due to ARM consortium doing some monopolistic shit with their licensing. But eventually, so far, not enough critical mass was attained and afaik the whole drama mellowed out a bit.
Regarding the energy efficiency, some experimental units managed to even be manifold better at this:
https://arstechnica.com/gadgets/2020/12/new-risc-v-cpu-claims-recordbreaking-performance-per-watt/
But on the other hand, studies involving some RISC-V models show quite the contrary when it comes to energy efficiency, although the thermal performance is much better:
https://link.springer.com/article/10.1007/s11227-024-05946-9
And below is a screenshot from a comparison by Gary Explains using more microcontroller models. So it really depends on the specific model, but it seems like the design of RISC-V has some solid potential to beat ARM in terms of energy and thermal efficiency.
I didn’t know there was no RISC-V toolchain for Rust, that’s kinda weird!
Compiling anything on PinePhone is also painful :D. But I suspect there is probably a lot more ARM packages available in distros and some app developers release ARM builds.
Those energy efficiency comparisons are pretty interesting! x86 is also improving, so I’m curious if there will ever be x86 phones.