Updated mbedTLS driver to include mbedTLS functions necessary for a
DRTM supported build.
Signed-off-by: Manish V Badarkhe <manish.badarkhe@arm.com>
Change-Id: If0120374a971519cf84f93e0c59e1a320a72cd97
Updated crypto module to include crypto calls necessary for a
DRTM supported build.
Signed-off-by: Manish V Badarkhe <manish.badarkhe@arm.com>
Change-Id: I4f945997824393f46864b7fb7fd380308a025452
- Removing platform dependencies from libc modules.
- Replacing panicking with actual error handling.
- Debug macros are included indirectly from assert.h. Removing
"platform_def.h" from assert.h and adding "common/debug.h"
where the macros are used.
- Removing hack for fixing PLAT_LOG_LEVEL_ASSERT to 40.
Instead removing assert with expression, as this
does not provide additional information.
Signed-off-by: Claus Pedersen <claustbp@google.com>
Change-Id: Icc201ea7b63c1277e423c1cfd13fd6816c2bc568
With RSS now introduced, we have 2 Measured Boot backends. Both backends
can be used in the same firmware build with potentially different hash
algorithms, so now there can be more than one hash algorithm in a build.
Therefore the logic for selecting the measured boot hash algorithm needs
to be updated and the coordination of algorithm selection added. This is
done by:
- Adding MBOOT_EL_HASH_ALG for Event Log to define the hash algorithm
to replace TPM_HASH_ALG, removing reference to TPM.
- Adding MBOOT_RSS_HASH_ALG for RSS to define the hash algorithm to
replace TPM_HASH_ALG.
- Coordinating MBOOT_EL_HASH_ALG and MBOOT_RSS_HASH_ALG to define the
Measured Boot configuration macros through defining
TF_MBEDTLS_MBOOT_USE_SHA512 to pull in SHA-512 support if either
backend requires a stronger algorithm than SHA-256.
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: I4ddf06ebdc3835beb4d1b6c7bab5a257ffc5c71a
This chain of trust is targeted at Arm CCA solutions and defines 3
independent signing domains:
1) CCA signing domain. The Arm CCA Security Model (Arm DEN-0096.A.a) [1]
refers to the CCA signing domain as the provider of CCA components
running on the CCA platform. The CCA signing domain might be independent
from other signing domains providing other firmware blobs.
The CCA platform is a collective term used to identify all hardware and
firmware components involved in delivering the CCA security guarantee.
Hence, all hardware and firmware components on a CCA enabled system that
a Realm is required to trust.
In the context of TF-A, this corresponds to BL1, BL2, BL31, RMM and
associated configuration files.
The CCA signing domain is rooted in the Silicon ROTPK, just as in the
TBBR CoT.
2) Non-CCA Secure World signing domain. This includes SPMC (and
associated configuration file) as the expected BL32 image as well as
SiP-owned secure partitions. It is rooted in a new SiP-owned key called
Secure World ROTPK, or SWD_ROTPK for short.
3) Platform owner signing domain. This includes BL33 (and associated
configuration file) and the platform owner's secure partitions. It is
rooted in the Platform ROTPK, or PROTPK.
[1] https://developer.arm.com/documentation/DEN0096/A_a
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: I6ffef3f53d710e6a2072fb4374401249122a2805
Upgrade to the latest and greatest 2.x release of Mbed TLS library
(i.e. v2.28.0) to take advantage of their bug fixes.
Note that the Mbed TLS project published version 3.x some time
ago. However, as this is a major release with API breakages, upgrading
to 3.x might require some more involved changes in TF-A, which we are
not ready to do. We shall upgrade to mbed TLS 3.x after the v2.7
release of TF-A.
Actually, the upgrade this time simply boils down to including the new
source code module 'constant_time.c' into the firmware.
To quote mbed TLS v2.28.0 release notes [1]:
The mbedcrypto library includes a new source code module
constant_time.c, containing various functions meant to resist timing
side channel attacks. This module does not have a separate
configuration option, and functions from this module will be
included in the build as required.
As a matter of fact, if one is attempting to link TF-A against mbed
TLS v2.28.0 without the present patch, one gets some linker errors
due to missing symbols from this new module.
Apart from this, none of the items listed in mbed TLS release
notes [1] directly affect TF-A. Special note on the following one:
Fix a bug in mbedtls_gcm_starts() when the bit length of the iv
exceeds 2^32.
In TF-A, we do use mbedtls_gcm_starts() when the firmware decryption
feature is enabled with AES-GCM as the authenticated decryption
algorithm (DECRYPTION_SUPPORT=aes_gcm). However, the iv_len variable
which gets passed to mbedtls_gcm_starts() is an unsigned int, i.e. a
32-bit value which by definition is always less than 2**32. Therefore,
we are immune to this bug.
With this upgrade, the size of BL1 and BL2 binaries does not appear to
change on a standard sample test build (with trusted boot and measured
boot enabled).
[1] https://github.com/Mbed-TLS/mbedtls/releases/tag/v2.28.0
Change-Id: Icd5dbf527395e9e22c8fd6b77427188bd7237fd6
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Common mbedTLS implementation include the fixed configuration
file of mbedTLS and that does not gives flexilibility to the
platform to include their own mbedTLS configuration.
Hence changes are done so that platform can include their own
mbedTLS configuration file.
Signed-off-by: Lucian Paul-Trifu <lucian.paul-trifu@arm.com>
Signed-off-by: Manish V Badarkhe <manish.badarkhe@arm.com>
Change-Id: I04546589f67299e26b0a6a6e151cdf1fdb302607
Measured-Boot and Trusted-Boot are orthogonal to each other and hence
removed dependency of Trusted-Boot on Measured-Boot by making below
changes -
1. BL1 and BL2 main functions are used for initializing Crypto module
instead of the authentication module
2. Updated Crypto module registration macro for MEASURED_BOOT with only
necessary callbacks for calculating image hashes
3. The 'load_auth_image' function is now used for the image measurement
during Trusted or Non-Trusted Boot flow
Change-Id: I3570e80bae8ce8f5b58d84bd955aa43e925d9fff
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
It doesn't look correct to use mbed TLS defines directly in the Event
Log driver as this driver may use another Crypto library in future.
Hence mbed TLS Crypto dependency on Event Log driver is removed by
introducing generic Crypto defines and uses those in the Event Log
driver to call Crypto functions.
Also, updated mbed TLS glue layer to map these generic Crypto defines
to mbed TLS library defines.
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: Ibc9c751f60cbce4d3f3cf049b7c53b3d05cc6735
Fixed a below build failure with CC-713 library
error:
implicit declaration of function ‘mbedtls_x509_get_rsassa_pss_params’
[-Werror=implicit-function-declaration]
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: If298ec16d133cf54413c299327b2c007ec4117b2
Adding load, authentication, and transfer functionality from FVP R BL1 to
BL33, which will be the partner runtime code.
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: I293cad09739dacac0d20dd57c1d98178dbe84d40
Avoided NV counter update when the system is running in
trial run state.
Change-Id: I5da6a6760f8a9faff777f2ff879156e9c3c76726
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Platform NV counter get updated (if cert NV counter > plat NV counter)
before authenticating the certificate if the platform specifies NV
counter method before signature authentication in its CoT, and this
provides an opportunity for a tempered certificate to upgrade the
platform NV counter. This is theoretical issue, as in practice none
of the standard CoT (TBBR, dualroot) or upstream platforms ones (NXP)
exercised this issue.
To fix this issue, modified the auth_nvctr method to do only NV
counter check, and flags if the NV counter upgrade is needed or not.
Then ensured that the platform NV counter gets upgraded with the NV
counter value from the certificate only after that certificate gets
authenticated.
This change is verified manually by modifying the CoT that specifies
certificate with:
1. NV counter authentication before signature authentication
method
2. NV counter authentication method only
Change-Id: I1ad17f1a911fb1035a1a60976cc26b2965b05166
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
This patch migrates the mbedcrypto dependency for TF-A
to mbedTLS repo v2.24.0 which is the latest release tag.
The relevant documentation is updated to reflect the
use of new version.
Change-Id: I116f44242e8c98e856416ea871d11abd3234dac1
Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Loop macros make it easier for developers to include new variables to
assert or define and also help code code readability on makefiles.
Change-Id: I0d21d6e67b3eca8976c4d856ac8ccc02c8bb5ffa
Signed-off-by: Leonardo Sandoval <leonardo.sandoval@linaro.org>
For dualroot CoT there are two sets of SP certificates, one owned by
Silicon Provider(SiP) and other owned by Platform. Each certificate can
have a maximum of 4 SPs.
This patch reduces the number of SiP owned SPs from 8 to 4 and adds
the remaining 4 to Plat owned SP.
Plat owned SP certificate is signed using Platform RoT key and
protected against anti-rollback using the Non-trusted Non-volatile
counter.
Change-Id: Idc3ddd87d6d85a5506a7435f45a6ec17c4c50425
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Currently only single signing domain is supported for SP packages but
there is plan to support dual signing domains if CoT is dualroot.
SP_CONTENT_CERT_ID is the certificate file which is currently generated
and signed with trusted world key which in-turn is derived from Silicon
provider RoT key.
To allow dual signing domain for SP packages, other certificate file
will be derived from Platform owned RoT key.
This patch renames "SP_CONTENT_CERT_ID" to "SIP_SP_CONTENT_CERT_ID" and
does other related changes.
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: I0bc445a3ab257e2dac03faa64f46e36a9fed5e93
This patch adds support for Event Log generation required
for Measured Boot functionality.
Change-Id: I34f05a33565e6659e78499d62cc6fb00b7d6c2dc
Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
with sha 44f1aa8, support for Silicon Provider(SiP) owned Secure
Partition(SP) was added for dualroot CoT. This patch extends this
support for tbbr CoT.
Earlier tbbr CoT for SPs was left to avoid adding new image types in
TBBR which could possibly be seen as deviation from specification.
But with further discussions it is understood that TBBR being a
*minimal* set of requirements that can be extended as long as we don't
violate any of the musts, which is the case with adding SP support.
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: I1b9e3ebdd7d653f1fd4cc3bd910a69871b55ecbb
A new certificate "sip-sp-cert" has been added for Silicon Provider(SiP)
owned Secure Partitions(SP). A similar support for Platform owned SP can
be added in future. The certificate is also protected against anti-
rollback using the trusted Non-Volatile counter.
To avoid deviating from TBBR spec, support for SP CoT is only provided
in dualroot.
Secure Partition content certificate is assigned image ID 31 and SP
images follows after it.
The CoT for secure partition look like below.
+------------------+ +-------------------+
| ROTPK/ROTPK Hash |------>| Trusted Key |
+------------------+ | Certificate |
| (Auth Image) |
/+-------------------+
/ |
/ |
/ |
/ |
L v
+------------------+ +-------------------+
| Trusted World |------>| SiP owned SPs |
| Public Key | | Content Cert |
+------------------+ | (Auth Image) |
/ +-------------------+
/ |
/ v|
+------------------+ L +-------------------+
| SP_PKG1 Hash |------>| SP_PKG1 |
| | | (Data Image) |
+------------------+ +-------------------+
. .
. .
. .
+------------------+ +-------------------+
| SP_PKG8 Hash |------>| SP_PKG8 |
| | | (Data Image) |
+------------------+ +-------------------+
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: Ia31546bac1327a3e0b5d37e8b99c808442d5e53f
CoT used for BL1 and BL2 are moved to tbbr_cot_bl1.c
and tbbr_cot_bl2.c respectively.
Common CoT used across BL1 and BL2 are moved to
tbbr_cot_common.c.
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: I2252ac8a6960b3431bcaafdb3ea4fb2d01b79cf5
Add Crypto 713 support as crypto module and NVM counter provider.
As files under include/drivers/arm/cryptocell/713/ are copied verbatim
from the CryptoCell SBROM lib project they are filtered from checkpatch
coding style check.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Change-Id: I7c361772f00ca7d96481f81ac6cbb2704467e52c
This patch provides support for measured boot by adding calculation
of BL2 image hash in BL1 and writing these data in TB_FW_CONFIG DTB.
Change-Id: Ic074a7ed19b14956719c271c805b35d147b7cec1
Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Add framework for autheticated decryption of data. Currently this
patch optionally imports mbedtls library as a backend if build option
"DECRYPTION_SUPPORT = aes_gcm" is set to perform authenticated decryption
using AES-GCM algorithm.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Change-Id: I2966f0e79033151012bf4ffc66f484cd949e7271
This new chain of trust defines 2 independent signing domains:
1) One for the silicon firmware (BL1, BL2, BL31) and optionally the
Trusted OS. It is rooted in the Silicon ROTPK, just as in the TBBR
CoT.
2) One for the Normal World Bootloader (BL33). It is rooted in a new key
called Platform ROTPK, or PROTPK for short.
In terms of certificates chain,
- Signing domain 1) is similar to what TBBR advocates (see page 21 of
the TBBR specification), except that the Non-Trusted World Public Key
has been removed from the Trusted Key Certificate.
- Signing domain 2) only contains the Non-Trusted World Content
certificate, which provides the hash of the Non-Trusted World
Bootloader. Compared to the TBBR CoT, there's no Non-Trusted World
Key certificate for simplicity.
Change-Id: I62f1e952522d84470acc360cf5ee63e4c4b0b4d9
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
The TBBR implementation extracts hashes from certificates and stores
them in static buffers. TF-A supports 3 variants of SHA right now:
SHA-256, SHA-384 and SHA-512. When support for SHA-512 was added in
commit 9a3088a5f5 ("tbbr: Add build flag
HASH_ALG to let the user to select the SHA"), the hash buffers got
unconditionally increased from 51 to 83 bytes each. We can reduce that
space if we're using SHA-256 or SHA-384.
This saves some BSS space in both BL1 and BL2:
- BL1 with SHA-256: saving 168 bytes.
- BL1 with SHA-384: saving 80 bytes.
- BL2 with SHA-256: saving 384 bytes.
- BL2 with SHA-384: saving 192 bytes.
Change-Id: I0d02e5dc5f0162e82339c768609c9766cfe7e2bd
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
The TBBR implementation extracts public keys from certificates and
stores them in static buffers. DER-encoded ECDSA keys are only 91 bytes
each but were each allocated 294 bytes instead. Reducing the size of
these buffers saves 609 bytes of BSS in BL2 (294 - 91 = 203 bytes for
each of the 3 key buffers in use).
Also add a comment claryfing that key buffers are tailored on RSA key
sizes when both ECDSA and RSA keys are used.
Change-Id: Iad332856e7af1f9814418d012fba3e1e9399f72a
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Introduce the Firmware CONfiguration Framework (fconf).
The fconf is an abstraction layer for platform specific data, allowing
a "property" to be queried and a value retrieved without the requesting
entity knowing what backing store is being used to hold the data.
The default backing store used is C structure. If another backing store
has to be used, the platform integrator needs to provide a "populate()"
function to fill the corresponding C structure.
The "populate()" function must be registered to the fconf framework with
the "FCONF_REGISTER_POPULATOR()". This ensures that the function would
be called inside the "fconf_populate()" function.
A two level macro is used as getter:
- the first macro takes 3 parameters and converts it to a function
call: FCONF_GET_PROPERTY(a,b,c) -> a__b_getter(c).
- the second level defines a__b_getter(c) to the matching C structure,
variable, array, function, etc..
Ex: Get a Chain of trust property:
1) FCONF_GET_PROPERY(tbbr, cot, BL2_id) -> tbbr__cot_getter(BL2_id)
2) tbbr__cot_getter(BL2_id) -> cot_desc_ptr[BL2_id]
Change-Id: Id394001353ed295bc680c3f543af0cf8da549469
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
This patch adds 'calc_hash' function using Mbed TLS library
required for Measured Boot support.
Change-Id: Ifc5aee0162d04db58ec6391e0726a526f29a52bb
Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
In further patches, we wish to enable -wredundant-decls check as
part of warning flags by default.
Change-Id: I43410d6dbf40361a503c16d94ccf0f4cf29615b7
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
Add the support needed to enable using CryptoCell integration with
with RSA 3K support.
Signed-off-by: Gilad Ben-Yossef <gilad.benyossef@arm.com>
Change-Id: I95527cb0c41ae012109e8968dd20a4ae9fe67f17
Support for PKCS#1 v1.5 was deprecated in SHA 1001202 and fully removed
in SHA fe199e3, however, cert_tool is still able to generate
certificates in that form. This patch fully removes the ability for
cert_tool to generate these certificates.
Additionally, this patch also fixes a bug where the issuing certificate
was a RSA and the issued certificate was EcDSA. In this case, the issued
certificate would be signed using PKCS#1 v1.5 instead of RSAPSS per
PKCS#1 v2.1, preventing TF-A from verifying the image signatures. Now
that PKCS#1 v1.5 support is removed, all certificates that are signed
with RSA now use the more modern padding scheme.
Change-Id: Id87d7d915be594a1876a73080528d968e65c4e9a
Signed-off-by: Justin Chadwell <justin.chadwell@arm.com>
Previously, TF-A could not support large RSA key sizes as the
configuration options passed to MBEDTLS prevented storing and performing
calculations with the larger, higher-precision numbers required. With
these changes to the arguments passed to MBEDTLS, TF-A now supports
using 3072 (3K) and 4096 (4K) keys in certificates.
Change-Id: Ib73a6773145d2faa25c28d04f9a42e86f2fd555f
Signed-off-by: Justin Chadwell <justin.chadwell@arm.com>
Add support for multiple Cryptocell revisions which
use different APIs.
This commit only refactors the existing code in preperation to the addition
of another Cryptocell revisions later on.
Signed-off-by: Gilad Ben-Yossef <gilad.benyossef@arm.com>
Change-Id: I16d80b31afb6edd56dc645fee5ea619cc74f09b6
Code using Cryptocell specific APIs was used as part of the
arm common board ROT support, instead of being abstracted
in Cryptocell specific driver code, creating two problems:
- Any none arm board that uses Cryptocell wuld need to
copy and paste the same code.
- Inability to cleanly support multiple versions of Cryptocell
API and products.
Move over Cryptocell specific API calls into the Cryptocell
driver, creating abstraction API where needed.
Signed-off-by: Gilad Ben-Yossef <gilad.benyossef@arm.com>
Change-Id: I9e03ddce90fcc47cfdc747098bece86dbd11c58e
The chain of trust description and the pointer pointing to its first
element were incompatible, thus requiring an explicit type cast for
the assignment.
- cot_desc was an array of
const pointers to const image descriptors.
- cot_desc_ptr was a const pointer to
(non-constant) pointers to const image descriptors.
Thus, trying to assign cot_desc to cot_desc_ptr (with no cast) would
generate the following compiler warning:
drivers/auth/tbbr/tbbr_cot.c:826:14: warning: initialization discards
‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
REGISTER_COT(cot_desc);
^~~~~~~~
Change-Id: Iae62dd1bdb43fe379e3843d96461d47cc2f68a06
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
The implementation of the heap function plat_get_mbedtls_heap() becomes
mandatory for platforms supporting TRUSTED_BOARD_BOOT.
The shared Mbed TLS heap default weak function implementation is
converted to a helper function get_mbedtls_heap_helper() which can be
used by the platforms for their own function implementation.
Change-Id: Ic8f2994e25e3d9fcd371a21ac459fdcafe07433e
Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com>
This changes the auth_img_desc_t struct to have pointers to struct
arrays instead of struct arrays. This saves memory as many of these
were never used, and can be NULL pointers. Note the memory savings are
only when these arrays are not initialised, as it is assumed these
arrays are fixed length. A possible future optimisation could allow for
variable length.
memory diff:
bl1: bl2:
text text
-12 -12
bss bss
-1463 0
data data
-56 -48
rodata rodata
-5688 -2592
total total
-7419 -2652
Change-Id: I8f9bdedf75048b8867f40c56381e3a6dc6402bcc
Signed-off-by: Joel Hutton <Joel.Hutton@Arm.com>
When Trusted Board Boot is enabled, we need to specify the Chain of
Trust (CoT) of the BL1 and BL2 images. A CoT consists of an array
of image descriptors. The authentication module assumes that each
image descriptor in this array is indexed by its unique image
identifier. For example, the Trusted Boot Firmware Certificate has to
be at index [TRUSTED_BOOT_FW_CERT_ID].
Unique image identifiers may not necessarily be consecutive. Also,
a given BL image might not use all image descriptors. For example, BL1
does not need any of the descriptors related to BL31. As a result, the
CoT array might contain holes, which unnecessarily takes up space in
the BL binary.
Using pointers to auth_img_desc_t structs (rather than structs
themselves) means these unused elements only use 1 pointer worth of
space, rather than one struct worth of space. This patch also changes
the code which accesses this array to reflect the change to pointers.
Image descriptors not needed in BL1 or BL2 respectively are also
ifdef'd out in this patch. For example, verifying the BL31 image is
the responsibility of BL2 so BL1 does not need any of the data
structures describing BL31.
memory diff:
bl1: bl2:
text text
-20 -20
bss bss
-1463 0
data data
-256 -48
rodata rodata
-5240 -1952
total total
-6979 -2020
Change-Id: I163668b174dc2b9bbb183acec817f2126864aaad
Signed-off-by: Joel Hutton <Joel.Hutton@Arm.com>
Improved support for W=2 compilation flag by solving some nested-extern
and sign-compare warnings.
The libraries are compiling with warnings (which turn into errors with
the Werror flag).
Outside of libraries, some warnings cannot be fixed.
Change-Id: I06b1923857f2a6a50e93d62d0274915b268cef05
Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com>
Due to the shared Mbed TLS heap optimisation introduced in 6d01a463,
common code files were depending on Mbed TLS specific headers. This
dependency is now removed by moving the default, unoptimised heap
implementation inside the Mbed TLS specific files.
Change-Id: I11ea3eb4474f0d9b6cb79a2afd73a51a4a9b8994
Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
Enforce full include path for includes. Deprecate old paths.
The following folders inside include/lib have been left unchanged:
- include/lib/cpus/${ARCH}
- include/lib/el3_runtime/${ARCH}
The reason for this change is that having a global namespace for
includes isn't a good idea. It defeats one of the advantages of having
folders and it introduces problems that are sometimes subtle (because
you may not know the header you are actually including if there are two
of them).
For example, this patch had to be created because two headers were
called the same way: e0ea0928d5 ("Fix gpio includes of mt8173 platform
to avoid collision."). More recently, this patch has had similar
problems: 46f9b2c3a2 ("drivers: add tzc380 support").
This problem was introduced in commit 4ecca33988 ("Move include and
source files to logical locations"). At that time, there weren't too
many headers so it wasn't a real issue. However, time has shown that
this creates problems.
Platforms that want to preserve the way they include headers may add the
removed paths to PLAT_INCLUDES, but this is discouraged.
Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
