search

intel / linux-sgx

Intel SGX for Linux*
https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/linux-overview.html
Other
1.33k stars 544 forks source link

sign_tool never sets debug attribute bit #341

Open deeglaze opened 6 years ago

deeglaze commented 6 years ago

The XML tag DisableDebug=1 ensures that the debug bit is both 0 and contributes to the signer key derivation. If DisableDebug=0, then the debug bit is still 0 (line manage_metadata.cpp:268), but it's not a contributor to the signer key derivation. I would have thought that DisableDebug=0 would in fact set the debug bit in ATTRIBUTES.

deeglaze commented 6 years ago

I'm guessing now that the debug bit is meant to be chosen at run-time by an argument to create_enclave, which will recreate a SIGSTRUCT with the debug bit set or not.

deeglaze commented 6 years ago

Reopening because I'm still confused. Sorry. The bits that I sign with a debug key always have the debug flag set to 0 since sign_tool never sets that bit. So when create_enclave sets this flag to 1, why is the signature still accepted? I'd be surprised if the way the SDK makes the debug flag a run-time option is by re-signing the sigstruct and replacing all the public key material and signature bits in the sigstruct. I don't see any code that does that though.

andyzyb commented 5 years ago

There is a corresponding mask bit in AttributeMask to affect debug bit.

Mask bit: 1 => the debug bit must be checked and should match what is set during signing process Mask bit: 0 => the debug bit is not checked

There is a setting in Enclave configuration file. If it is set to 1, then the Enclave can only be launched in production mode, means it cannot be debugged. If it is not set or set to 0, then the Enclave can be launched in production mode or debug bit, depending on the run-time flag you pass in sgx_create_enclave.

andyzyb commented 5 years ago

Missed the name of setting in Enclave configuration file in previous post.

"There is a setting (DisableDebug) in Enclave configuration file ..."

deeglaze commented 5 years ago

When I verify a signature with RSA_verify against sigstruct[0:128]++sigstruct[900:1028], the attribute bit for debug == 0 or debug == 1 is checked regardless of ATTRIBUTEMASK. When the signature is verified in hardware, is it not checking these same 256 bytes? Is the signature not verified in hardware at all if the debug bit is set? I'm not clear on the details of what actually leads to a debug launch in hardware, as I read through the enclave_creator_hw_com.cpp and launch_enclave.cpp implementations.

bodzhang commented 5 years ago

In EINIT instruction, the HW checks that SECS.ATTRIBUTES & SIGSTRUCT.ATTRIBUTEMASK = SIGSTRUCT.ATTRIBUTES & SIGSTRUCT.ATTRIBUTEMASK.

SECS.ATTRIBUTES.DEBUG bit is set by the SW that handles enclave launch. If SECS.ATTRIBUTES.DEBUG=1, the enclave is launched in Enclave Debug mode (Debugger can use EDBGRD/EDBGWR instructions to access enclave memory). SIGSTRUCT is verified even when the enclave is launched in Enclave Debug mode. and the SECS.ATTRIBUTES, including the DEBUG bit, is part of the SGX Remote attestation. So the remote attestation verify can tell whether the Enclave is launched in Enclave Debug mode (should not trust the enclave launched in Enclave Debug mode to protect secret).

During enclave development, the developer can specify whether the Enclave is allowed to be launched in Enclave Debug mode, by setting the SIGSTRUCT.ATTRIBUTES and SIGSTRUCT.ATTRIBUTEMASK. By default, the Intel SGX SDK signing tool sets SIGSTRUCT.ATTRIBUTEMASK.DEBUG=0, allowing the enclave launch SW to set SECS.ATTRIBUTES.DEBUG bit freely (1 or 0).

deeglaze commented 5 years ago

Not only does the signing tool set the debug bit to 0 by default, it has no non-default pathway to set it to 1. If it shouldn't, then this issue should be closed. If it should have that option, then there's some implementation work to do.

lzha101 commented 5 years ago

Your concern is we always set SIGSTRUCT.ATTRIBUTE.DEBUG = 0, no matter the tag DisableDebug is 0 or 1, right? I think SIGSTRUCT.ATTRIBUTES indicates the desired enclave attributes. Setting SIGSTRUCT.ATTRIBUTES.DEBUG = 0 means the default/desired loading mode is product mode. But users are allowed to change the loading mode to debug mode by setting debug_flag in sgx_create_enclave API if the enclave is signed with DisableDebug = 0. There is no need to provide an option to sign an enclave that could only be loaded in debug mode.

deeglaze commented 5 years ago

There are workflows that make sense for ensuring an enclave is only launchable in debug mode. For instance, if I build my enclave with some particular debugging definitions enabled that log the contents of secret data structures, I don't want that build to ever be launched in production mode. There is no security value to a production launch, and it prevents mistaken launches of insecure enclaves. I would make my build script such that flag x => debug_launch_only.

andyzyb commented 5 years ago

Unfortunately current SDK doesn't provide such a configuration for debug only.

We originally thought such option doesn't have much value as user can select which mode to run in sgx_create_enclave API when setting DisableDebug to 0.

Also even the same enclave launched with debug and product mode, the key generated inside Enclave will be different, so it won't be mixed for debug and product mode, for example, data sealed with debug mode cannot be unsealed by product mode.