Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

grapheneos.org

Post reply on HN
Print view View original

151–160 of 186 posts

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#151

Post by pjmlp »

strcat wrote: post #82
letstrynvm wrote: post #20

Earlier quoted context omitted.

No, chain-of-trust only has one trick... it can check that what you're about to run is unaltered from what was signed to some degree of probability. If that is the - shipped and validly signed - bugridden nightmare-fuel like the propreitary Qualcomm 802.11 stack or proprietary multimedia bits that are a rich and continuous source of vulnerabilities (take a look through the last months here https://source.android.com/…

> No, chain-of-trust only has one trick... it can check that what you're about to run is unaltered from what was signed to some degree of probability. This is only one of many privacy and security regressions from moving to a far less secure software stack without anything close to the same level of hardening or work on privacy / security. > If that is the - shipped and validly signed - bugridden nightmare-fuel like…

> Android is Linux....

Kind of, Google can release Android running on top of any OS that implements the NDK stable APIs, plus their POSIX subset, and besides OEMs no one would notice the change.

https://developer.android.com/ndk/guides/stable_apis

Other than that I fully agree with your statement regarding being a security weakness.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#152

Post by nextos »

petre wrote: post #144
beenBoutIT wrote: post #126

Earlier quoted context omitted.

A Pixel running stock AOSP with F-droid and Chromium is the bleeding edge of what's possible with open source. There's no better UI/UX in existence and the tragedy of it all is that outside of Android developers and software engineers most people never get to experience it at all. The reality is that Librem is unnecessary because we have F-droid. There's nothing wrong with F-droid and as time goes on more mainstream…

Too bad the Pixel doesn't have a headphone jack, otherwise I would have bought one. I've also heard it was pagued with hardware issues. Stuck on Nexus 5 + LineageOS for the time being. GrapheneOS is sadly only available on Pixel devices.

Pixel 3a has a jack. Not supported yet by GrapheneOS, but it might be in the future. You can always self-compile your own plain AOSP.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#153

Post by pjmlp »

oscargrouch wrote: post #114
strcat wrote: post #85

Earlier quoted context omitted.

Strengthening the security with virtualization is something that's in the early stage of experimentation and research and will be a long-term project. Over the long term though, the goal is moving away from having the Linux kernel completely other than as the native API / ABI for apps. Projects like https://github.com/google/gvisor are very promising in that regard even if they end up playing no part in how this even…

I think if you dont have a strong opinion about it, this is exactly what they are trying to achive with Zircon/Fuchsia kernel. A micro-kernel, with a linux virtualization layer, being abble to run Linux executables as if they were native. My hunch is that in the long term, Google will probably use Zircon as the 'first-level' kernel, and run the android apps using some emulation layer. Maybe it could be the answer for…

Google has already kind of achieved that with ChromeOS, each Linux executable runs in a sandbox, specially tailored for it.

It can only see hardware, files and processes that the user allows to as well.

It was written in Rust.

Check the ChromeOS support for Linux talk at Google IO.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#154

Post by Nursie »

orbifold wrote: post #140
Nursie wrote: post #139

Earlier quoted context omitted.

> BSD/Linux derived FOSS is still the C stronghold. Oh that's ok then, it's not like that accounts for most of the world's server and embedded infrastructure, open or otherwise...

The operating system is only a tiny fraction of commercial code out there most of which is either written in (more) memory safe languages like Java, C# or C++. SAPs code base alone is 1 billion lines of mostly C++ and their own proprietary scripting language.

Wait, is C++ memory safe?

I know they've introduced a lot of ways that memory management becomes easier or automatic, but I'm not sure you can call it "memory safe" can you?

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#155

Post by Nursie »

pjmlp wrote: post #145
Nursie wrote: post #139

Earlier quoted context omitted.

> BSD/Linux derived FOSS is still the C stronghold. Oh that's ok then, it's not like that accounts for most of the world's server and embedded infrastructure, open or otherwise...

How are they doing in the desktop and mobile OS worlds? And regarding embedded space, AUTOSAR now requires C++14. I think there are enough computers with wheels to deem it relevant.

Desktops are dwarfed by mobiles devices. AFAICT a linux kernel variant is present on most of the world's smartphones (with most of the rest being iOS devices, which I know little about), though you've addressed that by saying Google are pushing to reduce the impact of C underlying their system.

I don't want to make a song and dance about C being awesome or anything - we've certainly got massive issues with allowing that extreme amount of flexibility without ensuring that the developer really, really means what they've just told the machine to do - but it's hardly a small enclave that's holding out, it's still huge.

And there are still companies developing in it. I've seen a sort-of-microservices-in-C-implemented-as-a-sort-of-supersized-cgi-bin approach relatively recently.

And yes it was an abomination!

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#156

Post by cyphar »

wuschel wrote: post #143
cyphar wrote: post #130

Earlier quoted context omitted.

> AOSP is completely open source. This is only true in the most technical way possible. Yes, AOSP is open source -- but none of the standard applications on any stock version of Android use AOSP anymore. The calendar and other applications are all proprietary. The AOSP versions feel like they stopped being developed in 2010 -- which coincidentally is when Google started developing proprietary replacements. I use Line…

> There is a caveat for the baseband, but that's because it's not legal in most countries to sell or use baseband hardware that is free software (unless the user is licensed and even then it's non-trivial). Interesting, I did not know that. What are the reasons for this? Military application? Are these laws subject to change? I always thought that there is no way to separate the CPU from the baseband/communications P…

It's my understanding that the issue is one of FCC certification and licensing -- the FCC won't approve something which can be easily modified to transmit on non-free frequencies (tools which can usually are sold to hamradio license holders, which should know better and know how much trouble they can get into).

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#157

Post by pjmlp »

Nursie wrote: post #155
pjmlp wrote: post #145

Earlier quoted context omitted.

How are they doing in the desktop and mobile OS worlds? And regarding embedded space, AUTOSAR now requires C++14. I think there are enough computers with wheels to deem it relevant.

Desktops are dwarfed by mobiles devices. AFAICT a linux kernel variant is present on most of the world's smartphones (with most of the rest being iOS devices, which I know little about), though you've addressed that by saying Google are pushing to reduce the impact of C underlying their system. I don't want to make a song and dance about C being awesome or anything - we've certainly got massive issues with allowing t…

So you want to talk about mobiles?

Windows Phone, JavaScript, .NET (VB and C#) and C++.

iOS, JavaScript, Objective-C, C++ and Swift, C only due to BSD stuff.

Android, Java, Kotlin, JavaScript, C++, C only due to Linux kernel. Its sucessor. Project Treble drivers use Java and C++. Fuchsia is written in a mixture of Rust, Dart, and C++.

ChromeOS, JavaScript, C++, Rust, C only due to Linux kernel

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#158

Post by pjmlp »

Nursie wrote: post #154
orbifold wrote: post #140

Earlier quoted context omitted.

The operating system is only a tiny fraction of commercial code out there most of which is either written in (more) memory safe languages like Java, C# or C++. SAPs code base alone is 1 billion lines of mostly C++ and their own proprietary scripting language.

Wait, is C++ memory safe? I know they've introduced a lot of ways that memory management becomes easier or automatic, but I'm not sure you can call it "memory safe" can you?

Not to the extent that it is tainted by C's copy-paste compatibility.

Still it does provide a stronger type system, proper string, vectors, reference paramenters and strong type enumerations, to prevent a large amount of C security exploits.

C++ teams that care about security do use such features and respective static analysers on their CI/CD to enforce them.

While it doesn't cover everything, it is much safer than plain C.

Ideally, we will reach a state where both C and C++ get nuked, or ISO C++ just drops its C copy-paste compatibility, which in the end means it is anyway easier to switch to something else.

However that process will take decades, and is hampered by relying on POSIX based systems.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#159

Post by Nursie »

pjmlp wrote: post #157
Nursie wrote: post #155

Earlier quoted context omitted.

Desktops are dwarfed by mobiles devices. AFAICT a linux kernel variant is present on most of the world's smartphones (with most of the rest being iOS devices, which I know little about), though you've addressed that by saying Google are pushing to reduce the impact of C underlying their system. I don't want to make a song and dance about C being awesome or anything - we've certainly got massive issues with allowing t…

So you want to talk about mobiles? Windows Phone, JavaScript, .NET (VB and C#) and C++. iOS, JavaScript, Objective-C, C++ and Swift, C only due to BSD stuff. Android, Java, Kotlin, JavaScript, C++, C only due to Linux kernel. Its sucessor. Project Treble drivers use Java and C++. Fuchsia is written in a mixture of Rust, Dart, and C++. ChromeOS, JavaScript, C++, Rust, C only due to Linux kernel

> Windows Phone, JavaScript, .NET (VB and C#) and C++.

An irrelevance given their complete lack of market presence.

The rest all have significant underlying C components you've identified. All I'm saying is that's a hardly a 'niche holdout' when it appears to be at the heart of the vast majority of shipping devices.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#160

Post by pjmlp »

Nursie wrote: post #159
pjmlp wrote: post #157

Earlier quoted context omitted.

So you want to talk about mobiles? Windows Phone, JavaScript, .NET (VB and C#) and C++. iOS, JavaScript, Objective-C, C++ and Swift, C only due to BSD stuff. Android, Java, Kotlin, JavaScript, C++, C only due to Linux kernel. Its sucessor. Project Treble drivers use Java and C++. Fuchsia is written in a mixture of Rust, Dart, and C++. ChromeOS, JavaScript, C++, Rust, C only due to Linux kernel

> Windows Phone, JavaScript, .NET (VB and C#) and C++. An irrelevance given their complete lack of market presence. The rest all have significant underlying C components you've identified. All I'm saying is that's a hardly a 'niche holdout' when it appears to be at the heart of the vast majority of shipping devices.

It is, given the amount of usage across the OS stack, which decreases with every OS release.

By the way on iOS, drivers are written in C++.

Post reply on HN