ECC: DH implementation and self tests

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

ECC: DH implementation and self tests

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

show more ...

GP11 : Asymmetric functions fix/panic reason

Signed-off-by: Cedric Chaumont <cedric.chaumont@st.com>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.

GP11 : Asymmetric functions fix/panic reason

Signed-off-by: Cedric Chaumont <cedric.chaumont@st.com>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@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 ...

arm64: AES XTS using ARMv8-A cryptographic extensions

This completes the work started with commit:
7e8f94166c6f ("arm64: AES using ARMv8-A cryptographic extensions").

The ltc_cipher_descriptor stru

arm64: AES XTS using ARMv8-A cryptographic extensions

This completes the work started with commit:
7e8f94166c6f ("arm64: AES using ARMv8-A cryptographic extensions").

The ltc_cipher_descriptor structure of LibTomCrypt is updated to include
pointers to accelerated XTS routines, which can handle multiple blocks
of data. The actual processing is done in assembly by
ce_aes_xts_encrypt() and ce_aes_xts_decrypt().

aes-perf results on HiKey are now on par with other AES modes.
In the table below, XTS is non-accelerated (CFG_CRYPTO_AES_ARM64_CE=n),
XTS+ is commit 7e8f94166c6f, and XTS++ is this commit.

Average encryption speed (MiB/s):

Size | Mode
(KiB) | XTS XTS+ XTS++
------+------------------
1 | 9.2 13.0 21.3
2 | 11.7 18.3 41.4
4 | 13.6 23.0 78.3
8 | 14.7 26.3 141.4
16 | 15.4 28.4 236.6
32 | 15.8 29.6 362.2
64 | 16.0 30.3 495.3
128 | 16.1 30.6 605.8

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

show more ...

ECC: sign and self tests, at crypto_ops level

Note that in case of pager, the emulated esram size
has been increased from 200KB to 256KB.

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

ECC: sign and self tests, at crypto_ops level

Note that in case of pager, the emulated esram size
has been increased from 200KB to 256KB.

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

show more ...

ECC: gen_ecc_key HAL

Implementation and test of crypto_ops.acipher.gen_ecc_key

Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Tested-by: P

ECC: gen_ecc_key HAL

Implementation and test of crypto_ops.acipher.gen_ecc_key

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

show more ...

arm64: AES using ARMv8-A cryptographic extensions

Adds AES acceleration to LibTomCrypt when CFG_CRYPTO_AES_ARM64_CE=y.

This commit implements an ltc_cipher_descriptor with accelerated
encryption an

arm64: AES using ARMv8-A cryptographic extensions

Adds AES acceleration to LibTomCrypt when CFG_CRYPTO_AES_ARM64_CE=y.

This commit implements an ltc_cipher_descriptor with accelerated
encryption and decryption for AES modes: ECB, CBC and CTR.
XTS will also benefit from CE acceleration since it relies on
ecb_encrypt() and ecb_decrypt(), but it may be beneficial to later
add multiple-blocks XTS operations to the descriptor.

The ARMv8 CE assembler code comes from the Linux kernel:
arch/arm64/crypto/{aes-modes.S,aes-ce.S,aes-ce-cipher.c}.

Tested on HiKey. CE code was benchmarked against plain C code using
the test application at http://github.com/linaro-swg/aes-perf.git.
A Trusted Application is invoked to encrypt a buffer of a given
size using TEE_CipherUpdate(). The client application measures the
time it takes for TEEC_InvokeCommand() to execute. The throughput
values below are computed from the average time it takes to encrypt
one buffer of the specified size. '+' after a mode means accelerated
with crypto extensions.

Average encryption speed (MiB/s):

Size | Mode
(KiB) | ECB CBC CTR XTS ECB+ CBC+ CTR+ XTS+
------+--------------------------------------------------
1 | 11.8 10.6 10.2 9.2 23.7 23.2 23.5 13.0
2 | 15.6 13.5 12.8 11.7 46.4 44.9 45.7 18.3
4 | 18.6 15.8 14.8 13.6 89.4 84.1 87.5 23.0
8 | 20.6 17.2 16.1 14.7 165.4 148.1 159.3 26.3
16 | 21.8 17.9 16.8 15.4 292.3 240.2 272.2 28.4
32 | 22.4 18.4 17.1 15.8 470.4 351.9 422.2 29.6
64 | 22.8 18.6 17.3 16.0 684.6 461.6 585.0 30.3
128 | 23.0 18.7 17.4 16.1 884.2 546.6 726.5 30.6

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

show more ...

ECC: Update LTC code from branch develop

Synchronize https://github.com/libtom/libtomcrypt,
src/pk/ecc, at sha1=aeaa6d4a515f390515c21f1678e11b52b81d1ada

Reviewed-by: Cedric Chaumont <cedric.chaumon

ECC: Update LTC code from branch develop

Synchronize https://github.com/libtom/libtomcrypt,
src/pk/ecc, at sha1=aeaa6d4a515f390515c21f1678e11b52b81d1ada

Reviewed-by: Cedric Chaumont <cedric.chaumont@linaro.org>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (QEMU)
Signed-off-by: Pascal Brand <pascal.brand@st.com>

show more ...

GP Internal Core API v1.1 : enable LibTomCrypt's ECC code

Note: ECC-256 commented (legacy)

Signed-off-by: Cedric Chaumont <cedric.chaumont@st.com>
Reviewed-by: Jerome Forissier <jerome.forissier@li

GP Internal Core API v1.1 : enable LibTomCrypt's ECC code

Note: ECC-256 commented (legacy)

Signed-off-by: Cedric Chaumont <cedric.chaumont@st.com>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@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 ...

Enhancing Secure Storage

- Implement encrypted file system key manager
* Key generation for SSK, FEK
* Provide helper APIs to do file encryption/decryption
* Finished key manager test cases fo

Enhancing Secure Storage

- Implement encrypted file system key manager
* Key generation for SSK, FEK
* Provide helper APIs to do file encryption/decryption
* Finished key manager test cases for file encryption/decryption tests

- Implements encrypted file system operations file-based operation
* file content is encrypted and MACed before storing
on normal world file system.
* file hole is not implemented because this is
meaningless in the context of secure storage.

Signed-off-by: SY Chiu <sy.chiu@linaro.org>
Signed-off-by: James Kung <james.kung@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Tested-by: SY Chiu <sy.chiu@linaro.org> (QEMU)
Tested-by: James Kung <james.kung@linaro.org> (QEMU)
Tested-by: Pascal Brand <pascal.brand@linaro.org> (STM platform)

show more ...

Fix potential memory leak in DH

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

Rename arm32 architecture to arm

Renames arm32 directories to arm.

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

Rename arm32 architecture to arm

Renames arm32 directories to arm.

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>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (QEMU platform)

show more ...

Added new interface in PRNG Hal to inject entropy

- Added add_entropy interface in crypto_ops.prng, and expose
new interface tee_prng_add_entropy() for platform vendor to
inject entropy.
- Injec

Added new interface in PRNG Hal to inject entropy

- Added add_entropy interface in crypto_ops.prng, and expose
new interface tee_prng_add_entropy() for platform vendor to
inject entropy.
- Inject entropy using current timestamp every time
when a session is opened or closed.

Signed-off-by: SY Chiu <sy.chiu@linaro.org>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
Tested-by: SY Chiu <sy.chiu@linaro.org> (FVP,QEMU)
Tested-by: Pascal Brand <pascal.brand@linaro.org> (QEMU)

show more ...

Added Abstract Layer for PRNG

- Extended crypto_ops with a new prng_ops which handles prng operations.
- Replace calls to get_rng_array() with crypto_ops.prng.read(), this
enforces PRNG operations

Added Abstract Layer for PRNG

- Extended crypto_ops with a new prng_ops which handles prng operations.
- Replace calls to get_rng_array() with crypto_ops.prng.read(), this
enforces PRNG operations go through PRNG HAL, instead of invoking
platform-dependent PRNG implementation directly.
- Create a new mpa_set_random_generator() interface for mpa user to register
a callback to generate random number, instead of expecting the user to provide
a get_rng_array(). This enables libmpa uses crypto_ops.prng.read().
- Added a new configuration CFG_WITH_PRNG_SOFTWARE to toggle SW/HW-dependent
PRNG implementation.
- The SW PRNG implementation is supplied by backed cryto library(libtomcrypt).
- Added a new SW PRNG 'Fortuna' to libtomcrypt.
- Added a new SW PRNG 'RC4' to libtomcrypt, when Fortuna is not available due
to AES and SHA256 not available, fallback to RC4.
- Get rid of bad implemented SW PRNG in plat_vexpress(rng_support.c).
- If CFG_WITH_PRNG_SOFTWARE is not enabled, the platform needs to supply
hw_get_random_byte().

Signed-off-by: SY Chiu <sy.chiu@linaro.org>
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (STM platform)
Tested-by: SY Chiu <sy.chiu@linaro.org> (QEMU)

show more ...

Libtomcrypt: use buf_compare_ct instead of mem_neq

This is a size-optimization, as the current optee_os code
already contains a function dedicated to constant-time
memory compare: buf_compare_ct()

Libtomcrypt: use buf_compare_ct instead of mem_neq

This is a size-optimization, as the current optee_os code
already contains a function dedicated to constant-time
memory compare: buf_compare_ct()

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

show more ...

RSA decode in constant time

This is a cherry-pick of the libtomcrypt pull-request
https://github.com/libtom/libtomcrypt/pull/57

As pointed by Herve Sibert, verification has been kept non-constant t

RSA decode in constant time

This is a cherry-pick of the libtomcrypt pull-request
https://github.com/libtom/libtomcrypt/pull/57

As pointed by Herve Sibert, verification has been kept non-constant time
in this patch.

Excerpt from original libtomcrypt pull-request:
as proposed in RFC 3447 only one error return code is used when there are
errors while decoding the pkcs#1 format.
also, all steps are executed and only the "output" is skipped if something
went wrong.

Sorry this could break backwards compatibility, since there's no more
BUFFER_OVERFLOW messaging.
Former error-handling code could also be affected because now there's only
OK as return code in cases where "res" is also set to '1'.

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

show more ...

SHA-1 ARMv8 crypto extension implementation

* Adds a ARMv8 crypto extension based SHA-1 implementation for LTC.
* Crypto extension based SHA-1 implementation is enabled for
plat-vexpress-juno.

Si

SHA-1 ARMv8 crypto extension implementation

* Adds a ARMv8 crypto extension based SHA-1 implementation for LTC.
* Crypto extension based SHA-1 implementation is enabled for
plat-vexpress-juno.

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

show more ...

SHA-256 ARMv8 crypto extension implementation

* Adds a ARMv8 crypto extension based SHA-256 implementation for LTC.
* Crypto extension based SHA-256 implementation is enabled for
plat-vexpress-ju

SHA-256 ARMv8 crypto extension implementation

* Adds a ARMv8 crypto extension based SHA-256 implementation for LTC.
* Crypto extension based SHA-256 implementation is enabled for
plat-vexpress-juno.

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

show more ...

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 bas

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>

show more ...

Fix #6686: Support passing Public Exponent when generating RSA key pair

Global Platform Internal API 1.0 is not accurate when describing
RSA key pair generation. It only indicates
No parameter i

Fix #6686: Support passing Public Exponent when generating RSA key pair

Global Platform Internal API 1.0 is not accurate when describing
RSA key pair generation. It only indicates
No parameter is required
This is why RSA key pair generation was always using 65537
as the public exponent.

Version 1.1 of the API is much more precise:
No parameter is required.
The TEE_ATTR_RSA_PUBLIC_EXPONENT attribute may be
specified; if omitted, the default value is 65537.

This patch implements this requirement.

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)
Reviewed-by: Laurent GERARD <laurent.gerard@st.com>
Reviewed-by: Jean-Michel DELORME <jean-michel.delorme@st.com>
Signed-off-by: Pascal Brand <pascal.brand@st.com>

show more ...

core: get value of CFG_ variables directly from generated/conf.h

Add a '-include' preprocessor flag to the command line so that all
TEE core files include generated/conf.h automatically. Then, there

core: get value of CFG_ variables directly from generated/conf.h

Add a '-include' preprocessor flag to the command line so that all
TEE core files include generated/conf.h automatically. Then, there
is no need to define macros via the command line (-DCFG_XYZ=...).

This commit also fixes a compile error when
CFG_TEE_CORE_EMBED_INTERNAL_TESTS=0.

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>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (STM platform)

show more ...

arm32: paging of TEE Core optionally enabled

plat-vexpress-*:
* Optionally enable paging with CFG_WITH_PAGER=y
* Uses fake SRAM when paging is enabled
* Supports partitioning OP-TEE binary in unpage

arm32: paging of TEE Core optionally enabled

plat-vexpress-*:
* Optionally enable paging with CFG_WITH_PAGER=y
* Uses fake SRAM when paging is enabled
* Supports partitioning OP-TEE binary in unpaged, init and pagable areas

plat-stm:
* Displays an error message if compiled with CFG_WITH_PAGER=y

arm32:
* Replaces legacy paging support with new paging support
* Removes unused tee_pager_unpg.c

Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Tested-by: Jens Wiklander <jens.wiklander@linaro.org> (QEMU, FVP, Juno)
Reviewed-by: Pascal Brand <pascal.brand@linaro.org>
Tested-by: Pascal Brand <pascal.brand@linaro.org> (STM platform - Check the code without the pager is not broken).

show more ...

provide hash_sha256_check()

Adds hash_sha256_check() to the tee_crypt_provider interface to be
used by pager and early initialization code where the complete crypto
library might not be available.

provide hash_sha256_check()

Adds hash_sha256_check() to the tee_crypt_provider interface to be
used by pager and early initialization code where the complete crypto
library might not be available.

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

show more ...

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 tha

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>

show more ...

Select cryptographic algorithms at compile time

Allows to disable some cryptographic algorithms by setting make variables
at build time (either from the environment, the command line or by editing
c

Select cryptographic algorithms at compile time

Allows to disable some cryptographic algorithms by setting make variables
at build time (either from the environment, the command line or by editing
core/lib/libtomcrypt/sub.mk).

For example:
$ make ... CFG_CRYPTO=n
$ make ... CFG_CRYPTO_DES=n

This can reduce the size of the TEE binary as well as its memory footprint:

$ make -j9 PLATFORM=vexpress-qemu_virt DEBUG= all mem_usage
$ grep RAM out/arm32-plat-vexpress/core/tee.mem_usage
RAM Usage 7DF00000 - 7DF39280 size 00039280 229 KiB 58 pages
$ du -h out/arm32-plat-vexpress/core/tee.bin
164K out/arm32-plat-vexpress/core/tee.bin

$ make -j9 PLATFORM=vexpress-qemu_virt DEBUG= CFG_CRYPTO=n all mem_usage
$ grep RAM out/arm32-plat-vexpress/core/tee.mem_usage
RAM Usage 7DF00000 - 7DF1D280 size 0001D280 117 KiB 30 pages
$ du -h out/arm32-plat-vexpress/core/tee.bin
104K out/arm32-plat-vexpress/core/tee.bin

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

show more ...

MAC operations now supports NULL arguments

MAC algorithms support NULL arguments and zero length strings.

Note that the fix consists in a change of API in the internal crypto
interface. This change

MAC operations now supports NULL arguments

MAC algorithms support NULL arguments and zero length strings.

Note that the fix consists in a change of API in the internal crypto
interface. This change make hash_ops and mac_ops look the same in terms of
update and final step

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

show more ...