You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@teaclave.apache.org by GitBox <gi...@apache.org> on 2020/04/23 21:56:36 UTC
[GitHub] [incubator-teaclave] mssun opened a new pull request #273: [docs] Update docs and add rust guideline
mssun opened a new pull request #273:
URL: https://github.com/apache/incubator-teaclave/pull/273
## Description
- Update our threat model
- Add Rust development guideline
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@teaclave.apache.org
For additional commands, e-mail: notifications-help@teaclave.apache.org
[GitHub] [incubator-teaclave] m4sterchain commented on a change in pull request #273: [docs] Update docs and add rust guideline
Posted by GitBox <gi...@apache.org>.
m4sterchain commented on a change in pull request #273:
URL: https://github.com/apache/incubator-teaclave/pull/273#discussion_r414160449
##########
File path: docs/threat-model.md
##########
@@ -25,17 +29,24 @@ from company B, and use the deep learning inference engine provided by company
C. None of these parties need to trust another, yet the computation can commence
with everyone's privacy respected.
-In the settings above, the root of trust converges to Intel and its SGX-enabled
-CPU chips. Before the computation starts, Teaclave is booted as a secure SGX
-enclave on one of these CPUs owned by the cloud service provider. After that,
-each party can **remotely** attest the authenticity of the hardware and the
-integrity of Teaclave platform. Private data are securely provisioned to the
-Teaclave enclave only if the attestation passes. After the provision, no
-privileged software is able to access the memory content owned by the enclave
-from outside.
+In the settings above, the root of trust converges to the enclave manufactures
+(i.e., Intel) and its SGX-enabled CPU chips. Before the computation starts,
+Teaclave is booted as a secure SGX enclave on one of these CPUs owned by the
+cloud service provider. After that, each party can **remotely** attest the
+authenticity of the hardware and the integrity of Teaclave platform through
+attestation service (e.g., Intel Attestation Service). Private data are securely
+provisioned to the Teaclave enclave only if the attestation passes. After the
+provision, no privileged software is able to access the memory content owned by
+the enclave from outside.
The remote attestation functionality implemented by Teaclave is augmented from
-the method described by an Intel [white paper](https://arxiv.org/abs/1801.05863).
-The complicated structure of Teaclave requires additional work for remote
-attestation, which is explained in details via a separate
+the method described by an [white paper](https://arxiv.org/abs/1801.05863). In a
+nutshell, enclaves in Teaclave will establish trusted channel on attested TLS
+for communication. The complicated structure of Teaclave requires additional
+work for remote attestation, which is explained in details via a separate
[documentation](mutual_attestation.md).
+
+Side channels are out of scope for current Teaclave's implementation. While we
+acknowledge that existing enclaves may be vulnerable to various kinds of side
+channel attacks, we will try our best to mitigate existing attacks by adopt
Review comment:
adopting
##########
File path: docs/threat-model.md
##########
@@ -25,17 +29,24 @@ from company B, and use the deep learning inference engine provided by company
C. None of these parties need to trust another, yet the computation can commence
with everyone's privacy respected.
-In the settings above, the root of trust converges to Intel and its SGX-enabled
-CPU chips. Before the computation starts, Teaclave is booted as a secure SGX
-enclave on one of these CPUs owned by the cloud service provider. After that,
-each party can **remotely** attest the authenticity of the hardware and the
-integrity of Teaclave platform. Private data are securely provisioned to the
-Teaclave enclave only if the attestation passes. After the provision, no
-privileged software is able to access the memory content owned by the enclave
-from outside.
+In the settings above, the root of trust converges to the enclave manufactures
+(i.e., Intel) and its SGX-enabled CPU chips. Before the computation starts,
+Teaclave is booted as a secure SGX enclave on one of these CPUs owned by the
+cloud service provider. After that, each party can **remotely** attest the
+authenticity of the hardware and the integrity of Teaclave platform through
+attestation service (e.g., Intel Attestation Service). Private data are securely
+provisioned to the Teaclave enclave only if the attestation passes. After the
+provision, no privileged software is able to access the memory content owned by
+the enclave from outside.
The remote attestation functionality implemented by Teaclave is augmented from
-the method described by an Intel [white paper](https://arxiv.org/abs/1801.05863).
-The complicated structure of Teaclave requires additional work for remote
-attestation, which is explained in details via a separate
+the method described by an [white paper](https://arxiv.org/abs/1801.05863). In a
Review comment:
an -> a
##########
File path: docs/rust-guideline.md
##########
@@ -0,0 +1,51 @@
+# Rust Development Guideline
+
+This doc defines some guidelines for developing Teaclave in Rust.
+
+## Style
+
+We use `rustfmt` and `clippy` to format and lint all Rust code. Mostly, we use
+the default configurations, but there are a couple of custom settings and lint
+exceptions. The exceptions should be defined along with the code. Our CI will
+check the format/lint issues and deny all warnings by default. Simply run `make
+format` to format all code and `make CLP=1` to lint code before submitting a PR.
+If you still have some doubts of the `clippy` error, feel free to point out and
+add an exception.
+
+## Elegant APIs
+
+Elegantly designed functions and APIs will make the project readable and
+user-friendly. Basically, we follow naming conventions and API design patterns
+of Rust standard library. There's no official guideline, but here are several
+articles or docs for reference:
+
+ - [Rust API guidelines](https://rust-lang.github.io/api-guidelines/)
+ - [Rust Design Patterns](https://github.com/rust-unofficial/patterns)
+ - [Elegant Library APIs in Rust](https://deterministic.space/elegant-apis-in-rust.html#what-makes-an-api-elegant)
+
+## Unsafe Rust
+
+Using unsafe Rust is extremely dangerous, and may break Rust's strong
+memory-safety guarantees. Therefore, we want to keep unsafe Rust as minimal as
+possible. Sometime (very rare) using unsafe Rust can significant improve
+performance, the unsafe code should *well documented* and *explain the
+rationales*. For contributors and reviewers, pay attention to the unsafe code
+and carefully check whether the pre-conditions and post-conditions are still
+hold.
+
+## Error Handling
+
+Using `unwrap` or `expect` to get a value from an optional type may introduce
+runtime panic. Therefore, properly using the error handling mechanism provided
+by Rust can make the system robust and clean. In some cases, optional value can
+never be `None` internally, `unwrap` can be used with a comment explaining the
+assumptions and reasons. The same rule also applies to `panic` and similar
+functions which may cause runtime panic.
Review comment:
Can we add some guidelines regarding using `unwrap` for test cases?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@teaclave.apache.org
For additional commands, e-mail: notifications-help@teaclave.apache.org
[GitHub] [incubator-teaclave] mssun commented on pull request #273: [docs] Update docs and add rust guideline
Posted by GitBox <gi...@apache.org>.
mssun commented on pull request #273:
URL: https://github.com/apache/incubator-teaclave/pull/273#issuecomment-618705056
Fixed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@teaclave.apache.org
For additional commands, e-mail: notifications-help@teaclave.apache.org