Comment by vlovich123 | Hacker News Reader

Comment by vlovich123 | Hacker News Reader

Parent Full thread

> Certainly MTE was always pushed as a debugging feature only.

This claim seems to come from ARM marketing but every SW company applying it - notably Google which I believe may have worked with ARM on this - mention of these types of tags in a security context (I believe Herb Sutter also talks about this as a way to harden c++ code). In fact, it’s seen as one very important way to harden existing legacy c/c++ code (and even unsafe Rust). There’s a big difference between 100% success rate and 1/16th - while you will still get an exploit through a 1/16th chance, the chances of detection raise significantly which isn’t nothing in a security context as it leaves a trail of breadcrumbs to investigate.

> It will take more fundamental mitigations that address the root issue of memory corruption, like MTE, in order to dramatically raise the bar for attackers.

https://googleprojectzero.blogspot.com/2024/06/driving-forwa...

> Hardware memory tagging may fix some security pitfalls of C++, while still allowing high performance. We are looking forward to see a more broad adoption of hardware memory tagging in the future and suggest using Scan on top of hardware memory tagging to fix temporary memory safety for C++

https://security.googleblog.com/2022/05/retrofitting-tempora...

Of course MTE + Scan described above may not be vulnerable to this attack, but my point stands that MTE is very much viewed as a memory safety hardening feature (and thus the security implications that come with safety hardening).

This isn’t that bad news either. It may leave existing chips vulnerable but the next iteration of MTE will probably account for this problem (assuming you can’t patch microcode to solve this).

Are Google really pushing it a 'proper' security feature? You've quoted a line at the end of a blog that doesn't elaborate further. In the android documentation for instance it stats '[MTE] helps detect use-after-free and buffer-overflow bugs': https://source.android.com/docs/security/test/memory-safety/... without making any stronger claims.

> This isn’t that bad news either. It may leave existing chips vulnerable but the next iteration of MTE will probably account for this problem (assuming you can’t patch microcode to solve this).

I might argue fixing is is actively bad. Helps push the idea this is a feature to actually use for security rather than augment bug detection. Still fixing it shouldn't be too hard, just speculate as you do currently but always assume the tag check passes so you get the same speculative behaviour regardless of tag values (likely easier said than done of course, probably some fun corner cases where they'd still differ).

I’d say yes. Reading the blogs fully (and reading comments from people like Herb) makes it pretty clear it’s seen as a defense in depth mechanism. Yes it’s a debugging tool but since it’s running always at runtime it’s also usable for security purposes.

Whether it should be used for security or not is irrelevant - it clearly will be and I don’t see why it’s inherently undesirable. Seems like a useful technique to further raise the complexity of exploit chains needed to execute an attack and in some applications the speculation bypass may not even matter (eh CHERI + MTE is not subject to this attack based on what’s been written).

The annoying thing is that ARM engineers took your position instead of realizing it will be used for security applications anyway and fixing the speculation issue during the design phase since they did know about this.

MTE can be enabled in two modes. One is "synchronous": tag checking occurs on the relevant load/store instruction and will raise a segmentation fault immediately in case of a mismatch; this mode is slower but retains information about where the bad memory access was (i.e., hence intended for debugging). The second mode is asynchronous, where any mismatches are only raised after a context switch; this mode has minimal overhead but loses relevant debugging information (i.e., hence intended as a run-time protection).

The difference between 100% reliability and 7% reliability in this environment might exceed a million dollars.

Reply on news.ycombinator.com