GrapheneOS

GrapheneOS, 11 days ago

@ku It doesn't have any impact on Vanadium. It uses the built-in filtering engine and doesn't support extensions. We plan to upgrade the built-in filtering engine to support what we want to provide, similar to Brave. Any other features will also be implemented ourselves rather than by having people run third party code with access to their data. Extensions don't follow the standard site isolation model so they're always a downgrade in that regard for privacy and security.

GrapheneOS, 15 days ago

@xyhhx @ivpn It sounds like an issue with their service. Make sure your time is set correctly though. Is there any error message from it?

GrapheneOS, 19 days ago

@Anibyl @jasonkoebler Most alternate mobile operating systems greatly reduce security including the security against data extraction from the device, remote attacks, apps, etc. GrapheneOS does the opposite.

We greatly improve the defenses against that attack vector, but in this case it sounds like users are providing their lock method. Samsung does have working always-enabled encryption but Cellebrite, etc. can bypass it unless the device is Before First Unlock with a strong passphrase.

GrapheneOS, 19 days ago

@Anibyl @jasonkoebler See https://grapheneos.social/@GrapheneOS/112462758257739953 in our recent thread about how GrapheneOS and other devices are holding up against this attack vector. Nearly all other alternate operating systems are reducing security, not improving it, so your statement is overly general.

There's no evidence of backdoors in Samsung devices but rather they are simply a lot easier to exploit than GrapheneOS. They lack proper alternate OS support so another OS would be missing important security features.

GrapheneOS, 20 days ago

We're increasingly scared of updating LTS revisions and it does not help that the GKI LTS branch is lagging a bit behind since it's not lagging behind due to any further stabilization but rather lack of resources to keep up. Any LTS revision with f2fs changes is terrifying now.

GrapheneOS, 20 days ago

Unlike the stock Pixel OS, we've avoided shipping common f2fs corruption bugs in production by being way ahead on LTS adoption while narrowing avoiding shipping new serious issues. Has been way too close for comfort and we have low confidence in any LTS release with f2fs changes.

GrapheneOS, 20 days ago

Generic Kernel Images have directly interfered with both hardening and performance due to the impact of vendor hooks working around not being able to change core kernel code. We don't want dynamic kernel modules but we're essentially forced into using them to avoid init bugs.

GrapheneOS, 20 days ago

They've made the usual mistake of burning resources on branches by having 2 variants of each LTS branch (Android 12/13 variants of 5.10, Android 13/14 variants of 5.15, Android 14/15 variants of 6.1, etc.) and then making many overlapping branches from those to stabilize them.

GrapheneOS, 20 days ago

We're unconvinced that the Linux kernel is headed in the right direction. It's not truly getting more robust or secure. The accelerating complexity and churn is opposed to both, as are the culture and tools. We're hitting more issues including on our workstations and servers.

GrapheneOS, 20 days ago

@gregkh It's clearly not possible for 1 person to do all of this properly no matter how productive you can be. The fact that Google hasn't assigned more resources to GKI LTS releases and kernel.org LTS releases is ridiculous. Our issue is with Google and other companies expecting a tiny group of people to do all this especially as kernel complexity grows and the pace of development accelerates. All the problems we see with kernel.org LTS, GKI LTS and the CNA are from extreme lack of resources.

GrapheneOS, 20 days ago

@gregkh We aren't opposed to far more vulnerabilities having a CVE assigned, but non-vulnerabilities shouldn't. There were far too few CVE assignments before. The number of CVEs being assigned now might reflect reality but many are the wrong bugs.

The goal is clearly getting distributions to ship the stable/LTS releases instead of cherry-picking. That would be nice, but we think the goal would be better accomplished through having far more people working on testing, review, backporting, etc.

GrapheneOS, 19 days ago

@gregkh We're in full agreement cherry-picking fixes with CVE assignments didn't work, but kernel.org LTS releases don't have nearly enough backported themselves and don't have nearly enough testing/review.

Perhaps shaming companies/distributions into using LTS with CVEs will work but it would work better if there were clear criteria and few incorrect assignments which requires more resources.

Google has more than enough resources to trivially fund all this even if no one else is on board.

GrapheneOS, 14 days ago

@fiery Open hardware really has nothing to do with more operating systems developing a usable mobile OS.

Moving to a far less private and secure OS is the opposite of what we want. We do not want the anti-privacy/anti-security desktop software stack used on desktop Linux, OpenBSD, etc. That's the opposite of what we're trying to accomplish with GrapheneOS. Rolling back privacy and security by a decade is not the goal but rather improving it.

OpenBSD would not be progress at a low level either.

GrapheneOS, 14 days ago

@fiery OpenBSD kernel and Linux kernel are both monolithic kernels written in C. OpenBSD kernel is much simpler, but that would need to change as part of adding tons of required functionality and improving performance + power efficiency. Linux kernel has support for writing drivers in Rust and much more advanced exploit protections. Moving to the OpenBSD kernel is definitely not a clear upgrade especially since it will have to be massively extended for the use case.

GrapheneOS, 14 days ago

@fiery Open hardware and open firmware are a separate thing from having driver support for any given hardware.

OpenBSD has much more mature support for arm64 than RISC-V and an entirely new hardware platform based on RISC-V is not going to make it easier to make or port drivers to it.

RISC-V is missing a lot of required security functionality for GrapheneOS which would need to be implemented both for RISC-V as an ISA and then for operating systems using it. Lot more to it than that.

GrapheneOS, 14 days ago

@fiery If we were going to move to a new kernel, we would want a microkernel written in a memory safe language, not another monolithic kernel written in C. Something would have to be done to preserve compatibility either way, whether it's a compatibility layer resembling gVisor / WSL1 or involves simply running instances of the Linux kernel as part of guests via hardware virtualization. In the short/medium term, none of that is practical beyond using hardware virtualization more for sandboxing.

GrapheneOS, 18 days ago

@Rairii The software, hardware and firmware for Windows desktops has dramatically less protection against being exploited and make no serious attempt to put up barriers against an attacker with physical access. It's far easier to get all the data when it's not at rest. There's a lack of comparable hardware encryption security features and if you're not using a strong passphrase then it's not going to hold up against even much less sophisticated attackers. TPMs are not good secure elements.

GrapheneOS, 18 days ago

@Rairii When talking about desktops and laptops running Windows or Linux, you can just assume nearly any attacker is capable of bypassing weak mitigations aiming to prevent a brute force attack and that only a strong passphrase will work. Similarly, if the data isn't at rest, there's no serious attempt at defending it.

The difference with Pixels and iPhones is that they're making a serious attempt to make weaker credentials secure against attacks along with keeping data secure while locked.

GrapheneOS, 18 days ago

@Rairii They're missing our auto-reboot feature for getting the device back at rest which means no limit on how long the attacker can wait around to have an exploit available, which is a big hole in their defenses. The tables we posted also demonstrate that Cellebrite can currently exploit the OS for both so auto-reboot would only work for them if there wasn't time to bring it to the tool with these current exploits. A Windows or Linux desktop/laptop is far easier to exploit than these.