Avoid duplication of $(call force,CFG_WITH_VFP,y)

When cryptographic extensions are used, and whatever the platform,
we have to ensure that VFP preservation is enabled too. Therefore it
makes sense

Avoid duplication of $(call force,CFG_WITH_VFP,y)

When cryptographic extensions are used, and whatever the platform,
we have to ensure that VFP preservation is enabled too. Therefore it
makes sense to centralize the tests in core/lib/libtomcrypt/sub.mk
instead of having them in the platform-specific configuration files.

Incidentally, this adds a few missing statements to HiKey and Mediatek.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>

show more ...

core: ltc: enable thread-safety

Enables thread-safety by replacing empty macros for mutex handling with
a real implementation.

Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by:

core: ltc: enable thread-safety

Enables thread-safety by replacing empty macros for mutex handling with
a real implementation.

Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>

show more ...

core: ltc: add lock for memory pool

Adds a recursive lock for the memory pool, allowing only one thread at a
time to use the memory pool. This makes a predictable or consistent
worst case for memory

core: ltc: add lock for memory pool

Adds a recursive lock for the memory pool, allowing only one thread at a
time to use the memory pool. This makes a predictable or consistent
worst case for memory pool utilization. It also allows for a controlled
way of releasing memory from the pool to the pager when the pool is
unused.

Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>

show more ...

Convert remaining CRLF files

Converts the remaining CRLF files to LF, unix style.

Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
Revie

Convert remaining CRLF files

Converts the remaining CRLF files to LF, unix style.

Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>

show more ...

Introduce free_rsa_public_key() and free_ecc_public_key()

Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Tested-by: Pascal Brand

Introduce free_rsa_public_key() and free_ecc_public_key()

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)
Signed-off-by: Pascal Brand <pascal.brand@st.com>

show more ...

pager: remove pages used by scratch memory

Libtomcrypt is using, because of mpa, some scratch memory
used in intermediate computation. These data are useless
once the acipher computation is complete

pager: remove pages used by scratch memory

Libtomcrypt is using, because of mpa, some scratch memory
used in intermediate computation. These data are useless
once the acipher computation is completed. That means
that these data pages can be unmapped.

On QEMU, compiled with CFG_WITH_PAGER=y, "time xtest 4006" returns:
- Before the patch
real 3m 46.24s
user 0m 0.19s
sys 3m 45.51s
- After the patch
real 1m 29.00s
user 0m 0.17s
sys 1m 28.51s

Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (QEMU with CFG_WITH_PAGER=y)
Signed-off-by: Pascal Brand <pascal.brand@st.com>

show more ...

libtomcrypt: ECC code depends on ASN1 routines

Fixes:
$ make -j8 -s CFG_CRYPTO_{DSA,RSA}=n
[...]libtomcrypt.a(ecc_sign_hash.o): In function `ecc_sign_hash':
[...]ecc_sign_hash.c:166: undefined re

libtomcrypt: ECC code depends on ASN1 routines

Fixes:
$ make -j8 -s CFG_CRYPTO_{DSA,RSA}=n
[...]libtomcrypt.a(ecc_sign_hash.o): In function `ecc_sign_hash':
[...]ecc_sign_hash.c:166: undefined reference to
`der_encode_sequence_multi'

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>

show more ...

libtomcrypt: build prngs folder when CFG_WITH_SOFTWARE_PRNG is set

sub.mk is now consistent with the definition of struct tee_ltc_prng in
tee_ltc_provider.c.

Signed-off-by: Jerome Forissier <jerome

libtomcrypt: build prngs folder when CFG_WITH_SOFTWARE_PRNG is set

sub.mk is now consistent with the definition of struct tee_ltc_prng in
tee_ltc_provider.c.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>

show more ...

GP11 : DSA-SHA224 and DSA-SHA256 algo

Signed-off-by: Cedric Chaumont <cedric.chaumont@st.com>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.o

GP11 : DSA-SHA224 and DSA-SHA256 algo

Signed-off-by: Cedric Chaumont <cedric.chaumont@st.com>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Tested-by: Cedric Chaumont <cedric.chaumont@linaro.org> (STM boards)
Tested-by: Cedric Chaumont <cedric.chaumont@linaro.org> (ARM Juno board)

show more ...

libtomcrypt: sync ccm code

https://github.com/libtom/libtomcrypt/issues/73 highlighted NIST specifications
are not met in previous implementation. Here is the description of this issue:
Accordin

libtomcrypt: sync ccm code

https://github.com/libtom/libtomcrypt/issues/73 highlighted NIST specifications
are not met in previous implementation. Here is the description of this issue:
According to the NIST specification of CCM, the authentication tag is
part of the ciphertext. In order to decrypt, this full ciphertext must
be decrypted, resulting in a "plaintext" tag. The tag must then be
recomputed upon the plaintext and compared with the decrypted value.
However, upon decryption in the libtom implementation, the ciphertext
is decrypted, and a tag is computed upon the header and (decrypted)
plaintext. This is then re-encrypted, so that the caller of the function
must compare the resulting (encryped) tag with the received (encrypted) tag.

The NIST specification specifies that "only the error message INVALID is
returned" when the decryption-verification fails. In that case "the payload
P and the MAC T shall not be revealed" and that "the implementation shall
ensure that an unauthorized party cannot distinguish whether the error
message results from [invalid message format] or from [authentication
failure], for example, from the timing of the error message."

Current patch:
- sync CCM libtomcrypt code with the ones in optee_os
- NIST specifications are now met.
Note that ccm_memory() API has been modified.
- check of non-null pointers
- remove spurious space
- remove compilation of ccm_memory which is not used in optee_os

Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (QEMU platform)
Signed-off-by: Pascal Brand <pascal.brand@st.com>

show more ...

Fix leaking information from mem_neq

This fix comes from https://github.com/libtom/libtomcrypt/issues/74
mem_neq is a constant time comparison function, but it leaks information
on the secre

Fix leaking information from mem_neq

This fix comes from https://github.com/libtom/libtomcrypt/issues/74
mem_neq is a constant time comparison function, but it leaks information
on the secret data that is being compared in the value that is returned.

Signed-off-by: Pascal Brand <pascal.brand@st.com>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (QEMU)

show more ...

arm: Fix SHA-1 with cryptographic extensions

Commit 23900b599a98 ("arm: update SHA-1 32-bit CE implementation to
process multiple blocks") has introduced a regression on 32-bit
platforms when CFG_CR

arm: Fix SHA-1 with cryptographic extensions

Commit 23900b599a98 ("arm: update SHA-1 32-bit CE implementation to
process multiple blocks") has introduced a regression on 32-bit
platforms when CFG_CRYPTO_SHA1_ARM32_CE=y. Test case: xtest 4006.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>

show more ...

Hmac key is made static, as in other macs

Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (QEMU platform)
Signed-off-by: Pascal Brand <p

Hmac key is made static, as in other macs

Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (QEMU platform)
Signed-off-by: Pascal Brand <pascal.brand@st.com>

show more ...

libtomcrypt: fix memory leak in test

Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Pascal Brand <pascal.brand@st.com>

libmpa: remove DEBUG flag

Traces in libmpa comes from legacy code. They are not used in
current code, nor can they be activated. Moreover, they look
obsolete and look hard to be useful in current st

libmpa: remove DEBUG flag

Traces in libmpa comes from legacy code. They are not used in
current code, nor can they be activated. Moreover, they look
obsolete and look hard to be useful in current state.

This patch removes traces in libmpa. This includes
- DEBUG and DEBUG_ME flags
- macros MEMPOOL_MARKER and MEMPOOL_SANITY_CHECK
- __mpa_dbg_xxx functions
- macro ASSERT
- files mpa_debug.h and mpa_assert.h

Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (QEMU platform)
Signed-off-by: Pascal Brand <pascal.brand@st.com>

show more ...

arm64: SHA-224/SHA-256 using ARMv8-A cryptographic extensions

Import SHA-2 assembly code from the Linux kernel (linaro contribution).
Enabled with CFG_CRYPTO_SHA256_ARM64_CE=y, set by default on HiK

arm64: SHA-224/SHA-256 using ARMv8-A cryptographic extensions

Import SHA-2 assembly code from the Linux kernel (linaro contribution).
Enabled with CFG_CRYPTO_SHA256_ARM64_CE=y, set by default on HiKey.
Performance gains compared to the C implementation are as follows
(sha-perf results for SHA-256 on HiKey in MiB/s):

Size | Accelerated?
(KiB) | No Yes
------+-------------
1 | 11.4 18.3
2 | 16.8 35.6
4 | 21.8 66.8
8 | 25.7 118.9
16 | 28.3 195.5
32 | 29.7 289.7
64 | 30.5 383.3
128 | 30.9 456.9
256 | 31.2 505.3
384 | 31.2 520.7

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>

show more ...

arm: update SHA-256 32-bit CE implementation to process multiple blocks

Adjust the 32-bit ARMv8 Crypto Extensions version of the SHA-256
"compress" function to accept multiple blocks of input data.

arm: update SHA-256 32-bit CE implementation to process multiple blocks

Adjust the 32-bit ARMv8 Crypto Extensions version of the SHA-256
"compress" function to accept multiple blocks of input data.
Rename a couple of files in preparation for the 64-bit implementation
which will follow, and for consistency with SHA-1.

Performances with various buffer sizes were measured on HiKey with
sha-perf. Values are in MiB/s, column 'n' means no acceleration,
'y (before)' is the parent commit's accelerated code, and 'y (after)'
is this commit.

Size | CFG_CRYPTO_SHA256_ARM32_CE=?
(KiB) | n | y (before) | y (after)
------+-------+------------+-----------
1 | 17.8 | 31.9 | 36.3
2 | 22.9 | 52.1 | 67.4
4 | 26.9 | 78.9 | 117.5
8 | 29.4 | 105.2 | 188.4
16 | 30.9 | 125.3 | 268.5
32 | 31.7 | 139.4 | 341.7
64 | 32.1 | 147.8 | 401.4
128 | 32.4 | 152.4 | 438.7
256 | 32.5 | 154.8 | 460.6
384 | 32.5 | 155.4 | 467.0

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>

show more ...

arm: update SHA-1 32-bit CE implementation to process multiple blocks

The assembly code in sha1_armv8a_ce_a32.S is updated so that
sha1_ce_transform() can process multiple blocks of data in a single

arm: update SHA-1 32-bit CE implementation to process multiple blocks

The assembly code in sha1_armv8a_ce_a32.S is updated so that
sha1_ce_transform() can process multiple blocks of data in a single
call. Performances are significantly improved, and the code is
unified with the 64-bit implementation.

Hashing throughput (MiB/s) reported by sha-perf on HiKey:

Size | CFG_CRYPTO_SHA1_ARM32_CE=?
(KiB) | n | y (parent) | y (this commit)
------+-------+------------+----------------
1 | 18.8 | 32.6 | 37.2
2 | 24.9 | 53.8 | 68.7
4 | 30.1 | 80.1 | 121.7
8 | 33.6 | 106.0 | 198.1
16 | 35.6 | 126.3 | 284.4
32 | 36.7 | 140.3 | 365.1
64 | 37.3 | 149.0 | 430.0
128 | 37.6 | 153.6 | 471.9
256 | 37.8 | 156.0 | 496.1
384 | 37.8 | 156.6 | 505.1

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>

show more ...

arm64: SHA-1 using ARMv8-A cryptographic extensions

- LibTomCrypt: add a new macro, HASH_PROCESS_NBLOCKS, similar to
HASH_PROCESS but accepts a function that digests n blocks of data, not
just 1.
-

arm64: SHA-1 using ARMv8-A cryptographic extensions

- LibTomCrypt: add a new macro, HASH_PROCESS_NBLOCKS, similar to
HASH_PROCESS but accepts a function that digests n blocks of data, not
just 1.
- Import sha1_ce_transform() from the Linux kernel (Linaro contribution)
which implements the main SHA-1 transform in assembler using the ARMv-8
cryptographic extensions.
- Acceleration is enabled by setting CFG_CRYPTO_SHA1_ARM64_CE=y (this
is the default when PLATFORM=hikey).

Performance was compared to the plain C version using sha-perf
(https://github.com/linaro-swg/sha-perf.git). Average hashing speed on
HiKey is (MiB/s):

Size | Accelerated?
(KiB) | No Yes
------+-------------
1 | 12.3 18.4
2 | 18.6 35.6
4 | 24.9 66.9
8 | 29.9 118.0
16 | 33.3 192.9
32 | 35.3 282.6
64 | 36.4 369.6
128 | 37.0 436.4
256 | 37.3 479.9
384 | 37.4 494.4

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>

show more ...

Fix des3_cbc_mac in case of 112bits key

In DES3, a key of 112 bits is made of 2 56 bits keys.
DES3 can be run using only 2 56 bit keys, with the 3rd
key being equal to the first.

Fix #408

Reviewed

Fix des3_cbc_mac in case of 112bits key

In DES3, a key of 112 bits is made of 2 56 bits keys.
DES3 can be run using only 2 56 bit keys, with the 3rd
key being equal to the first.

Fix #408

Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (QEMU)
Signed-off-by: Pascal Brand <pascal.brand@st.com>

show more ...

libmpa: optimize size in mpa_get_str()

Save 4098 bytes of unpageable memory by removing option to group hex
numbers in mpa_get_str().

Note API change in libmpa, dropping groupsize parameter for
mpa

libmpa: optimize size in mpa_get_str()

Save 4098 bytes of unpageable memory by removing option to group hex
numbers in mpa_get_str().

Note API change in libmpa, dropping groupsize parameter for
mpa_get_str()

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

show more ...

core: optimize size with const crypto_ops

Optimize size of unpaged data by making crypto_ops const.

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

core: optimize size with const crypto_ops

Optimize size of unpaged data by making crypto_ops const.

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

show more ...

Add Post-Actions on acipher crypto algorithms

In order to check that all temporary variables, used in
acipher computation, are correctly released,
tee_ltc_acipher_postactions() has been added. It ra

Add Post-Actions on acipher crypto algorithms

In order to check that all temporary variables, used in
acipher computation, are correctly released,
tee_ltc_acipher_postactions() has been added. It raises
an assert in case some temporary variables have not
been released.

Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (QEMU)
Signed-off-by: Pascal Brand <pascal.brand@st.com>

show more ...

ECC: optimize the pool of temporary variables

ECC is using a lot (80) temporary variables. These variables
are taken from a static pool, each being of the maximum key size
supported in OP-TEE: 4096b

ECC: optimize the pool of temporary variables

ECC is using a lot (80) temporary variables. These variables
are taken from a static pool, each being of the maximum key size
supported in OP-TEE: 4096bits, times 2 to include
wrapping multiplication in temporary computation.

With the introduction of being able to get temporary variables
of a given size, the current patch optimize the use of the variables
in case of ECC.

Thanks to this patch, the number of temporary variables is back to 50,
and the emulated esram size (QEMU / FVP / HiKey) is back to 200KB.

Note that further optimization can be performed, for ECC and also
for other algorithms (RSA,...).

Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (QEMU platform)
Signed-off-by: Pascal Brand <pascal.brand@st.com>

show more ...

mpa: allocator for temporary variables

Tempory variables, in math, are taken in a pool.
Each variable has its size maximized, that is 4096 * 2
in order to make overflowed operations.

However, in mo

mpa: allocator for temporary variables

Tempory variables, in math, are taken in a pool.
Each variable has its size maximized, that is 4096 * 2
in order to make overflowed operations.

However, in most of the cases, like ECC, such big variable
is not necessary.

This patch introduce an allocator to get temporary variables
of given size, which is an enabler to reduce the number of
required memory for temporary variables

Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Pascal Brand <pascal.brand@st.com>

show more ...