We've added documentation for the hardware memory tagging implementation in hardened_malloc:

https://github.com/GrapheneOS/hardened_malloc?tab=readme-ov-file#memory-tagging

GrapheneOS on Pixel 8 / Pixel 8 Pro is the first platform using ARM MTE in production. Stock Pixel OS has it as a hidden development option requiring using ADB.

GrapheneOS uses hardened_malloc as the system allocator and enables memory tagging by default. MTE is enabled for all base OS apps and nearly all executables. It's only temporarily disabled for surfaceflinger (due to upstream bug in Android 14 QPR1) and a few vendor executables.

For user installed apps, we enable MTE by default for apps without bundled native libraries and apps marked as compatible. We give users the option to enable MTE for all user installed apps in Settings > Security and users can then toggle it off for specific incompatible apps.

We added a user-facing notification for crashes caused by MTE detecting memory corruption. It makes it easy for users to copy the traceback for reporting the bug to app developers. This also means users don't need to guess when the toggle to disable MTE for an app is relevant.

Our Vanadium browser is also the first browser using MTE in production. In Vanadium, we enable Chromium's PartitionAlloc MTE implementation. PartitionAlloc's implementation isn't nearly as good as hardened_malloc, but we intend to improve PartitionAlloc's security in the future.

Chromium marks itself as compatible with MTE but then disables it as runtime, so other Chromium-based browser have MTE disabled even when the OS has it enabled. We found a bug in Chromium's MTE integration which we had to fix to avoid WebView crashes. It works smoothly for us.

We're also planning on enabling Clang's stack allocation MTE support but it currently breaks Chromium's C++ garbage collection integration along with apps doing in-process unwinding via libunwind. We want MTE for the Linux kernel too, but it integrates it as a debugging feature.

hardened_malloc's MTE implementation is already best in class, but there are some improvements to consider. It currently statically reserves a value for free slots, which reduces the random choices from 15 to 14. It may make sense to use the default 0 tag for free data instead.

MTE obsoletes hardened_malloc's canary and write-after-free check features, so we disable them when it's enabled. However, we haven't figured out an approach to save the memory reserved for canaries yet due to Android supporting dynamically toggling MTE at runtime which is messy.

hardened_malloc uses MTE for all slab allocations, which are all the allocation size classes from 16 bytes through 128k bytes with statically reserved regions for each one. It doesn't need MTE for any metadata since all metadata is in a statically reserved region solely for that.

For allocations beyond the max slab allocation size (128k), there are randomly sized guards placed before/after each allocation along with an address space quarantine on free. MTE would still be valuable for large/arbitrary overflows and use-after-free beyond the quarantine.

We need to investigate the cost of tagging the large allocations above 128k by default.

For non-MTE-capable hardware, we could consider reserving a huge region for allocations above 128k with our own best-fit implementation in userspace to separate them from non-malloc mappings.

Reply to this note

Please Login to reply.

Discussion

Does GrapheneOS allow to choose which type of connection applications can use like in DivestOS?

👇

Network Restriction: DivestOS already lets you restrict network for each app by connection type (cellular/Wi-Fi/VPN), when in the background, and optionally completely revoke NETWORK permission.

#privacy #security #gos

again, tad, the lead developer of divestos uses #grapheneos.

"I like the DivestOS project. However, it cannot provide the same security and privacy guarantees as GrapheneOS. Tad, the lead developer of DivestOS admits so themselves.

The reason why DivestOS exists is to provide harm reduction for obsolete and EOL devices, not to provide a secure and private phone, because it is hard/almost impossible to do so.

If you have the means, I would personally suggest that you go ... with GrapheneOS, just like the DivestOS developer does."

Can you focus on the topic?

GrapheneOS is not a reliable project because unreliable people stand behind it.

Another thing is that GrapheneOS builds a walled garden and forces people to use their servers. You claim that you're security espert. Have you noticed that GOS forces to use their server to sync the clock? Maybe you think that you can have accurate time using manual setting?

GOS is a perfect tool to fingerprint and track journalist and dissidents.

DivestOS allows to make updates over Tor, DivestOS has repository with apps within Tor- .onion address.

DivestOS has .onion address of their site.

Can you provide any details of GOS to confirm claim that GOS is pro privacy and has astonishing approach to the security vs. DivestOS?

Do you have any personal or business relations with GrapheneOS?

DivestOS

What memory allocator is used?

As of 2024/01/09:

jemalloc for 32-bit and 64-bit: all 14.1 and 15.1 devices

jemalloc for 32-bit and hardened_malloc for 64-bit: all 16.0 and 17.1 devices

scudo for 32-bit and hardened_malloc for 64-bit: all 18.1, 19.1, and 20.0 devices

Exception: These devices use jemalloc for 32-bit instead of scudo: akari/akatsuki/aurora/xz2c, cheryl, klte, hlte

https://divestos.org/pages/faq

The tone and the line of questioning is perceivably antaganostic and hostile for unknown reasons. Much has been stated with great confidence however lacking substance and demonstrating a lack of use and familiarity of the very thing having remarks laid against it.

> Does GrapheneOS allow to choose which type of connection applications can use like in DivestOS?

👇

>Network Restriction: DivestOS already lets you restrict network for each app by connection type (cellular/Wi-Fi/VPN), when in the background, and optionally completely revoke NETWORK permission.

Yes GrapheneOS has the exact same functionality, DivestOS Network toggle is the exact same developed by GrapheneOS.

> GrapheneOS is not a reliable project because unreliable people stand behind it.

Remarkable claim with unremarkable evidence. You'll likely tout clout chasing trust abusing and extortionist "influencers" claims, where one in particular is a card carrying Kiwi Farms member immersed in their targeted harrassment campaigns being encouraged and encouraging in equal measure. Unreliable narrators all.

> Another thing is that GrapheneOS builds a walled garden and forces people to use their servers. You claim that you're security espert. Have you noticed that GOS forces to use their server to sync the clock? Maybe you think that you can have accurate time using manual setting?

Nobody is walled in, nobody is forced to use anything, all default connections are routed via GOS servers or proxies but can be done through stock Google or other provider. Users can use either/or OR none dependent on the connection in question.

> GOS is a perfect tool to fingerprint and track journalist and dissidents.

This is why Edward Snowden Chair of Freedom of the Press Foundation uses it every day and Citizenlabs team members have recommended it to high value targets etc.

> DivestOS allows to make updates over Tor, DivestOS has repository with apps within Tor- .onion address.

DivestOS has .onion address of their site.

Our updater will update the app via any connection if using Orbot/VPN etc.

Can you provide any details of GOS to confirm claim that GOS is pro privacy and has astonishing approach to the security vs. DivestOS?

grapheneos.org all auditable and verifiable should anyone choose to do so.

Can you provide any details to backup your extraordinary claims?

When you have no argument you can always play "hostility" or similar card.

You're just a liar. I use to have GrapheneOS on my phone.

Users CANNOT use any other server than GrapheneOS to sync clock using WIFI or LAN.

Why are you lying?

You can read YOUR site.

"An HTTPS connection is made to https://time.grapheneos.org/generate_204 to update the time"

You have no option to choose other server.

Your lies only confirm that GrapheneOS is not reliable.

Lets quote the WHOLE thing shall we:

° An HTTPS connection is made to https://time.grapheneos.org/generate_204 to update the time with a millisecond precision X-Time header. As part of future support for using other services, it falls back to the standard Date header with second precision.

This is a full replacement for Android's standard network time update implementation, which uses unauthentication SNTP (Simple Network Time Protocol) with fallback to the cellular network when it's not available (GNSS can also be used as a time source but is disabled by default, and OEMs can choose the priority order). Network time updates are security sensitive since certificate validation depends on having an accurate time, but the standard NTP / SNTP protocols used across most OSes have no authentication or encryption.

We plan to offer a toggle to use the standard functionality instead of HTTPS-based time updates in order to blend in with other devices.

Network time can be disabled with the toggle at Settings ➔ System ➔ Date & time ➔ Set time automatically. Unlike AOSP or the stock OS on the supported devices, GrapheneOS stops making network time connections when using network time is disabled rather than just not setting the clock based on it. The time zone is still obtained directly via the time zone provided by the mobile network (NITZ) when available which you can also disable by the "Set time zone automatically" toggle.

So as I said "Dependent on Connection" and as I said we DO NOT FORCE people to use our services. Not only can it be disabled, as I said "use either/or or NONE" we ARE going to offer the default connection.

You're a bad faith actor.

You changed your statement to "We are going to offer..."

Currently you force to use your server. People need accurate time -Tor, I2p, TOTP-2FA etc.

Before I thought that GOS is not reliable now I changed my point of view you're just probably a honeypot to fingerprint people.

Oh look another cycled npub. Nevermind honeypot, you're a timesink. You keep using that word FORCE too so lets get all Inigo Montoya...

#m=image%2Fjpeg&dim=537x464&alt=Inigo+Montoya+Meme&blurhash=%3BVD%2BuXf69tWWw%5Ds%3ANGj%5BfkMxayf%2Bayt6WBR*jZjZ_NWVs9s.R*WXWBoLjZbvayn%24f6RjayoLayj%40xvjtxafQflfQaebHRj-%3Bf6NGayRjoLoeWVWXV%40oLt7WVofoLjsWVR*%25Mf6aeazWBj%5BayWVjt&x=3e0af40376ee9f6d391ff0da96133f2667848b6aaeed0a126d0c586287576bb7

Could you upload a screenshot of this feature in GrapheneOS - I can't find it.

I only found Network permission.

>>Network Restriction: DivestOS already lets you restrict network for each app by connection type (cellular/Wi-Fi/VPN), when in the background, and optionally completely revoke NETWORK permission.

>Yes GrapheneOS has the exact same functionality, DivestOS Network toggle is the exact same developed by GrapheneOS.

nostr:npub1gd3h5vg6zhcuy5a46crh32m4gjkx8xugu95wwgj2jqx55sfgxxpst7cn8c where can I find in GraoheneOS this settings i.e. restrict network for each app by connection type: cellular/wifi/vpn?

>>Network Restriction: DivestOS already lets you restrict network for each app by connection type (cellular/Wi-Fi/VPN), when in the background, and optionally completely revoke NETWORK permission.

>Yes GrapheneOS has the exact same functionality, DivestOS Network toggle is the exact same developed by GrapheneOS.

GrapheneOS lies everywhere. This is from their forum. Those settings are implemented in DivestOS.

Another thing is that DivestOS does not recommend using MicroG.

https://discuss.grapheneos.org/d/8831-suggest-features-for-more-privacy

" GrapheneOS

In app info, under "Mobile data and Wi-Fi, implement a large range of toggles(allow network, Mobile data, Background data, VPN data, unrestricted data usage) instead of only background data and Unrestricted data usage.

These toggles from LineageOS don't work correctly. DivestOS didn't include them. GrapheneOS won't be adding leaky features. Our Network toggle does not have leaks itself like these toggles. App communication allows apps to communicate within a profile which means you rely on apps enforcing the permission model. Our App Communication Scopes feature will provide the ability to control this within profiles rather than needing to split up apps via separate profiles."

This post from GrapheneOS forum confirms that nostr:npub1gd3h5vg6zhcuy5a46crh32m4gjkx8xugu95wwgj2jqx55sfgxxpst7cn8c lied above in his statement. Those people are 100% unreliable.