search

keystone-enclave / keystone-sdk

SDK for Keystone Enclave - ABI/SBI libraries and sample apps
Other
44 stars 22 forks source link

Google Test support in the SDK (Part of #82) #42

Closed ghost closed 5 years ago

ghost commented 5 years ago

Added GoogleTest support in the SDK and wrote basic tests as a framework. Also created a device class to create mock classes later.

In order to run, do the following: 1) build google tests in sdk/tests (make all) 2) run 'make run' to run tests

Requires GoogleTest (run setup_test.sh) 1) Downloads GoogleTest source code via apt-get 2) Builds source code and copies library to /usr/lib

dkohlbre commented 5 years ago

A couple comments: Are the changes to the hash_enclave parameters correct? We updated the encl params ones to be accurate now for the alternative phys addr loading parts. I'm not sure the changes to hash_enclave match those.

I'd like to avoid having binaries checked into the repository if at all possible. Rebuilding the test eapp should be fine to do every time. I understand why there is an eyrie binary, but I'd prefer we build based on the current specified eyrie checkout hash or something like that

ghost commented 5 years ago

A couple comments: Are the changes to the hash_enclave parameters correct? We updated the encl params ones to be accurate now for the alternative phys addr loading parts. I'm not sure the changes to hash_enclave match those.

I'd like to avoid having binaries checked into the repository if at all possible. Rebuilding the test eapp should be fine to do every time. I understand why there is an eyrie binary, but I'd prefer we build based on the current specified eyrie checkout hash or something like that

So the user hashing is done by mallocing a page-aligned chunk of memory. We then substitute this memory from the one allocated via the driver. The hash parameters just collect where the RT "physical" (physical in quotes because the address is from the malloc'd buffer I specified above) and EAPP begins. In order to keep track of that, I define an 'epm_free_list' which keeps track of the next available page in the buffer. The parameters were actually incorrect before. One of the changes was setting the runtime physical address to where the runtime began. In the code currently, we set the runtime_paddr (line 384) after we load the runtime which updates our free list. That means the runtime_paddr is defined at the end of our RT.

For the second point, I agree. I can build the eyrie each time and copy it over. We just need to be careful of the hash changing if we edit the eyrie-rt and/or the stack eapp.

ghost commented 5 years ago

Could you add followings: (1) update README.md to have instructions for testing (2) setup Travis and add tests (3) build the binary from the source as David suggested

The changes have now been implemented. Please review my recent commits.

dayeol commented 5 years ago

will the test fail whenever eyrie changes?

ghost commented 5 years ago

will the test fail whenever eyrie changes?

Yes, in the travis build, I run init.sh.

dayeol commented 5 years ago

init.sh has an option for specifying version. Can you use that flag? --runtume-version