Sweet! Daniel Rosenberg's encryption with casefolding on ext4 feature has landed upstream! This has been an out of tree dependency needed for booting AOSP, so its great its been merged!
git.kernel.org/pub/scm/linux/
Conversation
I think all that's left needed for generic AOSP functionality right now is the PR_SET_VMA_ANON_NAME feature.
android.googlesource.com/kernel/common/
4
This Tweet was deleted by the Tweet author. Learn more
It's also unfortunate that it requires an extra system call. Bionic removed a bunch of the labels due to the cost added to thread spawning. They're almost always set on the whole memory region after an mmap or mprotect call. Requiring extra system calls deters using the feature.
1
This Tweet was deleted by the Tweet author. Learn more
It would help a bit to be able to set more than one at a time but it would still be worse than being able to set them with mmap / mprotect.
So, for example, hardened_malloc uses mappings directly for sizes above either 128k (default) or 16k (extended size classes disabled).
1
It takes 2 calls to allocate a large allocation (mmap region including guards, mprotect usable region in between guards) and 1-2 calls to deallocate (MAP_FIXED mmap into a quarantined region and also munmap the mapping pushed out of the quarantine once it's full).
1
Basic labels add 1 system call for allocation and 1 for deallocation with similar locking. No real point using separate labels for guards because it's already a separate VMA from being PROT_NONE and marking it as a large allocation is self-explanatory.
Other case that matters is adding back labels for free slabs pushed out of the empty slab cache which are purged with mmap MAP_FIXED back to a fresh PROT_NONE mapping. Similarly don't do multiple of those at once. Only do a bunch during initialization and it's not important.
1
1
Expect other use cases are similar. Bionic could theoretically use a single call to mark all of the thread related mappings but it would complicate the code and I don't think they'd bother with it if it wasn't trivial right after the mmap/mprotect calls.