search

GaloisInc / BESSPIN-Tool-Suite

The core tool of the BESSPIN Framework.
Other
5 stars 2 forks source link

Add a mode that leaks pointers instead of strings #1236

Closed brooksdavis closed 3 years ago

brooksdavis commented 3 years ago

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.

rtadros125 commented 3 years ago

@austinhroach I can add this feature to the branch no problem. @brooksdavis Any comments/recommendations before I start doing that?

brooksdavis commented 3 years ago

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.

rtadros125 commented 3 years ago

@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.

brooksdavis commented 3 years ago

OK, I guess the importance of comparability of results between performers is a DARPA question.

austinhroach commented 3 years ago

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.

rtadros125 commented 3 years ago

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.