Just don't use a password so weak it can be bruted for your FDE and you're fine. Treat it like most existing software-only solutions like TrueCrypt, not like a magic black box that can make a 4 digit number into a secure password. Even if the hardware were "secure" it still wouldn't be advisable to rely on it as a successful reverse engineering of the hardware could still result in a bruteforce attack on your key. And while that may be high effort and expensive, it's certainly not impossible. Never trust a half measure, this sort of TPM/Secure Enclave approach is a half measure.
Well hold on.. there are several issues. One is that there is an exploit allowing arbitrary code execution in the trustzone. This immediate problem should be fixed.
The second is that allowing a firmware updates to trustzone code means that Google could push an update which allows them to retrieve keys. Such updates should only be allowed if the user accepts them. How the user is supposed to know the difference between a security fix vs. Google trying to break into their phone is the real issue.
But IOS has this same issue. If you accept a firmware update from Apple, maybe it includes a pin logger.
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.
The section on extracting the key mentions the "Widevine DRM application" and "privilege escalation from QSEE"
Could the problem be fixed if the manufacturer used TrustZone exclusively for store key/encrypt/decrypt operations, eliminating the support for DRM and Trustlets?
So any Android phone currently on the market is basically unfixable?