Props to the blog post for being quite well written: easy to understand, yet also thorough enough to explain exactly what Ginseng is and how it works. By "easy

Props to the blog post for being quite well written: easy to understand, yet also thorough enough to explain exactly what Ginseng is and how it works. By "easy to understand" I don't just mean the introduction, which goes over the motivation at a high level, but also the lower-level explanation, with a handy C and assembly comparison that helps explain what the transformation actually does. ...On the other hand, the design itself seems like a pretty massive hack. The goal is to turn parts of a userland process into the equivalent of a TEE component, without having to manually separate the codebase into two pieces and set up IPC between them. But although that kind of "automagic" approach is easier to use, it also makes it really easy to write security flaws. For instance, in the example code: void hmac_sha1(sensitive long key_top, sensitive long key_bottom, const uint8_t *data, uint8_t *result) { sensitive long tmp_key_top, tmp_key_bottom; /* all other variables are insensitive */ /* HMAC_SHA1 implementation */ } It's quite dangerous to say that all other variables are insensitive! It's hard to say for sure without seeing the actual implementation, but SHA-1 requires first expanding the message into a state of 80 32-bit words, before performing 80 rounds of hashing on them. If the state is treated as insensitive, another core could read it out before it actually goes through hashing, in which case the key could be easily recovered. This design might be secure if the SHA-1 function is separate and itself marks all state as sensitive, as long as the key never leaks into memory in between, but that's not how SHA-1 implementations usually work, so I'm pretty suspicious. I tried to find the actual code to determine whether it's actually vulnerable, but failed: it's supposed to be released as open source [1], but the instructions involve downloading from a GitHub repo [2] which is currently marked as private, I guess by mistake. ...I don't really understand why Ginseng doesn't just mark all variables in a sensitive function as sensitive; it's not like memory for the secure stack is particularly scarce. That still leaves other attack vectors, though. [1] http://www.ruf.rice.edu/~mobile/ginseng.html http://www.ruf.rice.edu/~mobile/ginseng.html [2] https://github.com/susienme/ndss2019_ginseng_arm-trusted-firmware.git https://github.com/susienme/ndss2019_ginseng_arm-trusted-fir...