Closed brooksdavis closed 3 years ago
@austinhroach I can add this feature to the branch no problem. @brooksdavis Any comments/recommendations before I start doing that?
I haven't tested the code without CHERI, but it shouldn't be hard to make it work (leak secrets) if it doesn't already.
@brooksdavis I think I was not clear enough. I was going to make it run twice (1. strings. 2. pointers) for Cheri only, and only strings for non-Cheri. And I was going to open a ticket for making it run twice for non-Cheri as a future work.
OK, I guess the importance of comparability of results between performers is a DARPA question.
That's a fair point. Maybe the better course of action is to just cherry-pick the architecture-agnostic changes to control.c and control.h for baseline testgen inclusion, without the CHERI-specific macros and enabled with __IEX_GEN__POINTERS__
or something. Then SRI/Cambridge can add back the CHERI-specific macros when running it, to demonstrate that protection is achievable with this small set of source code modifications.
Based on internal conversations, the conclusion is to close this PR, but keep the branch for future integration. I have opened #1239 to track this suggestion.
The new code stores a secret pointer surrounded by two pads pointers (NULL-derived capabilities on CHERI). The secret pointer is stored without the GLOBAL bit set (making it LOCAL) and when allocating results buffers, the STORE_LOCAL permission is stripped from the buffer. This causes a fault when attempting to retrieve the secret value.
Enable this mode on SRI/Cambridge systems.