laginimaineb

(I work at doubleAI.) The benchmark numbers (90% wins, 2.24x speedup on average, with key attention workloads accelerated ~15x) are one part of the story. The other: AI-generated kernels can pass simple verifiers with room to spare and still break in production. Our writeup walks through one such case: a fused embedding-gradient + RMSNorm backward kernel. As an example, we took the fastest (highest scoring) submission on the benchmark, for this task, submitted by other competitors, put it in our training code, and... everything broke (the loss diverged). The bug turned out to be subtle and hard to nail down (even changing the input distribution or the optimiser made it invisible). More details are in our blogpost.

We find these kinds of bugs very interesting: defending against humans is not the same problem as defending against agents. As models are becoming more powerful, they're also getting great at subverting verifiers (going through the 'path of least resistance'). This means that stronger verifiers are becoming increasingly more necessary, something we at doubleAI specialise in. You can also read our previous blogposts where we discuss this.

Happy to answer technical questions.

Actually, I would imagine they are nothing like one another.

However, Exynos uses a TrustZone TEE implementation to implement the KeyMaster module, just like Qualcomm's Snapdragon. This means that unless that TEE implementation uses a hardware key which is not software accessible, the same issue would be present. Of course, reverse-engineering a new TEE implementation would take a long time... But it sounds like it could be fun.

You're right. Let's take a second to go over the issues:

1. The arbitrary code-execution in TZ has already been privately disclosed and fixed.

2. As for the second issue - I would argue that it's not an issue at all. TZ should be updated (otherwise how would they fix the TZ code-exec vulnerabilities?).

However, in this case gaining code execution in the TZ kernel directly leads to the disclosure of the keys which are meant to bind the KDF to your device. This is in direct contract with Apple's KDF. The key here is that software shouldn't be trusted, by design.

3. As for the last issue, I would argue that this is just a clever form of social-engineering. After all, who's to say they didn't just swap the phone with a dummy phone to make you insert the correct password?

However, in Android's case, you wouldn't even need to cooperate. OEMs could simply flash the new TZ code, extract the KeyMaster keys, and bruteforce the key. All without having any help from you.

I believe so.

I'll definitely try and get around to it sometime soon. However, I wouldn't be surprised if the situation is the same... After all, the KeyMaster module was initially only meant to keep encryption keys on the device, not to safeguard FDE.

FWIW, formal verification requires a complete and exact spec - the TZ kernel is very complex and interacts with nearly all the peripherals on the SoC, it doesn't just manage QSEE applications. I think creating a spec for something like that would be really hard.

Widevine DRM is integrated into virtually all Android phones. If you're building your own ROM, you could remove the widevine.bXX files from the ROM image itself - I've never tested it, but it could probably soft-fail. There's no other way to remove it.

Anyway, this specific issue has already been fixed (but there are probably more bugs lurking either there on in other trustlets).

I believe so

Don't think I'll collect it, but I will release all the details so people can do it themselves.

It will work on the Turbo! :)

But you'll either need a version old enough to be vulnerable to this TrustZone exploit, or you can wait a couple of weeks until I release a new exploit (which also works on the Turbo).

Thanks! I'm also on twitter in case that helps (@laginimaineb).

As for Sunshine - I'm publishing a new (even broader) zero-to-TZ saga, complete with exploits, but I'm not going to create a product out of it. So ultimately, as long as there are people behind Sunshine who are willing to make it work with relative ease, I'm sure most people won't mind spending a few dollars to unlock their device.

As for the more tech-savvy crowd; I hope they choose to do it themselves with the exploits provided - it is much more fun that way, IMHO.

AFAIK it's unknown - there's a controller on the SoC which is responsible for reading/writing the fuses, but its firmware is in mask ROM and isn't available. Perhaps it's a real chemical reaction? Maybe it's just emulated in firmware? Your guess is as good as mine.

In this case, it seems so. However, I must say I've reported many vulnerabilities to Google since and they've all been handled within that time-frame.

That's a great question! I didn't cover this in the blog post, but there is a primitive identical to the increment-by-one presented there, which allows me to decrement-by-one as well (I've gone into more detail in the exploit code: https://github.com/laginimaineb/cve-2014-7920-7921)

Thank you. Also, the map is mostly Thorin's, with only slight adaptations :)

Thanks! More to follow soon :)

Sure, see the first part of the blog post, under "Responsible Disclosure"

(Disclaimer: I'm the author of this blog) In this post I cover the development of a full TrustZone exploit in MSM8974 (Snapdragon 800) SoCs, resulting in arbitrary code execution in the "Secure World". I've also provided the full source code!

Please let me know if you have any questions/comments.

I've reversed those files in the past as well, and you're correct, they are TrustZone applications (like Widevine, DxDHCP, Keymaster and more). I have a script which can be used to reunite these pieces of code into an ELF file which can be loaded into IDA (more about this in about a month!)

Anyway, if you're looking to load arbitrary code into TZ, wait for the next blog post (approx. 2-3 days)!

Thanks for reading!

I haven't heard of such a project, but I'm not 100% sure I understand what you mean; are you asking if there are non-Android implementations on mediatek chips?

Actually, I haven't been able to write posts these five months because of the ongoing semester. The whole discovery to exploitation didn't take more than a week, AFAIR.

As for the next post (with full exploit code!), you can expect it within 3-4 days tops.

(Disclaimer: I'm the author of this blog)

In this post I describe an (initial) analysis of Qualcomm's TrustZone implementation, and a vulnerability that I've discovered which allowed complete arbitrary code execution within TrustZone (which I've responsibly disclosed to Qualcomm).

This is the first in a series of posts describing various kinds of vulnerabilities, so stick around if this interests you in any way!

In the following months, I'll be submitting detailed vulnerability write-ups and exploits for Android related vulnerabilities that I've discovered in the last year (but have been too busy to write about because of the academic year).

Please let me know if you have any questions/comments! I'll be more than happy to answer.