You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the recurring themes that comes up is the use of a custom target for our SGX enclaves. We've discussed this a long time ago, but decided against it because it was more complexity than it was worth at the time.
However, as our dependencies get more sophisticated, it's worth revisiting. If we had a custom target, e.g x86_64-mobilecoin-none-sgx , we could:
Delete the mc-crypto-rand crate, since getrandom can be configured to use rdrand.
Delete our fork of cpufeatures, since it does the right thing and uses target features when target_env = sgx.
The downside of this is that we can never use a stable rust for enclave builds. If we built an target, this could be useful. It may not be a practical issue, since allocators are not stabilized, but it's worth considering.
The text was updated successfully, but these errors were encountered:
One of the recurring themes that comes up is the use of a custom target for our SGX enclaves. We've discussed this a long time ago, but decided against it because it was more complexity than it was worth at the time.
However, as our dependencies get more sophisticated, it's worth revisiting. If we had a custom target, e.g
x86_64-mobilecoin-none-sgx
, we could:mc-crypto-rand
crate, since getrandom can be configured to userdrand
.cpufeatures
, since it does the right thing and uses target features whentarget_env = sgx
.The downside of this is that we can never use a stable rust for enclave builds. If we built an target, this could be useful. It may not be a practical issue, since allocators are not stabilized, but it's worth considering.
The text was updated successfully, but these errors were encountered: