There is a thread on the rust users forum which discusses this topic.
All examples I've seen online to link statically with rust rely on the musl libc.

We need one.

Make sure all fields of Signature struct are the same as those produced by selftests in https://github.com/jsakkine-intel/linux-sgx/tree/master/tools/testing/selftests/x86/sgx.

Specifically, dump bytes and retrieve: rsa key, sigstruct file, bytes submitted to hasher. make in selftest directory above will generate these structures.

Goal: produce same SIGSTRUCT as selftest.

Write tests for SGX_IOC_ENCLAVE_ADD_PAGES and SGX_IOC_ENCLAVE_SET_ATTRIBUTE, as well as SGX_IOC_ENCLAVE_CREATE. These are specified in sgx-sys/src/ioctls/sgx.rs.

There is already one test for SGX_IOC_ENCLAVE_CREATE in sgx-sys/src/lib.rs.

All of these tests should be labeled with #[cfg_attr(not(has_sgx), ignore)] so that they do not run if SGX is not present on the system.

Commit messages can link to issues. For example: https://help.github.com/en/github/managing-your-work-on-github/closing-issues-using-keywords

When a pull request links to an issue, it should probably inherit the labels from the issue.

This should call every WASI API we intend to support. Depends on #73.

There is already one test for this in sgx-sys/src/lib.rs.

Any tests should be labeled with #[cfg_attr(not(has_sgx), ignore)] so that they do not run if SGX is not present on the system.

https://icmconference.org/

Currently, we run a few tests on Enarx's other repos via Travis. With development in the namesake Enarx repo picking up, we'd like those tests here too.

Depends on #83 and #84.

Our current design has done all that we have in 2019 to improve the security unless for one possible thing I propose to improve: that is to decentralize the execution and attestation from one node to a consensus between a group of nodes.

We can add a few steps as the following

• Connect all Enarx nodes into a huge p2p network (swarm)

• When a client deploys a wasm task, all nodes need to run a VRF to decide which node will actually run this task. At this moment, only the node who wins this VRF competition knows he is the winner. The client, the host, and other nodes do not know what a node is currently running which task until the task is completed we will discuss later time.

• The host or the attestation code in the same node cannot claim itself a “trusted” TEE. The attestation is done by other VRF selected nodes. No one can predict or decide who is validator for who. If necessary, those VRF selected validators can run a BFT consensus to decide the truthfulness of the node who is under attestation.

• Executors and validators will be paid for doing an honest job after the execution is completed. That means who has run which task will only be disclosed after the task is completed. (So no security information exists any more at this moment)

• A credit score system can be used to incentivize good behavior. As well as slashing can be used for punishment.

By doing so we can get these benefits:

• No matter a task is a high attacking value or not, no one knows which node it is executing on. This reduces the profit attraction to hackers. A hacker has to hack more nodes to get enough profit to cover his costs.

• If one kind of under layer TEE has any secure issue, we can easily adjust the VRF function factor in real-time, so new tasks will be automatically routed away from those unsecured nodes until the problem fixed.

• Unless hackers can comprise a large number of nodes at the same time, one comprised node can hardly pass the attestation of other healthy nodes. So it will be easily quarantine.
  Bitcoin-like token incentives can be used to fast boost the ecosystem.

• Red hat doesn't need to run an attestation service. No single point of failure, no centralization.

Sorry, I did not find any designated place to propose this kind of improvement idea, so I post here as an issue. I hope I did not break any contribution rules here for discussion. If I did, I am sorry.

BTW, all technologies I mentioned here are mature and widely used in blockchain. If this idea can be adopted as an improvement proposal, I can contribute to this child project as this is what I was researching recently.

This depends on #81.

Once we can run a full static binary inside a VM (#77), we need to make our WASM runtime (#74) work inside the VM. This task is complete once the full tests work (#75).

Opening this one to track the following goal:
Automatically have any issue tagged label:conference added to the "Considering" column of the
Conferences board (or project, in Github speak).

Had a look at available actions on the marketplace and found two (Add new issue to column, Automate projects) that might help, but I'm reticent to set them up on my own. Maybe @mbestavros we can have a look at this together!

Mark and Lily are to present on Enarx at RHRD in San Francisco on April 26, 2020. The abstract was submitted to Gagan Kumar Nov. 15 2019.

Dates

Event: April 26, 2020

Location

San Francisco

CFP

N/A

We need some decent issue templates. This is related, in part, to project infrastructure automation.

GitHub allows us to set a "social preview" image. Preferred size is 1280x640px.

Once we are testing (#75) our static (#74) runtime, we need to inventory the Linux syscalls that are issued during this test. These will be the target syscalls for SGX and SEV to implement.

Make sure the bytes of the MRENCLAVE field in the SIGSTRUCT are the same as those produced by selftests in https://github.com/jsakkine-intel/linux-sgx/tree/master/tools/testing/selftests/x86/sgx.

Modify the selftests to dump the bytes for comparison.

We need a bot that runs on GitHub Action hooks to ensure that issues and pull requests have their metadata normalized. In particular, the bot needs to place issues/PRs into their respective projects when a tag is applied. Likewise, when the tag is removed, they should be removed from the respective projects.

We'd like Enarx to maintain a clean commit history. We have soft guidelines around logical commits and commit etiquette, but we can directly test incoming PRs to ensure they do not have merge commits. We should implement such a test in Travis.

Dates

Deadline: December 11th, 2019, 17:00 PST

Location

February 10, 2020
Google, 1625 Plymouth St
Mountain View, CA 94043

CFP

CfP form: https://docs.google.com/forms/d/e/1FAIpQLSdY82WK8eGSDro2qLwU63wbf8bTQhcSmSmmofY8QuQceS9Tag/viewform

Website

https://webassembly-summit.org/

Once we have a full static binary running inside a VM (#77), we need the ability to measure all the bits we put inside the VM and attest them to the client. This will use the SEV module (#71).

This crate will include a hasher struct that:

• Takes in Secs and outputs a hash based on SGX documentation for EADD and EEXTEND
• Generates an RSA pubkey from OpenSSL and extracts relevant data for sgx-types::sig::Signature:
  • modulus
  • exponent
  • q1
  • q2
• Goes through the same steps as the Builder trait but without actually creating the enclave

Dates

• CFP closes: 23:59 PST, Monday 3 February 2020
• CFP results: ?
• Event: 20-21 April 2020

Location
Los Angeles, CA

CFP
https://events.linuxfoundation.org/open-networking-edge-summit-north-america/program/cfp

Depends on #82.

The runtime merged in #73 needs to be converted to be a static binary.

Dates

Deadline: 10 December 2019
Event: 15–18 June 2020

Location

Santa Clara

CFP

https://conferences.oreilly.com/infrastructure-ops/io-ca/public/cfp/777

The existing WASM code needs to be merged into enarx/enarx. This is done when we have a crate that builds a binary that can run a toy WASM/WASI binary.

There's also Embedded Linux Conference at the same time/place, but it seems less obvious a conference for Enarx.

Dates

• CFP opens: 17 December 2019
• CFP closes: 23:59pm PST on Sunday 16 February 2020
• CFP results: Monday 23 March 2020
• Slides Due Date: Monday 15 June 2020
• Event: 22-24 June 2020

Location
W Marriott Austin, Texas, USA

CFP
https://events.linuxfoundation.org/open-source-summit-north-america/program/cfp/

Once we can run a toy static binary in a VM (#72), we need to support a full musl-libc static binary.

The Enarx project plans on developing a robust project infrastructure, with deep automation enabled by Github Actions.

As this plan is being finalized, and before we implement Actions, we should experiment with Github's built in project board automation and make whatever rules we do decide to implement consistent across all our projects. It is very surface-level, but it can potentially make some future steps easier.

This is done when we can load and run a toy static Linux ELF binary inside a VM that does nothing more than call SYS_exit with the code in the enarx/enarx repo.

Dates

• CFP closes: 23:59pm GMT+2 on Sunday 7 June 2020
• CFP results: ?
• Event: 29-30 September 2020

Location
Antwerpen, Belgium

CFP
https://events.linuxfoundation.org/open-networking-edge-summit-europe/program/cfp

• Add comments for each field of each SGX type
• Add documentation for all pub fns
• Add documentation for each SGX type

Related to #58.

• Reusable Components

  • Persistent storage
    • Design and Implement Block Encryption
    • Design and Implement Block Authentication
    • Choose and Implement Filesystem
  • SEV Attestation
    • Port sev repo to use rust-vmm kvm repo
    • Port sevctl to the new sev API
    • Expand library for SEV-ES
    • Expand library for SEV-SNP
  • OpenSSL (replace mbedtls)
    • Solve ld load problem
    • Solve CPUID problem
    • Solve network IO problem
  • Enarx VMM (name: TBD)
    • KVM Library (ketuvim => rust-vmm)
      • Merge x86_64_types improvements to x86_64 repo
      • Extract ketuvim core structures to rust-vmm kvm repo using x86_64
      • Merge rust-vmm kvm-ioctl repo to kvm repo
      • Transfer sev repo ownership to rust-vmm
    • Enarx VMM (name: TBD)
      • Design Host/Guest communication channel for syscall proxy (virtio-syscall?)
      • Document VMM
      • Implement VMM
    • Enarx μKernel (name: TBD)
      • Design μKernel
      • Document μKernel
      • Implement μKernel
    • Enarx WASM Runtime
      • Cranelift
        • architectural control
      • Wasmtime
        • architectural control
        • implement modularization
        • migrate unneded functionality to unused modules
      • WASI
        • Failure stubs for unsupported APIs
        • Implement Arguments
        • Implement Clocks
        • Implement Secure Sockets
        • Implement Filesystem

• Enarx Host Agent

  • Protocol
    • Choose transport
    • Choose serialization
    • Design protocol
    • Design instance state format
    • library/daemon
    • CLI
    • Openshift integration
    • other OS support?

• Enarx Tenant CLI

  • Validate input before sending it to host

• Enarx Keep Scheduler

  • Node architecture discovery
  • Security-level negotiation
  • Design Keep input and output format

• Architectures

  • SGX

    • Validate an SGX remote attestation
    • Establish encrypted channel to an SGX enclave
    • Embed Wasmtime in an SGX enclave
    • Deliver WASM code to an SGX enclave across an encrypted channel
    • Evaluate stripped-down graphene?

  • SEV # please double check if content below here is correct. SEV got lost temporarily

    • Implement SEV attestation in our VMM
    • Implement SEV-ES attestation in our VMM
    • Implement SEV-SNP attestation in our VMM
    • Implement SEV support in our μKernel
    • Implement SEV-ES support in our μKernel
    • Implement SEV-SNP support in our μKernel

  • PEF

    • investigate once available

  • Others

    • track, investigate

  • Standardization Work

    • Evolve the WASI standard to better support our use case
      • Networking/secure sockets APIs
      • Low-level cryptography APIs
      • Secure clocks APIs
      • Secure random numbers APIs

• Testing

• Documentation

• Community

• Uncategorized

  • Key management design
    • control plane
    • data plane
  • Key sharing
  • GPU support - per platform, as available
  • FPGA support - per platform, as available
  • crypto hardware accelerator support
  • dev. tool integration (WASM + WASI): Eclipse, Eclipse Che...
  • Example applications/use cases (Java secure key store)

Currently we have three test tasks: stable, beta, and nightly. As part of each of these, we install and run cargo-audit. However, this takes a lot of time and is duplicated unnecessarily. We should add a fourth test task: audit that runs cargo-audit in parallel to the other test tasks.

We need an sgx-run crate that can load a toy static binary that does nothing more than issue SYS_exit into SGX and run it.

We currently have a number of comments (for example: https://github.com/enarx/enarx/blob/master/sgx-hasher/src/lib.rs#L40) that probably should be documentation. Someone should go through all the files (a grep is fine) and find all the comments that should be turned into proper documentation.

For information on documentation:
https://doc.rust-lang.org/stable/rust-by-example/meta/doc.html

Related to #28.

https://www.ibm.com/events/think/

Get a list of the files modified. Do a regular expression search for SGX. If found, label it with technology/sgx.

Or likewise for other projects.

Depends on #82 and #74. This is complete when the tests pass (#75).

Depends on #78 and #79.

All tests should be labeled with #[cfg_attr(not(has_sgx), ignore)] so that they do not run if SGX is not present on the system.

The bot should automatically add to the "WASM on SGX" project tickets that do not have "help wanted" (i.e. backlog) and either "technology/wasm" or "technology/sgx".

The hash is a SHA256 of an enclave binary.

All tests should be labeled with #[cfg_attr(not(has_sgx), ignore)] so that they do not run if SGX is not present on the system.

https://www.rsaconference.com/

Dates

Event: 24 – 28 February 2020

Location

Moscone Center, San Francisco

CFP

…

We currently run a bunch of sanity tests in TravisCI (things like checking code formatting, etc.). I'd like these converted to git pre-commit hooks.

We can move these to the hooks/ directory and then use git config core.hooksPath hooks to ensure they are updated with the repo. Once this is done, we can configure TravisCI to run the pre-commit hooks instead.

This ensures that you hit the failures before submitting the PR.

We need to adopt a Code of Conduct. This needs to be coordinated with our CCC membership.