4 ms·

Sure, but hardware memory tagging is also not proven to work. Anyway, it's unclear with which criteria you're judging "proven not to work" with as we're both t

Sure, but hardware memory tagging is also not proven to work. Anyway, it's unclear with which criteria you're judging "proven not to work" with as we're both typing via the software right now, unlike a hardware solution.

pjmlp 6y ago
Sure it is, thanks to CVE database entries. Here are Google's rationale for enabling it on Android, > Platform hardening - We’ve expanded use of compiler-based sanitizers in security-critical components, including BoundSan, IntSan, CFI, and Shadow-Call Stack. We’re also enabling heap pointer tagging for apps targeting Android 11 or higher, to help apps catch memory issues in production. These hardening improvements may surface more repeatable/reproducible app crashes in your code, so please test your apps. We've used HWAsan to find and fix many memory errors in the system, and we now offer HWAsan-enabled system images to help you find such issues in your apps. https://android-developers.googleblog.com/2020/02/Android-11-developer-preview.html https://android-developers.googleblog.com/2020/02/Android-11... > Starting in Android R, for 64-bit processes, all heap allocations have an implementation defined tag set in the top byte of the pointer on devices with kernel support for ARM Top-byte Ignore (TBI). Any application that modifies this tag is terminated when the tag is checked during deallocation. This is necessary for future hardware with ARM Memory Tagging Extension (MTE) support. https://source.android.com/devices/tech/debug/tagged-pointers https://source.android.com/devices/tech/debug/tagged-pointer... "Adopting the Arm Memory Tagging Extension in Android" https://security.googleblog.com/2019/08/adopting-arm-memory-tagging-extension.html https://security.googleblog.com/2019/08/adopting-arm-memory-... "Detecting Memory Corruption Bugs With HWASan" > Native code in memory-unsafe languages like C and C++ is often vulnerable to memory corruption bugs. Our data shows that issues like use-after-free, double-free, and heap buffer overflows generally constitute more than 65% of High & Critical security bugs in Chrome and Android. > HWASan is based on memory tagging and depends on the Top Byte Ignore feature present in all 64-bit ARM CPUs and the associated kernel support. Every memory allocation is assigned a random 8-bit tag that is stored in the most significant byte (MSB) of the address, but ignored by the CPU. As a result, this tagged pointer can be used in place of a regular pointer without any code changes. https://android-developers.googleblog.com/2020/02/detecting-memory-corruption-bugs-with-hwasan.html https://android-developers.googleblog.com/2020/02/detecting-... The post is already too long just with Android, otherwise I would provide similar references for iOS, Solaris on SPARC, Azure Sphere / Phonon.
- deleted 6y ago
  [deleted]
- monadic2 6y ago
  Why does this point to a hardware-level protection rather than simply removing the dependency on C? I mean wouldn't moving to rust mitigate most of these vulnerabilities? I can't help but think that if hardware protection from vulnerabilities were useful we would have enabled them 30-40 years ago. I just don't see any value of this to the end-user: the result (a crash) is the same. If they can get it to work it might be beneficial, but it would also validate the idea that C is broken as a system language because it can't know at compile-time whether or not an fault will occur on memory access, which has been proven to be the correct way to reason about memory.
  - pjmlp 6y ago
    Because it still won't protect against unsafe code in Rust. // very contrived example fn main() { let mut data = vec!(1, 3, 4); unsafe { let ptr = data.as_mut_ptr(); *(ptr.offset(1024)) = 1; } } At some level there is some unsafe code, even if in pure Assembly. There problem with C is that it taints everything due to strings, arrays and UB. By the way, Android is also taking steps to introduce Rust on its codebase, hence the talks started by Google at Linux Plumbers conference. As much as I love to rant on C, as long as POSIX based software is relevant, if WG 14 isn't willing to improve its security, hardware solutions are the only way.
    - monadic2 6y ago
      Alright I guess I see what you’re saying, and this does seem like natural progress from address sanitization.

pjmlp 6y ago

Sure it is, thanks to CVE database entries. Here are Google's rationale for enabling it on Android, > Platform hardening - We’ve expanded use of compiler-based sanitizers in security-critical components, including BoundSan, IntSan, CFI, and Shadow-Call Stack. We’re also enabling heap pointer tagging for apps targeting Android 11 or higher, to help apps catch memory issues in production. These hardening improvements may surface more repeatable/reproducible app crashes in your code, so please test your apps. We've used HWAsan to find and fix many memory errors in the system, and we now offer HWAsan-enabled system images to help you find such issues in your apps. https://android-developers.googleblog.com/2020/02/Android-11-developer-preview.html https://android-developers.googleblog.com/2020/02/Android-11... > Starting in Android R, for 64-bit processes, all heap allocations have an implementation defined tag set in the top byte of the pointer on devices with kernel support for ARM Top-byte Ignore (TBI). Any application that modifies this tag is terminated when the tag is checked during deallocation. This is necessary for future hardware with ARM Memory Tagging Extension (MTE) support. https://source.android.com/devices/tech/debug/tagged-pointers https://source.android.com/devices/tech/debug/tagged-pointer... "Adopting the Arm Memory Tagging Extension in Android" https://security.googleblog.com/2019/08/adopting-arm-memory-tagging-extension.html https://security.googleblog.com/2019/08/adopting-arm-memory-... "Detecting Memory Corruption Bugs With HWASan" > Native code in memory-unsafe languages like C and C++ is often vulnerable to memory corruption bugs. Our data shows that issues like use-after-free, double-free, and heap buffer overflows generally constitute more than 65% of High & Critical security bugs in Chrome and Android. > HWASan is based on memory tagging and depends on the Top Byte Ignore feature present in all 64-bit ARM CPUs and the associated kernel support. Every memory allocation is assigned a random 8-bit tag that is stored in the most significant byte (MSB) of the address, but ignored by the CPU. As a result, this tagged pointer can be used in place of a regular pointer without any code changes. https://android-developers.googleblog.com/2020/02/detecting-memory-corruption-bugs-with-hwasan.html https://android-developers.googleblog.com/2020/02/detecting-... The post is already too long just with Android, otherwise I would provide similar references for iOS, Solaris on SPARC, Azure Sphere / Phonon.

deleted 6y ago
[deleted]
monadic2 6y ago
Why does this point to a hardware-level protection rather than simply removing the dependency on C? I mean wouldn't moving to rust mitigate most of these vulnerabilities? I can't help but think that if hardware protection from vulnerabilities were useful we would have enabled them 30-40 years ago. I just don't see any value of this to the end-user: the result (a crash) is the same. If they can get it to work it might be beneficial, but it would also validate the idea that C is broken as a system language because it can't know at compile-time whether or not an fault will occur on memory access, which has been proven to be the correct way to reason about memory.
- pjmlp 6y ago
  Because it still won't protect against unsafe code in Rust. // very contrived example fn main() { let mut data = vec!(1, 3, 4); unsafe { let ptr = data.as_mut_ptr(); *(ptr.offset(1024)) = 1; } } At some level there is some unsafe code, even if in pure Assembly. There problem with C is that it taints everything due to strings, arrays and UB. By the way, Android is also taking steps to introduce Rust on its codebase, hence the talks started by Google at Linux Plumbers conference. As much as I love to rant on C, as long as POSIX based software is relevant, if WG 14 isn't willing to improve its security, hardware solutions are the only way.
  - monadic2 6y ago
    Alright I guess I see what you’re saying, and this does seem like natural progress from address sanitization.