Initial Bazel Targets

[ghost]

Basic bazel configuration + 3 basic simplest targets have been ported for review of general direction to resolve #52 .

Some questions that popped up till this point:

• What is desired behavior when it comes cargo features such as align in sgx_libc. Do you want to trasnfer them to bazel BUILD files as well?
• What is desired behavior of cfg(not(target_env = "sgx")) from toml files. Cargo features are not fully supported the best withing rules_rust rules_rust#37. Alternative solution exists with configurable build

This is for now. If there is anything unclear happy to explain

[ghost]

Sorry for a delay. Moving jobs at the moment, which is taking more time then expected. Hope initial direction works for you. Want to nail the riskiest portions in the next PR. But we need to figure a way to circumvent cargo features, which wouldn't cause problems for you.

I can prepare an example with configurable builds which could be controlled via command flags/.bazelrc files.

[dingelish]

Hey @Sythanis , thank you so much for your contribution!! Your works are really helpful to us!!

Please see my answers below:

• What is desired behavior when it comes cargo features such as align in sgx_libc. Do you want to trasnfer them to bazel BUILD files as well?

I think behavior like "alignment" can be hard-coded for now. Its behavior depends on Intel SDK and I can't see any possibility to change in linux-sgx environment. Is it an option that we hardcode it now, and (unlikely) make it configurable in future? I'm not familiar with bazel 😂

• What is desired behavior of cfg(not(target_env = "sgx")) from toml files. Cargo features are not fully supported the best withing rules_rust rules_rust#37. Alternative solution exists with configurable build.

target_env = "sgx" means building with Xargo and the [x86_64-unknown-linux-sgx.json](https://github.com/baidu/rust-sgx-sdk/blob/master/xargo/x86_64-unknown-linux-sgx.json#L6. not(target_env = "sgx") means building with Cargo, resulting in #![no_std] mode on every crate. Xargo would build a sysroot using Xargo.toml for the first stage and store them in ~/.xargo by default (including libcore built from upstream libcore source, and sgx_* crates from this repo, and std as a renamed sgx_tstd). Then Xargo build the enclave as normal but load sgx_* crates from sysroot. Cargo uses the default libcore shipped in the official toolchain and builds everything else on each cargo build.

I can see that some projects are using Xargo but most people keep using Cargo because cargo seems easier to understand. Xargo seems can be replaced by the the std-awared cargo in the future.

[ghost]

Hey @dingelish thanks for the fast reply. Your answers are illuminating! Didn't know that xargo even exists. Learned something new today. Both xargo and std-awared cargo looks pretty amazing!

Not sure about their support in bazel in the near future haha. Work on rules_rust is active and I will try to contribute there as well, but for bazel internals I am still a newbie.

Anyways let me see if I have understood that correctly:

• I will always enable the cargo features such as align . Hard coding is definitely possible. :)
• I will assume that project is build with cargo thus not(target_env = "sgx") is true

I will make the changes to the sgx_libc and recommit for review

[ghost]

Oh and final thing I forgot to mention... I am assuming bazel 0.28.1 version for now as specified in .bazelversion file. Older versions should work down to cca 0.26, but they cannot be guaranteed.

I also suggest that you use bazelisk tool to run bazel. It will always resolve to the feature defined in the .bazelversion file

If you have any further questions about bazel, I will be happy to answer :)

[tomtau]

@Sythanis pretty good stuff!

BTW, here are a few extra thoughts (not for this PR, but some future PRs):
Google has a few Intel SGX SDK-related Bazel rules in their asylo repo:
https://github.com/google/asylo/blob/master/asylo/bazel/sgx_deps.bzl
https://github.com/google/asylo/tree/master/asylo/distrib/sgx_x86_64

I think this could later be used to bootstrap the environment. My future ideal project workflow with Rust SGX SDK and Bazel looks something like this (on a fresh machine):

1. I clone a project (the project has just its own source code in the repository rather than duplicating Rust SGX SDK code)
2. The only dependencies to (manually) install are Bazel + perhaps Intel SGX driver / kernel module.
3. I run bazel build

The Google Bazel rules can help with installing / building the Intel SGX SDK environment that currently one had to install manually or use a Docker image.
I'm not sure if they have it, but one other thing would be to capture some of the Intel SGX SDK build tools (once they are built) in Bazel rules (edger8r, sgx_sign...).
So when starting a new Rust SGX SDK project, I won't need to copy-paste and tweak Makefiles like https://github.com/baidu/rust-sgx-sdk/blob/master/samplecode/hello-rust/Makefile
Instead, I could simply do something like load("@baidu//:rust-sgx-sdk", ....)and have all the functionality related to building Rust SGX SDK projects ready

[ghost]

Hey @tomtau wow will check those rules tomorrow. I think the workflow you have described is definitely possible. I would need to get up to speed in sgx but I could write some rules to replace makefiles.

For now I have pushed hard coded align cargo feature in sgx_libc. @dingelish @tomtau do you feel better merging this into a longer living bazel branch or straight into master?

Anyways, things are good from my side for now.

In the next PR I would need some help to setup sgx environment to try to test some features and see that everything is working as it should. But I have the weekend for this ;) .

[dingelish]

@tomtau I prefer master. how do you think?

[tomtau]

master is fine, it doesn't interfere with anything at the moment

[ghost]

Alright then, should I squash the commits them in preparation for the merge?

[dingelish]

yes please!

[ghost]

All squashed and commit message has been unified. Hope it describes well enough what was done. Ready to merge from my side