-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tn/unsafe handling #1114
base: master
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
unsafe
code.unsafe
depending on if the function has unsafe code. Also see Consistent marking of functions asunsafe
#982get_update_info.rs
. Currently both methodsocall_get_update_info
andget_update_info
have 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.nullptr
checks inget_update_info.rs
. See Check safety offrom_raw_parts
andfrom_raw_parts_mut
#1113No longer treat the body of an unsafe fn as being an unsafe block.