There's not much downside to only having 1 slot per slab once slab allocations are 4096 byte aligned, which is what we refer to as extended size classes. This goes nicely with the guard slab feature.
By default, there's an unused guard slab between every possible usable slab that's left as unused PROT_NONE memory.
If the slabs have 1 slot, the allocations have guaranteed guard pages without paying the cost of actually making system calls to set them up during regular usage.
Having slabs with 1 slot originally wasn't supported but github.com/GrapheneOS/har… added support for it.
This does need a tiny little bit of unnecessary work but avoids other work (bitmaps). It's insignificant for allocations this large, especially with zero-on-free, etc. enabled.
The normal non-extended size classes are too small to be all be aligned to 4096. There are 4 size classes per doubling in size to have ~20% maximum waste from rounding, like jemalloc. Extended size classes are optional since hardened_malloc can happily use mappings instead.
It would also be nice to go through the smaller size classes to see if it makes sense to reduce the number of slots in some cases to further reduce memory usage. It's not really that much of a problem by itself but it will help make the slab allocation quarantine use less memory.
Further work will be figuring out how to efficiently purge slabs entirely consisting of quarantined allocations without adding too much overhead. It could start out being done only as part of malloc_trim which Android calls regularly via M_PURGE for background apps, etc.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Likely going to have very positive news to announce about GrapheneOS in the near future.
It's unfortunate that others decided to pick up the torch of fighting an underhanded war against us after Copperhead started to stop. The past month SHOULD have been a huge relief, but no...
Nevertheless, there's probably going to be some great news. I hope others realize that waging a misguided war against us is not going to work out to their benefit and they can either stop or destroy themselves in the long run. I'll happily put very substantial resources into it.
One consequence of all the nonsense with Copperhead was lack of time to hire people. Now we have a lot of money we need to spend along with a lot more time and resources being freed up. I'll happily spend a substantial amount paying people to counter any further shenanigans.
Despite previously claiming to be my friend and a supporter of my work, @nickcalyx has consistently engaged in trying to portray me as being deranged/crazy. He has participated in persistent harassment and bullying targeting me. It's far worse than anything Copperhead ever did.
I was naive and repeatedly tried appealing to him for help against attacks from Copperhead and then the even worse behavior from his own community.
Copperhead has stopped their attacks, at least for the time being, but Calyx has continued carrying it on and it's worse than ever.
Calyx took full advantage of what Copperhead was doing and tried to use it as a way to benefit themselves. They actively engaged in making it worse while playing the both sides angle. They've now done things far worse than anything Copperhead did in years of trying to hurt us.
Traditional epoll wakes every thread and they race to accept the connection. EPOLLEXCLUSIVE fixes it but uses LIFO order.
LIFO order is terrible for a web server. HTTP connections are generally long-lived and reused for mixed / varying workloads. That's even more true with HTTP/2 where clients are only supposed to make a single connection to each server and multiplex everything over it concurrently.
In a standard nginx setup on Linux, it uses EPOLLEXCLUSIVE. This gives nearly all the connections to the same worker until it starts getting overloaded. Even then, the most overloaded workers still keep getting the most connections among handling other events. It's pretty awful.
We've archived these tweets where Copperhead's CEO admits to them tracking devices via unique identifiers and using them as part of the update system.
He admits that their phone sellers with Copperhead emails, etc. have databases mapping unique identifiers to the customers too.
His excuse is that tracking devices via unique identifiers available to update server doesn't count as tracking users. They've designed it in a way that they can ship an update targeting a device. The excuse is they don't know which user has which device, but their seller does.
In that same thread, he also peddles the usual lie that Copperhead is source available. Meanwhile, the sources are not published and are not available for review. Multiple researchers including a Whonix developer have attempted to get access to the sources and could not get it.
@cankerwort_@sethisimmons@CopperheadOS@mamushi_io@GrapheneOS They're the ones choosing to a misinformation war against GrapheneOS along with threatening/intimidating anyone who contributes to the project, even people that are underage. You say it should be settled in court but they're making daily attacks on us causing lots of harm.
@cankerwort_@sethisimmons@CopperheadOS@mamushi_io@GrapheneOS GrapheneOS not a for-profit project. We're not selling any products. We're focused on building privacy and security technology. They're focusing all their resources on causing harm to us in any way that they can, and on marketing a product simply copy pasting our codebase.
@cankerwort_@sethisimmons@CopperheadOS@mamushi_io@GrapheneOS This is primarily not a legal dispute. It's largely a personal vendetta against me by James Donaldson and now also Max. Their poorly formed lawsuit against was primarily a way to exhaust my time, energy and resources along with intimidating people to stop them from contributing.