by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 11 05:41

    dingelish on master

    Upgrade toolchain to 2020-09-08 Remove unused profile line Compile on 2020-09-10 and 2 more (compare)

  • Sep 09 05:40

    dingelish on master

    support intel sgx sdk 2.11 and … clean samplecode Fix file attributes and 2 more (compare)

  • Sep 03 22:09

    dingelish on master

    Update Makefile Merge pull request #264 from le… (compare)

  • Aug 31 18:22

    dingelish on master

    fix no return value of u_malloc… Merge pull request #266 from vo… (compare)

  • Aug 26 22:04

    dingelish on oom_handling

    sample oom handling (compare)

  • Aug 24 03:01

    dingelish on mem_footprint

    Statis of memory footprint (compare)

  • Aug 20 22:33

    dingelish on master

    Update .gitignore Merge pull request #263 from le… (compare)

  • Aug 16 20:00

    dingelish on master

    crypto sample: split into 4 fun… Merge pull request #262 from le… (compare)

  • Aug 03 18:25

    dingelish on master

    Fix no-landing-pads error Merge pull request #261 from vo… (compare)

  • Aug 03 18:25

    dingelish on master

    Fix switchless sample code In … Merge pull request #260 from xu… (compare)

  • Jul 22 03:49

    dingelish on master

    add exception vector definition fix typos Merge pull request #259 from vo… (compare)

  • Jul 06 16:56

    dingelish on v1.1.2

    update Makefile update Makefile Merge pull request #256 from le… and 2 more (compare)

  • Jul 06 16:53

    dingelish on master

    Repair "write_vectored "caused … Merge pull request #257 from Zh… (compare)

  • Jul 06 04:27

    dingelish on master

    update Makefile update Makefile Merge pull request #256 from le… (compare)

  • Jun 30 04:01

    dingelish on v1.1.2

    Update Readme.md Merge pull request #248 from le… first dcap tool commit add dca… and 6 more (compare)

  • Jun 30 03:59

    dingelish on master

    Fix consttime_memequal integer … Merge pull request #253 from vo… (compare)

  • Jun 22 06:04

    dingelish on master

    first dcap tool commit add dca… rewrite qpl remove a assertion and 2 more (compare)

  • Jun 22 06:02

    dingelish on dcap-retrieve

    Readme.md (compare)

  • Jun 22 01:58

    dingelish on dcap-retrieve

    remove a assertion (compare)

  • Jun 22 01:55

    dingelish on dcap-retrieve

    rewrite qpl (compare)

Yu Ding
@dingelish
that'll be really awesome!
basmaelgaabouri
@basmaelgaabouri

Hi, I tried creating a new example using the hello-rust sample code, the only difference is my app (untrusted part) has other local rust projects as dependencies, I used the same Makefile in the sample code but I get this error

error: could not find native static library `Enclave_u`, perhaps an -L flag is missing?

any idea what's going on ?

├── app
│   ├── build.rs
│   ├── Cargo.toml
│   ├── src ...
├── enclave
├── depen1
├── depen2
Liwei Guo
@zaxguo
create a lib/ next to enclave/. Last time I recall there seems to be a small bug in Makefile
basmaelgaabouri
@basmaelgaabouri
I already have lib/ and bin/ folders next to app/ enclave/ dep1/ dep2/, also the Makefile seem to work fine for the rest of the examples
Yu Ding
@dingelish
@basmaelgaabouri when we build sample's app, it'll cd app and cargo build there, and libEnclave_u.a is located in app as well. so if you have an exterior workspace, cargo would not search that directory. you may need to add another line in app/build.rs to specify the path of libEnclave_u.a
basmaelgaabouri
@basmaelgaabouri
Thank you, specifying the absolute path instead of the relative path to libEnclave_u.a seem to work
Reuven Podmazo
@reuvenpo
Hey there @dingelish , Is there a way to check how much memory is still available inside the enclave, from inside the enclave?
CC: @assafmo
Yu Ding
@dingelish

Hey there @dingelish , Is there a way to check how much memory is still available inside the enclave, from inside the enclave?

i'm reviewing tlibc's dlmalloc, and tcmalloc provided by intel. my first thought is "can we have the total number of allocatable bytes", and seems the answer may not be useful since the memory is managed by chunks which are organized in a tree. trying to manually analyze the metadata of these chunks and see how far can i get

Yu Ding
@dingelish
@reuvenpo Please look at branch mem_footprint

To make the hello-rust compile, please do

sudo objcopy --globalize-symbol=_gm_ ./libsgx_tstdc.a

over your SGX SDK's libsgx_tstdc.a. This would turns the symbol of memory management metainfo _gm_ into a global symbol. Then we can link against _gm_ and do whatever we want. I demoed the memory footprint field there in hello-rust sample.

Reuven Podmazo
@reuvenpo
Thanks for investigating this @dingelish !
We've been busy with a few tasks over the last days and i haven't had the time to look into the mem_footprint branch yet
I hope to check it out this week
Reuven Podmazo
@reuvenpo
which allocator is used in the enclave by default?
Yu Ding
@dingelish
dlmalloc, located in intel sdk linux-sgx/sdk/tlibc/stdlib/malloc.c
Reuven Podmazo
@reuvenpo
thanks :D
we're trying to figure out a good strategy to handle OOM events
we've tried a few things, the best design so far has been allocating a bunch of small buffers as a "pillow" and then when detecting OOM with std::alloc::set_alloc_error_hook we release all of them, and panic in order to cause an orderly unwind, which we can catch at the enclave boundary
We did this in order to circumvent the default abort behavior when OOM happens because that just crashes the enclave completely
Thing is, we still find edge cases where this strategy, for some reason, causes a double fault...
Do you have any ideas on this?
do you think that the approach you showed earlier this week can be sufficient for this?
Yu Ding
@dingelish
yea i've seen discussions but haven't touch that. how about this: provide me a fork of hello-rust sample which crashes on OOM, and i create a PR to make it OOM/safe. there must be some stealth problem inside the sdk and intel's sdk
Reuven Podmazo
@reuvenpo
You can just write an infinite loop that keeps pushing some large-ish boxed type to a vector (e.g. Box<[u64;16]>)
in any case, that might not cut it. we tried 3-4 different strategies that satisfied one test, only to find another a couple days later that would break. today we have a case where an unrelated change caused one of the OOM-resilience tests to fail
we started with a chunk of 2MiB contiguous memory out of 32 MiB enclave heap (2/32-contiguous), then tried 32/64-contiguous, then tried 32/64 with fragmentation (a vector holding a bunch of smaller 1KiB vectors)
all seemed to work until they didn't
Yu Ding
@dingelish
i don't know if my understanding is correct. please take a look at this commit
apache/incubator-teaclave-sgx-sdk@635f3cb
Yu Ding
@dingelish
i'm not sure if problem is caused by the format string here (or similar cases)
    result.unwrap_or_else(|err| {
        // We can get here only by failing to allocate memory,
        // so there's no real need here to test if oom happened
        error!("Enclave ran out of memory: {:?}", err);
        oom_handler::get_then_clear_oom_happened();
        EnclaveBuffer::default()
    })
Reuven Podmazo
@reuvenpo
The problem happens even if we remove the formatting tbh
but we'll try again
Reuven Podmazo
@reuvenpo
hey there @dingelish :)
So yesterday I finally looked into the two branches you opened.
I also read up a bit about how allocators work in reality, and I realized that because of memory fragmentation, and size/alignment requirements of different allocations it's really hard to use the "available space in bytes" metric in any sort of useful way... Even if you have a lot of free memory, it might be in a lot of very small chunks that are fragmented across memory in a way that the allocator can not coalesce into bigger chunks.
This poses a hard issue because I can't think up a strategy in which we can recover from OOM in a reliable and repeatable way (that is, that we can fail the same way multiple times without crashing the thread).
Our solution for now is going to be putting limits on the different components in our system, and making sure that our memory limit will be somewhere above the sum of those components' maximum possible requirements.
Our hope is that giving the enclave some extra memory above the maximum theoretical memory consumption that we expect, will make it so that even under worst-case fragmentation we still have enough memory available for everything we need.
we have one recursive flow in our system that was also (relatively) very memory-intense, which was the reason we were concerned about OOM in the first place. So instead of leaving the recursion depth open ended, we will set a reasonable recursion limit for it.
Reuven Podmazo
@reuvenpo
- which will stop the recursion before hitting the memory cap.
HeathJay
@heathjay
@dingelish Hello, could u please give me some ideas on trying to port rust crate into sgx world using rust-sgx-sdk if this crate needs some mods/traits which are partially supported mods/traits in sgx_tstd or sgx_libc?
Yu Ding
@dingelish
@heathjay hey there, sorry for the late reply. could i have some clues about what kind of crates you're working on? thanks! it'll be great if the traits are available to me
HeathJay
@heathjay
@dingelish Hey, I was trying to port openssl-sys using rust-sgx. But it seems that some mods/traits, for example std::path::Path and libc::FILE, are not supported there.
Yu Ding
@dingelish
@heathjay std::path::Path at std::path::Path;
sgx_std::path::Path
Yu Ding
@dingelish
and yes, we don't have libc::FILE by design. anyone wants to use untrusted file system needs to implement their own ocalls. if we provide this by default, we cannot guarantee that secrets are never stored on untrusted file system :-(
Sylvain Bellemare
@sbellem
Hi, I am curious to know whether anyone is still working on reproducible enclave builds, such as what is done in the linux-sgx project. I saw this open issue: apache/incubator-teaclave-sgx-sdk#52 ... and wonder if anyone is still working on this. I'd like to help.
Yu Ding
@dingelish
@sbellem it'll be really fantastic if you can help us!
Sylvain Bellemare
@sbellem
Great! Thanks for the quick reply @dingelish !
@dingelish I am in Europe, so it's a bit late now. I'd like to know your thoughts on the current status and direction to take. I will be back online tomorrow!
Yu Ding
@dingelish
@sbellem to be honest, i'm not familiar with bazel. the bazel integration was started long time ago by Sythanis. and in an incident i accidentally closed that WIP PR :-( i think code samples have lower priority while the library crates should be higher. no much thoughts 😂
Sylvain Bellemare
@sbellem

Ah ok, I see. Do you know if it would be "simpler" to build off the linux-sgx project, which is https://github.com/intel/linux-sgx/tree/master/linux/reproducibility (it uses docker + Nix)?

I somehow naively thought that an extra layer would be needed in the Rust SGX SDK, building on top of the linux-sgx approach. I understand that some comments in apache/incubator-teaclave-sgx-sdk#52 perhaps express something like that meanwhile others appear to suggest that the linux-sgx related infratstucture or tooling is not needed. Do you or anyone else has any thoughts on this?

Yu Ding
@dingelish
oh that one. i forget it. i think it's 100% ok if we can use intel's solution
Sylvain Bellemare
@sbellem
Ok I'll look into this!