plat: rcar: add support for ROM API calls including HW RNG

RCAR Gen3 SoCs have public ROM API functions that provide access to various
security-related features, including access to hardware random

plat: rcar: add support for ROM API calls including HW RNG

RCAR Gen3 SoCs have public ROM API functions that provide access to various
security-related features, including access to hardware random number
generator.

This patch adds both generic ROM API interface and wrapper function for
ROM_GetRndVector() call.

As ROM API code is written with identity mapping in mind, we can't call
those function with MMU enabled. So we need a special trampoline function
that would disable MMU, save state and jump to ROM API code.

Beginning with the latest revisions (H3 ES3.0, M3 ES1.1, etc) of Renesas
SoCs, ROM API addresses are fixed, but prior to that each family had own
address, so we need to maintain table of all possible addressed and select
correct one in runtime.

Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Jerome Forissier <jerome@forissier.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

plat: rcar: store PRR value in global variable

Product Register will be needed not only by get_core_pos_mpidr
function but by other platform code as well. So move its cached
value into variable in m

plat: rcar: store PRR value in global variable

Product Register will be needed not only by get_core_pos_mpidr
function but by other platform code as well. So move its cached
value into variable in main.c

Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Jerome Forissier <jerome@forissier.org>

show more ...

plat: rcar: disable aarch32 support for OP-TEE core

While it is theoretically possible to boot RCar Gen3 SoC in aarch32
mode, it isn't supported by Renesas BSP. ARM TF provided by Renesas
boots only

plat: rcar: disable aarch32 support for OP-TEE core

While it is theoretically possible to boot RCar Gen3 SoC in aarch32
mode, it isn't supported by Renesas BSP. ARM TF provided by Renesas
boots only in aarch64 mode. Also it lacks aarch32 assembler code, so
it is not possible to built it for aarch32 at all.

Therefore, there is a little sense in supporting aarch32 in
OP-TEE (for plat-rcar, of course) - user just can't boot it. On other
hand it requires additional efforts to maintain aarch32 assembly code
that newer will be used.

This patch enforces CFG_ARM64_core build option and removes all
aarch32 related parts.

Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Jerome Forissier <jerome@forissier.org>

show more ...

boot: introduce plat_get_aslr_seed()

Platforms may provide own ways to get ASLR seed, so this commit
adds weak function plat_get_aslr_seed(), which is called when we
can't obtain seed from FDT.

Sig

boot: introduce plat_get_aslr_seed()

Platforms may provide own ways to get ASLR seed, so this commit
adds weak function plat_get_aslr_seed(), which is called when we
can't obtain seed from FDT.

Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Jerome Forissier <jerome@forissier.org>

show more ...

drivers: scif: update base address in scif_uart_init()

Prior this patch function scif_uart_init() didn't called io_pa_or_va()
to determine correct base address for the device. This worked fine
becau

drivers: scif: update base address in scif_uart_init()

Prior this patch function scif_uart_init() didn't called io_pa_or_va()
to determine correct base address for the device. This worked fine
because in most cases OP-TEE address space is identity mapped. But,
this breaks if are trying to enable ASLR, because SCIF MMIO range is
no more 1:1 mapped.

To fix this we need to use io_pa_or_va() as all other drivers do.

Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Jerome Forissier <jerome@forissier.org>

show more ...

ta: pkcs11: Add support for elliptic curve signing & verification

Add support for performing elliptic curve signing & verification
operations for:

- ECDSA with supplied hash value
- Multi stage SHA

ta: pkcs11: Add support for elliptic curve signing & verification

Add support for performing elliptic curve signing & verification
operations for:

- ECDSA with supplied hash value
- Multi stage SHA-1
- Multi stage SHA-224
- Multi stage SHA-256
- Multi stage SHA-384
- Multi stage SHA-512

Specified in:
PKCS #11 Cryptographic Token Interface Current Mechanisms Specification
Version 2.40 Plus Errata 01
2.3 Elliptic Curve

Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Ricardo Salveti <ricardo@foundries.io>
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>

show more ...

ta: pkcs11: Add support for elliptic curve key pair generation

Specified in:
PKCS #11 Cryptographic Token Interface Current Mechanisms Specification
Version 2.40 Plus Errata 01

2.3.5 Elliptic curve

ta: pkcs11: Add support for elliptic curve key pair generation

Specified in:
PKCS #11 Cryptographic Token Interface Current Mechanisms Specification
Version 2.40 Plus Errata 01

2.3.5 Elliptic curve key pair generation

Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Co-developed-by: Ricardo Salveti <ricardo@foundries.io>
Signed-off-by: Ricardo Salveti <ricardo@foundries.io>
Co-developed-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>

show more ...

ta: pkcs11: scripts: Add script for generating EC curve parameters

Initial supports for curves:

- prime192v1
- secp224r1
- prime256v1
- secp384r1
- secp521r1

Acked-by: Etienne Carriere <etienne.ca

ta: pkcs11: scripts: Add script for generating EC curve parameters

Initial supports for curves:

- prime192v1
- secp224r1
- prime256v1
- secp384r1
- secp521r1

Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Ricardo Salveti <ricardo@foundries.io>
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>

show more ...

ta: pkcs11: Add generic support for key pair generation

This commit only adds common key pair generation support code.

Actual mechanism specific key pair generation codes are in their own
commits.

ta: pkcs11: Add generic support for key pair generation

This commit only adds common key pair generation support code.

Actual mechanism specific key pair generation codes are in their own
commits.

Specified in:
PKCS #11 Cryptographic Token Interface Base Specification Version 2.40 Plus
Errata 01

5.13 Key management functions
C_GenerateKeyPair

Reviewed-by: Ricardo Salveti <ricardo@foundries.io>
Co-developed-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>

show more ...

ta: pkcs11: Allocate command ID for key pair generation

Allocate command ID for C_GenerateKeyPair() functionality.

Reviewed-by: Ricardo Salveti <ricardo@foundries.io>
Co-developed-by: Etienne Carri

ta: pkcs11: Allocate command ID for key pair generation

Allocate command ID for C_GenerateKeyPair() functionality.

Reviewed-by: Ricardo Salveti <ricardo@foundries.io>
Co-developed-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>

show more ...

ta: pkcs11: Add helper for setting up CKA_ID value

When generating a new key pair object adds CKA_ID attribute from paired
object template if value given.

Reviewed-by: Etienne Carriere <etienne.car

ta: pkcs11: Add helper for setting up CKA_ID value

When generating a new key pair object adds CKA_ID attribute from paired
object template if value given.

Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Ricardo Salveti <ricardo@foundries.io>
Co-developed-by: Gabor Szekely <szvgabor@gmail.com>
Signed-off-by: Gabor Szekely <szvgabor@gmail.com>
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>

show more ...

ta: pkcs11: Fix get_default_value/PKCS11_CKA_PUBLIC_KEY_INFO

Default value for CKA_PUBLIC_KEY_INFO is empty unless asymmetric
mechanism is specified.

When asymmetric mechanism is specified it shoul

ta: pkcs11: Fix get_default_value/PKCS11_CKA_PUBLIC_KEY_INFO

Default value for CKA_PUBLIC_KEY_INFO is empty unless asymmetric
mechanism is specified.

When asymmetric mechanism is specified it should contribute the actual
value.

Reviewed-by: Ricardo Salveti <ricardo@foundries.io>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>

show more ...

ta: pkcs11: CKA_SUBJECT is mandatory for keys but has default value

When creating a new public/private key in its template it is not mandatory
to have CKA_SUBJECT field. However in the object stored

ta: pkcs11: CKA_SUBJECT is mandatory for keys but has default value

When creating a new public/private key in its template it is not mandatory
to have CKA_SUBJECT field. However in the object stored in it must be
present.

If CKA_SUBJECT is not present it will be given empty default value.

In PKCS #11 Cryptographic Token Interface Base Specification Version 2.40
Plus Errata 01:

4.8 Public key objects:

CKA_SUBJECT -- DER-encoding of the key subject name (default empty)

4.9 Private key objects:

CKA_SUBJECT -- DER-encoding of the key subject name (default empty)

Reviewed-by: Ricardo Salveti <ricardo@foundries.io>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>

show more ...

drivers: caam: fix CMAC data input handling

Depending on the memory buffer input configuration, the function
caam_dmaobj_sgtbuf_build() might modify the data size to be processed in
the loop.
This c

drivers: caam: fix CMAC data input handling

Depending on the memory buffer input configuration, the function
caam_dmaobj_sgtbuf_build() might modify the data size to be processed in
the loop.
This case happens sometimes on the imx8mp where the input buffer
physical address in above 32 bits.
This implies reporting the data size re-ajustment when data is saved in
the context buffer.

Signed-off-by: Clement Faure <clement.faure@nxp.com>
Acked-by: Jerome Forissier <jerome@forissier.org>

show more ...

plat-vexpress: FF-A: update secondary core init

Currently when using FF-A on FVP platform, the secondary core entrypoint
registration is done with PSCI calls. However, this relies on a forked
TF-A v

plat-vexpress: FF-A: update secondary core init

Currently when using FF-A on FVP platform, the secondary core entrypoint
registration is done with PSCI calls. However, this relies on a forked
TF-A version, as normally PSCI calls aren't accepted from SWd. Replace
this mechanism with FFA_SECONDARY_EP_REGISTER, which is an FF-A v1.1
ALP0 ABI and it's supported by upstream TF-A v2.5.

Note that the Function ID expected by TF-A differs from the one in the
spec, this will be fixed when the spec is finalized, but the overall
mechanism should stay the same.

Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Signed-off-by: Balint Dobszay <balint.dobszay@arm.com>

show more ...

core: pta: scmi: fix missing threaded state of the channel

Enable SMT channel threaded state when SCMI PTA gets a channel. Before
this fixup, Core panics when SCMI message is posted since the assert

core: pta: scmi: fix missing threaded state of the channel

Enable SMT channel threaded state when SCMI PTA gets a channel. Before
this fixup, Core panics when SCMI message is posted since the assertion
on channel threaded field value in scmi_smt_threaded_entry() when
in debug mode.

Fixes: b0a1c2504aaf ("core: pta: scmi: new interface to REE SCMI agent")
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: rpmb: use IS_ENABLED on CFG_RPMB_FS_DEBUG_DATA

Replace #ifdef with if (IS_ENABLED()) for CFG_RPMB_FS_DEBUG_DATA.

Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Jen

core: rpmb: use IS_ENABLED on CFG_RPMB_FS_DEBUG_DATA

Replace #ifdef with if (IS_ENABLED()) for CFG_RPMB_FS_DEBUG_DATA.

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

show more ...

config: add description for CFG_RPMB_* config switches

Add a short description for some CFG_RPMB_* configuration switches
not described anywhere.

Signed-off-by: Etienne Carriere <etienne.carriere@l

config: add description for CFG_RPMB_* config switches

Add a short description for some CFG_RPMB_* configuration switches
not described anywhere.

Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Jerome Forissier <jerome@forissier.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: rpmb: remove CFG_RPMB_FS_NO_MAC

Remove CFG_RPMB_FS_NO_MAC that disabled authentication of RPMB frames
read from the device. The switch was not documented never enabled in
the project hence it

core: rpmb: remove CFG_RPMB_FS_NO_MAC

Remove CFG_RPMB_FS_NO_MAC that disabled authentication of RPMB frames
read from the device. The switch was not documented never enabled in
the project hence it simply removed.

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

show more ...

drivers: caam: remove faulty DMAOJB_TRACE()

Remove DMA object debug trace that would print a structure
variable through a NULL pointer.

Signed-off-by: Clement Faure <clement.faure@nxp.com>
Reviewed

drivers: caam: remove faulty DMAOJB_TRACE()

Remove DMA object debug trace that would print a structure
variable through a NULL pointer.

Signed-off-by: Clement Faure <clement.faure@nxp.com>
Reviewed-by: Jerome Forissier <jerome@forissier.org>

show more ...

core: a32: fix parameter passing for __thread_std_smc_entry()

With the commit referred below is __thread_std_smc_entry() changed to
take 6 arguments instead of 4. This means with the arm32 calling
c

core: a32: fix parameter passing for __thread_std_smc_entry()

With the commit referred below is __thread_std_smc_entry() changed to
take 6 arguments instead of 4. This means with the arm32 calling
convention [1] that the last two parameters are passed on the stack.
This is handled automatically by the C compiler, but has to be done by
hand when calling from assembly. __thread_std_smc_entry() is called from
assembly so fix the two places where the function is called.

Link [1]: https://developer.arm.com/documentation/ihi0042/latest/

Fixes: 4107d2f93e3e ("core: add a4 and a5 to thread_alloc_and_run()")
Reviewed-by: Jerome Forissier <jerome@forissier.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

mem_usage.py: consider all allocatable sections

All allocatable sections end up using memory when the TEE binary is
loaded. Therefore the 'A' (allocatable) flag in the readelf output is
all that mat

mem_usage.py: consider all allocatable sections

All allocatable sections end up using memory when the TEE binary is
loaded. Therefore the 'A' (allocatable) flag in the readelf output is
all that matters when gathering memory usage data using mem_usage.py.
The combinations that are currently hardcoded in the script ('AX',
'WA', 'A', 'AL') are fragile and need to be replaced. For example, with
COMPILER=clang many sections have the 'W' flag set.

Signed-off-by: Jerome Forissier <jerome@forissier.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: pager: fix compiler warning with Clang

Function rwp_unpaged_iv_free() is reduced to a call to panic() when
CFG_WITH_PAGER=y and CFG_CORE_PAGE_TAG_AND_IV=y. In this case, Clang 12
suggests a no

core: pager: fix compiler warning with Clang

Function rwp_unpaged_iv_free() is reduced to a call to panic() when
CFG_WITH_PAGER=y and CFG_CORE_PAGE_TAG_AND_IV=y. In this case, Clang 12
suggests a noreturn attribute:

$ make -s CFG_WITH_PAGER=y COMPILER=clang
core/mm/fobj.c:322:1: warning: function 'rwp_unpaged_iv_free' could be
declared with attribute 'noreturn' [-Wmissing-noreturn]
{
^
1 warning generated.

However the attribute cannot be applied since it would be inappropriate
when CFG_CORE_PAGE_TAG_AND_IV != y. Therefore, disable the warning for
the file core/mm/fobj.c when the problematic configuration is enabled.

Signed-off-by: Jerome Forissier <jerome@forissier.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: allow configuration without any secure storage

Support a configuration with no secure storage (CFG_REE_FS=n and
CFG_RPMB_FS=n). In such a case, user TAs will get error code
TEEC_ERROR_ITEM_NOT

core: allow configuration without any secure storage

Support a configuration with no secure storage (CFG_REE_FS=n and
CFG_RPMB_FS=n). In such a case, user TAs will get error code
TEEC_ERROR_ITEM_NOT_FOUND when trying to access persistent objects.

Signed-off-by: Jerome Forissier <jerome@forissier.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...

core: zlib: fix build warning when _LFS64_LARGEFILE is not defined

In zlib, _LFS64_LARGEFILE is expected to be a boolean directive, either
1 (true) or 0 (false). Depending on toolchain version and d

core: zlib: fix build warning when _LFS64_LARGEFILE is not defined

In zlib, _LFS64_LARGEFILE is expected to be a boolean directive, either
1 (true) or 0 (false). Depending on toolchain version and directives
build may produces warnings (as shown below with gcc 9.3) when the macro
is not defined hence this change to default it to value 0 (false).

core/lib/zlib/zutil.h:196:39: warning: "_LFS64_LARGEFILE" is not defined, evaluates to 0 [-Wundef]
196 | (!defined(_LARGEFILE64_SOURCE) || _LFS64_LARGEFILE-0 == 0)
| ^~~~~~~~~~~~~~~~
In file included from core/lib/zlib/adler32.c:9:
core/lib/zlib/zutil.h:196:39: warning: "_LFS64_LARGEFILE" is not defined, evaluates to 0 [-Wundef]
196 | (!defined(_LARGEFILE64_SOURCE) || _LFS64_LARGEFILE-0 == 0)
| ^~~~~~~~~~~~~~~~
CC out/core/lib/zlib/zutil.o
In file included from core/lib/zlib/inftrees.c:7:
core/lib/zlib/zutil.h:196:39: warning: "_LFS64_LARGEFILE" is not defined, evaluates to 0 [-Wundef]
196 | (!defined(_LARGEFILE64_SOURCE) || _LFS64_LARGEFILE-0 == 0)
| ^~~~~~~~~~~~~~~~
In file included from core/lib/zlib/inflate.c:84:
core/lib/zlib/zutil.h:196:39: warning: "_LFS64_LARGEFILE" is not defined, evaluates to 0 [-Wundef]
196 | (!defined(_LARGEFILE64_SOURCE) || _LFS64_LARGEFILE-0 == 0)
| ^~~~~~~~~~~~~~~~
In file included from core/lib/zlib/zutil.c:9:
core/lib/zlib/zutil.h:196:39: warning: "_LFS64_LARGEFILE" is not defined, evaluates to 0 [-Wundef]
196 | (!defined(_LARGEFILE64_SOURCE) || _LFS64_LARGEFILE-0 == 0)
| ^~~~~~~~~~~~~~~~

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

show more ...