-remove goto
-remove multiple return
-Modify assignment operator in boolean expression
-Modify/fix code style violations
-fix attempt to change parameters passed by value
-fix value need U suffix
-fix use of mixed arithmetic
-fix assigment in expression
-other fix
Tracked-On: #861
Signed-off-by: Chen Gang G <gang.g.chen@intel.com>
Reviewed-by: Bing Zhu <bing.zhu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Remove dynamic memory allocation in crypto lib, use array to
replace them.
Tracked-On: #1900
Reviewed-by: Bing Zhu <bing.zhu@intel.com>
Signed-off-by: Chen Gang G <gang.g.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
CSE FW uses an AEK (Attestation keybox Encryption Key) to encrypt the keybox
with AES-256-GCM algorithm before sending it to Android/Trusty. This key is
derived from the latest platform Seed by CSE FW with KDF (key derivation function)
HMAC-SHA256. After Trusty retrieves this encrypted keybox over HECI/MEI driver,
Trusty needs the same AEKkey to decrypt it. Hence, before Trusty launches,
Hypervisor derives the same AEK key from Platform Seed with the same algorithm
and the same derivation parameters, then sends this AEK along with Trusty vSeed
to Trusty world memory.
Since Platform Seed is only visible to Hypervisor and it must not be
sent to any guest VM, only Hypervisor can derive this AEK from this
Platform Seed, just like previous per-Trusty virtual Seed derivation.
Please note that Android Attestation Keybox is shared in a single hardware
platform, so all the Trusty instance/world can get the same AEK for
decryption even if there are multiple Android User OS/VMs running
on top of Hypervisor.
v1 --> v2:
Add detailed description why we need the patch to derive an extra key
v2 --> v3:
Convert API descriptions to Doxygen
Tracked-On: #1812
Reviewed-by: Bing Zhu <bing.zhu@intel.com>
Reviewed-by: Kai Wang <kai.z.wang@intel.com>
Signed-off-by: Chen Gang G <gang.g.chen@intel.com>
Acked-by: Bing Zhu <bing.zhu@intel.com>
Chen Gang G