Tn/unsafe handling #1114
Tn/unsafe handling #1114
Conversation
|
@murerfel Maybe you also want to have a look |
| if p_platform_blob.is_null() || p_update_info.is_null() { | ||
| return sgx_status_t::SGX_ERROR_INVALID_PARAMETER | ||
| } |
There was a problem hiding this comment.
In general, I think I like your proposal, and agree with it.
The only thing that I wonder; the teaclave examples don't check for null pointers in their sample code either, so I wonder if the overall construct with rust FFI and .edl files gives guarantees such that these function args can't be null?
There was a problem hiding this comment.
Hmm, yeah you are right regarding the teaclave example, but I don't see how they could guarantee that the arguments are never null. It can be a valid use-case to pass a null into a function so it cannot be enforced in general.
There was a problem hiding this comment.
I could imagine that the edger8r does enforce it. As the .edl files are strongly typed, the edger8r might enforce that a pointer to something does, in fact, always point to a valid object of said type. I am not sure about this though, but I found this very interesting reference to the edger8r.
There was a problem hiding this comment.
There is only one place in the code samples where they check for null pointer on the v2.0.0-preview branch:
https://github.com/apache/incubator-teaclave-sgx-sdk/blob/v2.0.0-preview/samplecode/httpreq/enclave/src/lib.rs#L33:L38
(There are some checks on the current master branch as well)
I did not find anything related to explicit null checking in https://download.01.org/intel-sgx/latest/linux-latest/docs/Intel_SGX_Developer_Reference_Linux_2.18_Open_Source.pdf
I think it is worth to asking it on openenclave though just to have a confirmation.
This PR is more a proposal on how to improve our handling of
unsafecode.unsafedepending on if the function has unsafe code. Also see Consistent marking of functions asunsafe#982get_update_info.rs. Currently both methodsocall_get_update_infoandget_update_infohave unsafe code. I refactored it such that one function is safe and the other unsafe. The safe one also has a more rust like interface.nullptrchecks inget_update_info.rs. See Check safety offrom_raw_partsandfrom_raw_parts_mut#1113No longer treat the body of an unsafe fn as being an unsafe block.