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

Update annotations of sgx_sealed_data_t and sgx_aes_gcm_data_t (#639) #640

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions common/inc/sgx_tseal.h
Original file line number Diff line number Diff line change
Expand Up @@ -47,18 +47,18 @@

typedef struct _aes_gcm_data_t
{
uint32_t payload_size; /* 0: Size of the payload which includes both the encrypted data and the optional additional MAC text */
uint8_t reserved[12]; /* 4: Reserved bits */
uint32_t payload_size; /* 0: Size of the payload which includes the encrypted data: payload[] */
Copy link
Contributor

Choose a reason for hiding this comment

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

The payload[] includes encrypted data and the optional additional authenticated data if users seal data with a plaintext (for example, sgx_seal_data() is called with p_additional_MACtext not NULL). So I suppose the previous annotation is correct.

uint8_t reserved[SGX_SEAL_IV_SIZE]; /* 4: Reserved bits used as iv */
Copy link
Contributor

Choose a reason for hiding this comment

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

Although the value of the used IV in tseal library is the same as this reserved bits array, but they are indeed different buffers. This reserved array is actually to make the structure 16byte aligned.

Copy link
Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

OK. Thanks for the explanation. This usage may not be aligned with the initial design of the structure. But the functionality is correct.

uint8_t payload_tag[SGX_SEAL_TAG_SIZE]; /* 16: AES-GMAC of the plain text, payload, and the sizes */
uint8_t payload[]; /* 32: The payload data which includes the encrypted data followed by the optional additional MAC text */
uint8_t payload[]; /* 32: The payload data which includes the encrypted data followed by payload_tag */
} sgx_aes_gcm_data_t;

typedef struct _sealed_data_t
{
sgx_key_request_t key_request; /* 00: The key request used to obtain the sealing key */
uint32_t plain_text_offset; /* 64: Offset within aes_data.playload to the start of the optional additional MAC text */
uint8_t reserved[12]; /* 68: Reserved bits */
sgx_aes_gcm_data_t aes_data; /* 80: Data structure holding the AES/GCM related data */
uint32_t plain_text_offset; /* 512: Offset within aes_data.playload to the start of the optional additional MAC text */
uint8_t reserved[12]; /* 516: Reserved bits */
sgx_aes_gcm_data_t aes_data; /* 528: Data structure holding the AES/GCM related data */
} sgx_sealed_data_t;

#ifdef __cplusplus
Expand Down