4 ms·
I mostly agree with you (UAF is more interesting but more difficult that bound checking), but I would nitpick on details: - yes you can opt-in and opt-out on a
by renox 11y ago
I mostly agree with you (UAF is more interesting but more difficult that bound checking), but I would nitpick on details:
- yes you can opt-in and opt-out on a case-by-case basis in Rust for bound checking but can you globally remove checks and globally force checks?
- as for UAF protection being non local, a true UAF protection true but a 99% solution such as overwriting the data with know garbage on free (0xDEADBEEF) and ensuring that the allocator doesn't reuse virtual addresses may be good enough in practice, no?
But yes it's probably too expensive to release with such configuration..
- pcwalton 11y ago> - yes you can opt-in and opt-out on a case-by-case basis in Rust for bound checking but can you globally remove checks and globally force checks? No. Nobody has asked for it, because nearly all bounds checks in Rust just don't matter from a performance point of view, and thus there is no reason to remove them. > - as for UAF protection being non local, a true UAF protection true but a 99% solution such as overwriting the data with know garbage on free (0xDEADBEEF) and ensuring that the allocator doesn't reuse virtual addresses may be good enough in practice, no? You can't avoid reuse of virtual addresses. That would have terrible cache implications. The only thing that sorta works is something like WebKit's PartitionAlloc, but that only mitigates some exploitation scenarios. There is no easy solution to UAF.
- renox 11y ago> You can't avoid reuse of virtual addresses. That would have terrible cache implications. --> terrible TLB implications > There is no easy solution to UAF. Agreed.