I'm Ryan from Estonia. I have a Ph.D. in cryptoloogie and working on a project that will use Intel SGX for government customers. We would like to use Rust for this purpose and I have a question about Rust SGX support.
I noticed that Rust official distribution already has a target for SGX, which is developed by a private company called Fornatix in America. However, this SGX target is very tightly coupled with this vendor's tools and I think it's American vendor's way to pushing their own products through Rust. Note that SGX is not like other compiler targets, because it requires at least the following highly vendor specific tools:
A custom loader that can load SGX binaries into Enclaves.
A custom file format that specifies what parts of the the executable binary should be used in the enclave sha256 computation
A custom Input/Output protocol between the enclave and host
Currently all these parts are vendor specific and NOT part of the standard Rust distribution, so I want to ask how you decided to choose this vendor over someone else. For large government projects, using an unqualified vendor's tools is complete no no, and I would like to understand how the Rust team decided to merge this vendor's code? (If your answer is "we will do whatever we want because its our code" that fine, but it will be good to know if that's your answer.)
Another licensing question (which my company is also hiring a lawyer for). What are the attribution requirements for using mainline Rust compiler with SGX. Can we just say Rust community, or do we need to individually attribute it to the American Vendor? (Of course we will write our own loader etc.)
We really want to use Rust for this project, but it seems SGX target was added without an open RFC process.
I don't think we usually have RFCs for adding new targets. Also, this target is actually explicitly called x86_64-fortanix-unknown-sgx, so it seems clear that everyone is aware that this is Fortanix-specific.
Here's some relevant stuff I found in the repo:
I think what happened is, someone proposed adding a Fortanix SGX target, and people were largely happy to have support for that target.
The way I read this is, if you're up for doing the work to add platform support for SGX to work with another vendor, that would likely be welcomed. You may be requested to deduplicate whatever can be deduplicated between the Fortanix target and your new one, though, but that's probably a good thing anyway?
The Rust project didn't choose to "bless" Fortanix as our SGX implementation, but it's just yet another tier 2 target supported by the compiler. If other SGX implementations want to be supported I (personally) see no problem, as long as they do the implementation work and they commit to keeping it up to date and maintained. The reason why we only support Fortanix's SGX implementation at the moment is that they're the only ones who did the work required so far.
By the way, an RFC was recently opened to formalize our policies about adding and promoting targets. The current text doesn't require an RFC to add new targets, and Fortanix's SGX implementation meets all the proposed requirements for a tier 2 target. Still, we'd love your feedback on the RFC if there is something you want to change!
Please note that Fortanix is a global company with offices in US, EU and India. You might also be interested to know that Intel is a large investor in Fortanix.
This target & toolchain has been developed over time as the first available public open source SDK for SGX (even before Intel's Linux SDK was available!) from research originally done at the University of California, Berkeley. The entire toolchain, including the parts not officially part of the Rust project, is open source. If you'd like to know more about how this target came to be, please take a look at the following videos:
All SGX toolchains require vendor-specific tools, there's no way around that at the moment. There are other Rust targets that require lots of external tooling to be useful: WebAssembly comes to mind. You might also argue that all of the Windows targets require a large amount of vendor-specific tools.
There shouldn't be any difference between the qualification of the Rust project and the Fortanix tools needed for this target: both are available under a relatively permissive open source license without any warranty.
If you have specific government certification or qualification needs, we might be able to help you with that. Feel free to contact me at jethro@fortanix.com.
For any technical questions regarding the target I'd like to invite you to our public slack channel for SGX experts: Slack
The file format is actually intended such that the entire file can be used in the SHA256 computation with regular hashing tools without doing any parsing.
This target & toolchain has been developed over time as the first available public open source SDK for SGX (even before Intel's Linux SDK was available!) from research originally done at the University of California, Berkeley. The entire toolchain, including the parts not officially part of the Rust project, is open source
Yes, I know it's open source, but that doesn't mean anything. Apple's source code is opensource, ( https://opensource.apple.com/ ) but I doubt I can use anything from there (not that I want to )
The question for a compiler distribution however is that, does it want to be a Trojan horse for a specific vendor, or should it be neutral in how it can be used in broader context, especially when there are other alternatives available. (These alternatives might not be as mature, but I'd think that Rust would have open process to decide what should and should not go into the compiler official distribution.)
There shouldn't be any difference between the qualification of the Rust project and the Fortanix tools needed for this target: both are available under a relatively permissive open source license without any warranty.
Source code license is not the only thing that goes into certification process.
Ability to verify software by independent tools is also a crucial requirement. Instead of using PE or ELF file format, SGX Rust distribution has it's own file format, which not a single standard tool can read/write/verify...
The input/output interface between the host and TEE (which the target calls Upcalls) is designed with whatever the vendor's engineer could imagine. The certification process might find that interface unsuitable.
And this is just top of technical list.
If you have specific government certification or qualification needs, we might be able to help you with that. Feel free to contact me at jethro@fortanix.com.
No, if you ever need to get government certification in Estinoa, we can help you with that
The file format is actually intended such that the entire file can be used in the SHA256 computation with regular hashing tools without doing any parsing.
The side effect of this decision is that none of the opensource tools like readelf etc., can be used. Without idenpendent third party tools, it's hard to convince that the file format that Fornatix Rust SGX uses is not actually including a malware or an adware in its SHA256 computation.
Also, SHA256 of the entire file only works if you only want to include the data and text section of the enclave. If you want to measure the stack and heap as well (which you might want to make sure the memory layout of the enclave is in a given state), this file format doesn't work.
I'd appreciate it if you'd assume I'm acting in good faith. I'd say my track record speaks for itself, having been active in the Rust community for nearly 5 years. My goal is to present the best-designed, easiest-to-use SGX toolchain with practical security trade-offs following the spirit of Rust.
As you can see from the other replies to this topic, such a process already exists and there is nothing closed about it.
Why not?
Unlike other existing public SGX interfaces, the Fortanix SGX ABI is well-documented in terms of both calling convention and ABI. The documentation also includes a clear rationale for the designs. These kinds of specifications and design documents are invaluable during any certification process.
I'd say it's actually harder to verify enclaves for toolchains that don't use the SGX stream format. Unlike what you claim, the heap and stack can be measured in the SGX stream format. The SGX stream format is the native format of the CPU so all enclaves must eventually be converted into it as a last step in the enclave loading process.
Unlike the toolchains that don't use the SGX stream format natively, we don't rely on any special tools to prepare the SGX stream format at load time. Therefore, it's much clearer what the enclave is that is actually being signed: there is no hidden “magic” in the loader in terms of inserting heap, stacks, guard pages, TCSes, etc.
Unlike other existing public SGX interfaces, the Fortanix SGX ABI is well-documented in terms of both calling convention and ABI. The documentation also includes a clear rationale for the designs. These kinds of specifications and design documents are invaluable during any certification process.
We documented doesn't mean it is also well thought out. Also here well thought out means, what a certification body thinks is well thought out, not what Rust or a vendor thinks is well thought out. As a general purpose compiler, I'd think that the Rust mainline distribution will enable people to build such tools, not be just be a trojan for some vendor.
Of course, Rust can do whatever it wants, but please state that clearly in your mission statements so that non-technical people making expensive decisions are not mislead by marketing.
I'd say it's actually harder to verify enclaves for toolchains that don't use the SGX stream format. Unlike what you claim, the heap and stack can be and are measured in the SGX stream format.
Yes, it's measured with a static value on heap and stack so that someone can run sha256 on your "stream format" but that's not the only use case. If I want to put the MRSIGNER public key in the heap right before loading the enclave, please tell me which open-source sha256 binary can help me compute the hash of the enclave for such a use case.
By using this vendor specific stream format, now not only will none of the standard sha256 binary tools will work, but I have also lost the ability to run standard malware analysis tools on the binary right before loading it into the enclave.
I think the key point which was maybe unclear here is that the Rust project has in no way offered special blessing to or promotion of Fortanix's SGX API/ABI. If you wanted to use something different, you'd go through the same process the Fortanix folks did to add it to get it accepted as a compiler target.
There is no blessing on Rust's part for Fortanix's work. It's simply the first option anyone's put the work in to add.
As others have said: Fortanix sent us patches, we evaluated their quality and suitability, and then we merged them. If someone else sends us patches, we will make the same evaluation. There's no conspiracy to promote a specific vendor; we integrate things that people develop if they look reasonable to us, and we don't integrate things that people don't develop or submit.
Well, and from the target name, it's completely possible for there to be multiple SGX targets at the same time. So the Fortanix one doesn't preclude a different one, IIUC.
)