Skip to content
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

Node auth error messages - take 3 #397

Merged
merged 6 commits into from
Jul 15, 2020

Conversation

reuvenpo
Copy link
Contributor

This PR makes errors in node authentication display more useful errors for users that encounter them.
closes #376
To reviewer: The technique shown here to generate nicer error messages can and should be applied to EnclaveError.

@@ -35,6 +35,12 @@ pub enum Error {
#[cfg(feature = "backtraces")]
backtrace: snafu::Backtrace,
},
#[snafu(display("Error calling the enclave: {}", msg))]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't an error calling the enclave specifically. Also if this is going to be printed to the log we can probably just print "{}", msg since it will be an informative error

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also this is the 3rd variant of the name EnclaveErr in the project. Maybe name this something else? (sgx-vm EnclaveErr and EnclaveError in ffi/types)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, so just writing is as "{}", msg is probably alright.
I was debating creating another variant SdkError for cases of sgx_status_t like i did in VmError, for which this message is accurate, and then change the message on this variant to something like "Error returned from the enclave", but i felt that might be excessive.
As for the naming, the name shows up in a lot of contexts, but that's because different contexts use different error types, and all of them needed a new variant for errors that come from the enclave. I agree that the naming duplication isn't great, but for each of those contexts separately i felt like that was the most appropriate name.
In any case, if you mix them up, the compiler will let you know.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So why not call it GoEnclaveErr or something? Duplicate names will cause all sorts of fun when trying to use find and replace, or find in path (not to mention the potential Expected EnclaveErr but got EnclaveErr good times)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not even in Go yet 😅
But we can name it GoCwEnclaveError or something to signal the layer it's in.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

יאללה קניתי

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

/// cbindgen:prefix-with-name
#[repr(C)]
#[derive(Debug, Display, PartialEq, Eq)]
pub enum NodeAuthResult {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think we could add errors for specific isvEnclaveQuoteStatus? Like, return "failed to perform registration. Invalid quote status "KEY_REVOKED" " or something

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm... can you point me to the place in the code where this error originates? I'd probably have to fiddle with 1-3 functions to bubble this specific case out to the context where i instantiate variants of this type.
Note that the way i use this type is really high level, and unrelated to how most of the related code just uses sgx_status_t

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this will be somewhat involved.
I'm not sure I understand what exactly all the structs and enums mean, and the specific error you're referring to happens a couple layers into functions that obfuscate the specific errors that happen. If I change that, I'd need to add a couple of error types, and modify a bunch of other functions that use the same functions that I needed to change in the first place.

@Cashmaney Cashmaney merged commit c0bb36c into develop Jul 15, 2020
@Cashmaney Cashmaney deleted the node-auth-error-messages-3-electric-manatee branch July 17, 2020 11:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants