Hacker News new | past | comments | ask | show | jobs | submit login

My point was just that current security best practice already requires indexing a separate data structure for bookkeeping. With CHERI, even if your metadata is stored in an adjacent header, to read or write that memory you have to lookup its pool to derive a wider pointer encompassing that header. (If not, as the article describes your allocator is misusing CHERI.)

But certainly with CHERI you could recover some optimization opportunities. For example, the block length can be derived directly from the pointer, which could make it easier to lookup the parent pool. And CHERI pointers preserve some bits for application pointer tagging, making it easier to implement typed allocations.

However, you still have to be careful. CHERI provides spatial safety, not temporal safety--double frees, dangling pointers, etc--so you may not want to reuse the application-visible portion of a block for bookkeeping purposes. Similarly, ASLR still retains much of its benefit, as does Rust--static enforcement of temporal safety, not spatial safety, is the principal value-add of Rust (spatial safety in Rust primarily comes from the library, not the language per se).




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: