3 ms·

In one of his latest video he show how it is going to work for array access: by default it's checked, but you have a directive to make one (or a block) of array

by renox 11y ago

In one of his latest video he show how it is going to work for array access: by default it's checked, but you have a directive to make one (or a block) of array access unchecked and then you have a global directive which can change the default to check all the array access or NOT check all the array access. So you get the full range from safe array access to C-like performance and with the possibility of dropping the checks only where this impact really performance. Memory safety isn't limited to array access, but I really like the idea of this kind of control (even though for library this could create issue, I think that there are plans to allow the use of an 'ANDF' like format for libraries).

pcwalton 11y ago
Bounds checking isn't as interesting as use-after-free protection (like the borrow check) for a couple of reasons: (1) you can easily opt-in and opt-out on a case-by-case basis (even in Rust), whereas UAF protection is nonlocal; (2) bounds checks rarely if ever show up in profiles with a well-designed iterator library and an optimizing compiler.
- 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.

by renox 11y ago

pcwalton 11y ago

Bounds checking isn't as interesting as use-after-free protection (like the borrow check) for a couple of reasons: (1) you can easily opt-in and opt-out on a case-by-case basis (even in Rust), whereas UAF protection is nonlocal; (2) bounds checks rarely if ever show up in profiles with a well-designed iterator library and an optimizing compiler.

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.