4 ms·
Although I was prepared to be impressed by project zero's work here I find that I'm not. There's an efuse based revocation mechanism. It isn't used for every v
by debatem1 9y ago
Although I was prepared to be impressed by project zero's work here I find that I'm not.
There's an efuse based revocation mechanism. It isn't used for every vulnerability. That's unfortunate but understandable-- fuses are a scarce resource. Given that, signers should be more careful about the code they sign in the first place to avoid stressing that resource.
Having said that, at the end of the day this is still just a security feature that is painful to use. That doesn't make it a vulnerability in and of itself, and dressing it up as one feels like a stretch.
- ktRolster 9y agosigners should be more careful about the code they sign in the first place I agree with your sentiment, but that's not going to happen.
- debatem1 9y agoI'm not sure why not. Some of the same groups that sign this code also do formal verification of other codebases, for instance FSBLs. It seems reasonable that they would try similar approaches on TZ code given the scarcity of fuses.
- AstralStorm 9y agoGood joke. There are layers of proprietary software where nobody can audit involved. Can you trust a single auditor ever too? Even an automated exhaustive verifier can be buggy... oot more importantly incomplete if parallelism is considered.
- willvarfar 9y agoIt doesn't seem to have been used for any vulnerability. Including the one thats linked in the post that allow arbitrary code execution...