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 2021/03/17 05:00:34 UTC

[GitHub] [incubator-teaclave-sgx-sdk] xu-cheng opened a new issue #326: Incompatible with hashbrown 0.11

xu-cheng opened a new issue #326:
URL: https://github.com/apache/incubator-teaclave-sgx-sdk/issues/326


   I write enclave code strictly in `no_std` and use `hashbrown` as one of the transitive dependencies. However, it fails to compile after upgrading `hashbrown` to 0.11. It fails at linker step with the following messages:
   
   <details>
   <pre>
   /usr/local/bin/ld: target/debug/libenclave.a(getrandom-1afbd7620d110fa6.getrandom.3csxlzm7-cgu.0.rcgu.o): in function `getrandom::error::os_err':
   /home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.2/src/error.rs:96: undefined reference to `__xpg_strerror_r'
   /usr/local/bin/ld: target/debug/libenclave.a(getrandom-1afbd7620d110fa6.getrandom.3csxlzm7-cgu.0.rcgu.o): in function `getrandom::util_libc::open_readonly':
   /home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.2/src/util_libc.rs:110: undefined reference to `open64'
   /usr/local/bin/ld: target/debug/libenclave.a(getrandom-1afbd7620d110fa6.getrandom.3csxlzm7-cgu.0.rcgu.o): in function `getrandom::use_file::getrandom_inner::{{closure}}':
   /home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.2/src/use_file.rs:36: undefined reference to `read'
   /usr/local/bin/ld: target/debug/libenclave.a(getrandom-1afbd7620d110fa6.getrandom.3csxlzm7-cgu.0.rcgu.o): in function `getrandom::use_file::wait_until_rng_ready':
   /home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.2/src/use_file.rs:104: undefined reference to `poll'
   /usr/local/bin/ld: target/debug/libenclave.a(getrandom-1afbd7620d110fa6.getrandom.3csxlzm7-cgu.0.rcgu.o): in function `getrandom::use_file::wait_until_rng_ready::{{closure}}':
   /home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.2/src/use_file.rs:99: undefined reference to `close'
   /usr/local/bin/ld: target/debug/libenclave.a(getrandom-1afbd7620d110fa6.getrandom.3csxlzm7-cgu.0.rcgu.o): in function `getrandom::use_file::Mutex::lock':
   /home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.2/src/use_file.rs:124: undefined reference to `pthread_mutex_lock'
   /usr/local/bin/ld: target/debug/libenclave.a(getrandom-1afbd7620d110fa6.getrandom.3csxlzm7-cgu.0.rcgu.o): in function `getrandom::use_file::Mutex::unlock':
   /home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.2/src/use_file.rs:128: undefined reference to `pthread_mutex_unlock'
   /usr/local/bin/ld: target/debug/libenclave.a(getrandom-1afbd7620d110fa6.getrandom.3csxlzm7-cgu.0.rcgu.o): in function `getrandom::imp::getrandom':
   /home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.2/src/linux_android.rs:45: undefined reference to `syscall'
   collect2: error: ld returned 1 exit status
   </pre>
   </details>
   
   The pitfall comes from that `hashbrown 0.11` depends on `getrandom 0.2`. And `getrandom` despite being a `no_std` library will always use Linux syscall if the target triple is `*-linux-*`. See [its document](https://docs.rs/getrandom/0.2.2/getrandom/) for more detail.
   
   Ultimately, I think this just shows a fundamental issue that we tell rust to build enclave code in `x86_64-unknown-linux-gnu` target when in reality we are actually using something like `x86_64-unknown-none-eabi`. As such, `getrandom` got the wrong impression that we are on Linux and it is safe to use Linux syscall.
   
   Of course, we can fork and patch `getrandom`. But IMHO, patching crates for sgx are red herring in terms of maintenance, stability, or even security (as bug fixes in upstream may not be applied in time). Not mentioning it splits the eco systems. I also believe it is infeasible to patch every crates whenever we encounter similar issues. So my question is whether there is a better systemic approach to address the underlying issue.
   
   Thanks.


----------------------------------------------------------------
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-sgx-sdk] xu-cheng commented on issue #326: Incompatible with hashbrown 0.11

Posted by GitBox <gi...@apache.org>.

xu-cheng commented on issue #326:
URL: https://github.com/apache/incubator-teaclave-sgx-sdk/issues/326#issuecomment-800812736


   > and i believe hashbrown is a very very special case: std has a built-in hashbrown (v0.9.0 as of today)
   
   FYI, `hashbrown` is commonly used as drop-in for essentially `alloc::collections::hash_map` in `no_std` crates. This use case will likely exist until std hashmap is moved to alloc in the future.


----------------------------------------------------------------
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-sgx-sdk] dingelish edited a comment on issue #326: Incompatible with hashbrown 0.11

Posted by GitBox <gi...@apache.org>.

dingelish edited a comment on issue #326:
URL: https://github.com/apache/incubator-teaclave-sgx-sdk/issues/326#issuecomment-800799978

Hi @xu-cheng , thanks for your report.

I totally agree on every word you mentioned above.

maintain a bunch of forked crates can help us with (1) stability and (2) compatibility and (3) features, and something suffers a lot (1) freshness, (2) security. but overall I slightly tend to maintain an isolated ecosystem. and in production, i believe most products vendor their dependencies and then maintain their vendored sources.

on the getrandom issue, i'd say the only doable way is to maintain a fork of getrandom. as you already know, quality of random number is **critical** to Intel SGX enclaves, while it may not mean much to many of other platforms. getrandom lays on the bottom of the entire crate dependency graph and i'd strongly recommend user to maintain their own fork.

and i believe hashbrown is a very very special case: std has a built-in hashbrown (v0.9.0 as of today). and one principle you may know is "we should not have 2 different versions of the same library in the same dependency tree". so I'd say if you need hashbrown, first try if you can use the libstd's built-in one.

----------------------------------------------------------------
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-sgx-sdk] dingelish commented on issue #326: Incompatible with hashbrown 0.11

Posted by GitBox <gi...@apache.org>.

dingelish commented on issue #326:
URL: https://github.com/apache/incubator-teaclave-sgx-sdk/issues/326#issuecomment-800799978

Hi @xu-cheng , thanks for your report.

I totally agree on every word you mentioned above.

maintain a bunch of forked crates can help us with (1) stability and (2) compatibility and (3) features, and something suffers a lot (1) freshness, (2) security. but overall I slightly intended to maintain an isolated ecosystem. and in production, i believe most products vendor their dependencies and then maintain their vendored sources.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org