Update CFG_TEE_CORE_LOG_LEVEL flag in FVP

Fixes OP-TEE/optee_os#148

Signed-off-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Docs: Add platform specific details

Update README.md with information that tells how to build for the
different software and hardware combinations.

Signed-off-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
Cosmetics fixes

Signed-off-by: Pascal Brand <pascal.brand@st.com>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
core/arm32: add traces in case of user TA abort

TA manager and TA mmu layer have specific trace handlers for TA aborts:
- dumping TA info.
- dumping TA mapping info.

Generic helper uuid2str().

Signed-off-by: Pascal Brand <pascal.brand@st.com>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (STM platform)
libtomcrypt: the len parameter of hash.final() is the max size

To be consistent with the behavior of crypto_ops.mac.final(), do not fail if
the length passed to crypto_ops.hash.final() is larger than the hash size.

Also, use TEE_MAX_HASH_SIZE instead of defining another macro (MAX_DIGEST).

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
TEE_DeriveKey(): remove redundant parameter check

paramCount and params are checked by the system service
tee_svc_cryp_derive_key() so they do not need to be checked in libutee.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
merge tee_pager*.c and tee_pager*.h files

* Merges tee_pager_unpg.c and tee_pager.c into tee_pager.c
* Merges tee_pager_unpg.h and tee_pager.h into tee_pager.h
* Removes some legacy dummy macros
* Replaces some while(1) with panic()

Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
arm32: add thread_init_per_cpu()

Adds a thread_init_per_cpu() function that should be called instead of
thread_init_handlers() by the secondary CPUs. The primary CPU should first
call thread_init_handlers() and then thread_init_per_cpu().

Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
arm32: split and enhance core_init_mmu()

* Splits core_init_mmu() into two functions, core_init_mmu_tables() called
  by primary CPU to create the translation tables and core_init_mmu_regs()
  called by each CPU to initialize MMU register settings.
* Adds option to map certain areas in a level 2 translation table instead
  of only level 1 mapping. Allocation of the level 2 translation tables
  is implemented in platform specific code, a weak function is provided
  in case the platform doesn't implement/need the function.
* Adds L2 translation table for STM and Vexpress.

Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (STM platform)
Tested-by: Jens Wiklander <jens.wiklander@linaro.org> (QEMU virt platform)
Add HMAC-based extract-and-expand key derivation function (HKDF)

HKDF (http://tools.ietf.org/html/rfc5869) is a key derivation algorithm.
As per the RFC:

   A key derivation function (KDF) is a basic and essential component of
   cryptographic systems.  Its goal is to take some source of initial
   keying material and derive from it one or more cryptographically
   strong secret keys.
   [...]
   HKDF follows the "extract-then-expand" paradigm, where the KDF
   logically consists of two modules.
   [...]
   The goal of the "extract" stage is to "concentrate" the possibly
   dispersed entropy of the input keying material into a short, but
   cryptographically strong, pseudorandom key.
   [...]
   The second stage "expands" the pseudorandom key to the desired
   length; the number and lengths of the output keys depend on the
   specific cryptographic algorithms for which the keys are needed.

Since HKDF is not covered by the GlobalPlatform Internal API specification
v1.0/v1.1, this commit introduces extensions to the specification.
More specifically: it defines new algorithms, a new object type and new
object attributes. This implementation supports all the usual hash
functions (MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512) and may
produce output keys of length up to 4096 bits (currently limited only by
the maximum size allowed for an object of type TEE_TYPE_GENERIC_SECRET).
Aside from minor updates to object manipulation functions to support
the new data, the function TEE_DeriveKey() is mostly impacted.

The file documentation/extensions/crypto_hkdf.md contains the modifications
to the GP Internal API v1.0 spec in order to support HKDF.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Xiaoqiang Du <xiaoqiang.du@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (STM platform)
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>