fix(smccc): properly set RAS feature bit

The SCR_EL3.TERR bit controls trapping accesses to the RAS CPU system
registers, like ERRIDR_EL1. Those are part of RAS CPU extension, and
exist and can be a

fix(smccc): properly set RAS feature bit

The SCR_EL3.TERR bit controls trapping accesses to the RAS CPU system
registers, like ERRIDR_EL1. Those are part of RAS CPU extension, and
exist and can be accessed independently of the rest of the system's RAS
implementation status, BL31's RAS handling capabilities, or the way RAS
errors are routed by the firmware (FFH vs. KFH handling).
Tie the SCR_EL3.TERR bit to the right build symbol, since TF-A's
capability to handle RAS errors has nothing to do with lower EL's
accesses to those CPU system registers.

Change-Id: I4f06f915c0815c80058ec365139a8d818ba85721
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

feat(smccc): add FEAT_TWED to ARCH_FEATURE_AVAILABILITY

FEAT_TWED (Delayed Trapping of WFE) is an ARMv8.6 feature that is
advertised in the ID_AA64MMFR1_EL1 ID register and controlled by a bit
in th

feat(smccc): add FEAT_TWED to ARCH_FEATURE_AVAILABILITY

FEAT_TWED (Delayed Trapping of WFE) is an ARMv8.6 feature that is
advertised in the ID_AA64MMFR1_EL1 ID register and controlled by a bit
in the SCR_EL3 register.

On cores implementing that feature we should announce it in the
ARCH_FEATURE_AVAILABILITY SMCCC call, so that users of that interface
can correctly assess the availability of the delayed trap.

Change-Id: I2b185f7eb9d58e45472983204db0305511372477
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

feat(cpufeat): add support for PMUv3p9

Armv8.9 introduced the FEAT_PMUV3P9 extension, which allows finer
grained control over EL0 usage of PMU registers. This is controlled by
the new PMUACR_EL1 sys

feat(cpufeat): add support for PMUv3p9

Armv8.9 introduced the FEAT_PMUV3P9 extension, which allows finer
grained control over EL0 usage of PMU registers. This is controlled by
the new PMUACR_EL1 system register, access to which is guarded by the
MDCR_EL3.EnPM2 bit. We should set this bit to avoid a trap into EL3 when
lower ELs access this register.

Add the required bits and pieces to make this feature usable:
- Add the CPUID and MDCR_EL3 bit definitions associated with
FEAT_PMUV3P9.
- Extend the existing PMU feature check to allow v9 now as well. This
is fine since we don't context switch PMU registers at all, so we
don't need to do much except to flip the MDCR bit:
- Set the EnPM2 bit in pmuv3_enable, so the feature is usuable in
non-secure world (and there only).
- Handle the MDCR bit for the ARCH_FEATURE_AVAILABILITY feature.

Please note that MDCR_EL3.EnPM2 guards other system registers as well,
for other PMU related new architecture features.

Change-Id: I288ca15f5c9efd336c64477d1c6fe9543613e238
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

Merge "feat(rmmd): add FEAT_MEC support" into integration

feat(rmmd): add FEAT_MEC support

This patch provides architectural support for further use of
Memory Encryption Contexts (MEC) by declaring the necessary
registers, bits, masks, helpers and values a

feat(rmmd): add FEAT_MEC support

This patch provides architectural support for further use of
Memory Encryption Contexts (MEC) by declaring the necessary
registers, bits, masks, helpers and values and modifying the
necessary registers to enable FEAT_MEC.

Signed-off-by: Tushar Khandelwal <tushar.khandelwal@arm.com>
Signed-off-by: Juan Pablo Conde <juanpablo.conde@arm.com>
Change-Id: I670dbfcef46e131dcbf3a0b927467ebf6f438fa4

show more ...

Merge "fix(smccc): register PMUv3p5 and PMUv3p7 bits with the FEATURE_AVAILABILITY call" into integration

fix(smccc): register PMUv3p5 and PMUv3p7 bits with the FEATURE_AVAILABILITY call

These bits were missed with the original implementation. They are set if
supported, so we need to ignore them.

Chang

fix(smccc): register PMUv3p5 and PMUv3p7 bits with the FEATURE_AVAILABILITY call

These bits were missed with the original implementation. They are set if
supported, so we need to ignore them.

Change-Id: I3a94017bacdc54bfc14f0add972240148da3b41d
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

Merge changes from topic "ar/smccc_arch_wa_4" into integration

* changes:
fix(security): apply SMCCC_ARCH_WORKAROUND_4 to affected cpus
fix(security): add support in cpu_ops for CVE-2024-7881

Merge changes from topic "ar/smccc_arch_wa_4" into integration

* changes:
fix(security): apply SMCCC_ARCH_WORKAROUND_4 to affected cpus
fix(security): add support in cpu_ops for CVE-2024-7881
fix(security): add CVE-2024-7881 mitigation to Cortex-X3
fix(security): add CVE-2024-7881 mitigation to Neoverse-V3
fix(security): add CVE-2024-7881 mitigation to Neoverse-V2
fix(security): add CVE-2024-7881 mitigation to Cortex-X925
fix(security): add CVE-2024-7881 mitigation to Cortex-X4
fix(security): enable WORKAROUND_CVE_2024_7881 build option

show more ...

fix(security): apply SMCCC_ARCH_WORKAROUND_4 to affected cpus

This patch implements SMCCC_ARCH_WORKAROUND_4 and
allows discovery through SMCCC_ARCH_FEATURES.
This mechanism is enabled if CVE_2024_78

fix(security): apply SMCCC_ARCH_WORKAROUND_4 to affected cpus

This patch implements SMCCC_ARCH_WORKAROUND_4 and
allows discovery through SMCCC_ARCH_FEATURES.
This mechanism is enabled if CVE_2024_7881 [1] is enabled
by the platform. If CVE_2024_7881 mitigation
is implemented, the discovery call returns 0,
if not -1 (SMC_ARCH_CALL_NOT_SUPPORTED).

For more information about SMCCC_ARCH_WORKAROUND_4 [2], please
refer to the SMCCC Specification reference provided below.

[1]: https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881
[2]: https://developer.arm.com/documentation/den0028/latest

Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>
Change-Id: I1b1ffaa1f806f07472fd79d5525f81764d99bc79

show more ...

Merge changes from topic "bk/smccc_feature" into integration

* changes:
feat(smccc): implement SMCCC_ARCH_FEATURE_AVAILABILITY
refactor(cm): clean up per-world context
refactor(cm): change own

Merge changes from topic "bk/smccc_feature" into integration

* changes:
feat(smccc): implement SMCCC_ARCH_FEATURE_AVAILABILITY
refactor(cm): clean up per-world context
refactor(cm): change owning security state when a feature is disabled

show more ...

feat(smccc): implement SMCCC_ARCH_FEATURE_AVAILABILITY

SMCCC_ARCH_FEATURE_AVAILABILITY [1] is a call to query firmware about
the features it is aware of and enables. This is useful when a feature
is

feat(smccc): implement SMCCC_ARCH_FEATURE_AVAILABILITY

SMCCC_ARCH_FEATURE_AVAILABILITY [1] is a call to query firmware about
the features it is aware of and enables. This is useful when a feature
is not enabled at EL3, eg due to an older FW image, but it is present in
hardware. In those cases, the EL1 ID registers do not reflect the usable
feature set and this call should provide the necessary information to
remedy that.

The call itself is very lightweight - effectively a sanitised read of
the relevant system register. Bits that are not relevant to feature
enablement are masked out and active low bits are converted to active
high.

The implementation is also very simple. All relevant, irrelevant, and
inverted bits combined into bitmasks at build time. Then at runtime the
masks are unconditionally applied to produce the right result. This
assumes that context managers will make sure that disabled features
do not have their bits set and the registers are context switched if
any fields in them make enablement ambiguous.

Features that are not yet supported in TF-A have not been added. On
debug builds, calling this function will fail an assert if any bits that
are not expected are set. In combination with CI this should allow for
this feature to to stay up to date as new architectural features are
added.

If a call for MPAM3_EL3 is made when MPAM is not enabled, the call
will return INVALID_PARAM, while if it is FEAT_STATE_CHECK, it will
return zero. This should be fairly consistent with feature detection.

The bitmask is meant to be interpreted as the logical AND of the
relevant ID registers. It would be permissible for this to return 1
while the ID returns 0. Despite this, this implementation takes steps
not to. In the general case, the two should match exactly.

Finally, it is not entirely clear whether this call replies to SMC32
requests. However, it will not, as the return values are all 64 bits.

[1]: https://developer.arm.com/documentation/den0028/galp1/?lang=en

Co-developed-by: Charlie Bareham <charlie.bareham@arm.com>
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: I1a74e7d0b3459b1396961b8fa27f84e3f0ad6a6f

show more ...

Merge changes from topic "spectre_bhb" into integration

* changes:
fix(security): apply SMCCC_ARCH_WORKAROUND_3 to A73/A75/A72/A57
fix(security): workaround for CVE-2022-23960 for Cortex-A57, Co

Merge changes from topic "spectre_bhb" into integration

* changes:
fix(security): apply SMCCC_ARCH_WORKAROUND_3 to A73/A75/A72/A57
fix(security): workaround for CVE-2022-23960 for Cortex-A57, Cortex-A72
fix(fvp): disable reclaiming init code by default

show more ...

fix(security): apply SMCCC_ARCH_WORKAROUND_3 to A73/A75/A72/A57

This patch applies CVE-2022-23960 workarounds for Cortex-A75,
Cortex-A73, Cortex-A72 & Cortex-A57. This patch also implements
the new

fix(security): apply SMCCC_ARCH_WORKAROUND_3 to A73/A75/A72/A57

This patch applies CVE-2022-23960 workarounds for Cortex-A75,
Cortex-A73, Cortex-A72 & Cortex-A57. This patch also implements
the new SMCCC_ARCH_WORKAROUND_3 and enables necessary discovery
hooks for Coxtex-A72, Cortex-A57, Cortex-A73 and Cortex-A75 to
enable discovery of this SMC via SMC_FEATURES. SMCCC_ARCH_WORKAROUND_3
is implemented for A57/A72 because some revisions are affected by both
CVE-2022-23960 and CVE-2017-5715 and this allows callers to replace
SMCCC_ARCH_WORKAROUND_1 calls with SMCCC_ARCH_WORKAROUND_3. For details
of SMCCC_ARCH_WORKAROUND_3, please refer SMCCCv1.4 specification.

Signed-off-by: Bipin Ravi <bipin.ravi@arm.com>
Signed-off-by: John Powell <john.powell@arm.com>
Change-Id: Ifa6d9c7baa6764924638efe3c70468f98d60ed7c

show more ...

Merge "Implement SMCCC_ARCH_SOC_ID SMC call" into integration

Implement SMCCC_ARCH_SOC_ID SMC call

Implemented SMCCC_ARCH_SOC_ID call in order to get below
SOC information:

1. SOC revision
2. SOC version

Implementation done using below SMCCC specification do

Implement SMCCC_ARCH_SOC_ID SMC call

Implemented SMCCC_ARCH_SOC_ID call in order to get below
SOC information:

1. SOC revision
2. SOC version

Implementation done using below SMCCC specification document:
https://developer.arm.com/docs/den0028/c

Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: Ie0595f1c345a6429a6fb4a7f05534a0ca9c9a48b

show more ...

Merge "Use consistent SMCCC error code" into integration

Use consistent SMCCC error code

Removed duplicate error code present for SMCCC and used
proper error code for "SMCCC_ARCH_WORKAROUND_2" call.

Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.c

Use consistent SMCCC error code

Removed duplicate error code present for SMCCC and used
proper error code for "SMCCC_ARCH_WORKAROUND_2" call.

Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: I76fc7c88095f78a7e2c3d205838f8eaf3132ed5c

show more ...

Merge pull request #1673 from antonio-nino-diaz-arm/an/headers

Standardise header guards across codebase

Standardise header guards across codebase

All identifiers, regardless of use, that start with two underscores are
reserved. This means they can't be used in header guards.

The style that this proje

Standardise header guards across codebase

All identifiers, regardless of use, that start with two underscores are
reserved. This means they can't be used in header guards.

The style that this project is now to use the full name of the file in
capital letters followed by 'H'. For example, for a file called
"uart_example.h", the header guard is UART_EXAMPLE_H.

The exceptions are files that are imported from other projects:

- CryptoCell driver
- dt-bindings folders
- zlib headers

Change-Id: I50561bf6c88b491ec440d0c8385c74650f3c106e
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

show more ...

Merge pull request #1392 from dp-arm/dp/cve_2018_3639

Implement workaround for CVE-2018-3639 on Cortex A57/A72/A73 and A75

Implement static workaround for CVE-2018-3639

For affected CPUs, this approach enables the mitigation during EL3
initialization, following every PE reset. No mechanism is provided to
disable the mit

Implement static workaround for CVE-2018-3639

For affected CPUs, this approach enables the mitigation during EL3
initialization, following every PE reset. No mechanism is provided to
disable the mitigation at runtime.

This approach permanently mitigates the entire software stack and no
additional mitigation code is required in other software components.

TF-A implements this approach for the following affected CPUs:

* Cortex-A57 and Cortex-A72, by setting bit 55 (Disable load pass store) of
`CPUACTLR_EL1` (`S3_1_C15_C2_0`).

* Cortex-A73, by setting bit 3 of `S3_0_C15_C0_0` (not documented in the
Technical Reference Manual (TRM)).

* Cortex-A75, by setting bit 35 (reserved in TRM) of `CPUACTLR_EL1`
(`S3_0_C15_C1_0`).

Additionally, a new SMC interface is implemented to allow software
executing in lower ELs to discover whether the system is mitigated
against CVE-2018-3639.

Refer to "Firmware interfaces for mitigating cache speculation
vulnerabilities System Software on Arm Systems"[0] for more
information.

[0] https://developer.arm.com/cache-speculation-vulnerability-firmware-specification

Change-Id: I084aa7c3bc7c26bf2df2248301270f77bed22ceb
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>

show more ...

Merge pull request #1240 from dp-arm/dp/smccc

Implement support for SMCCC v1.1 and optimize security mitigations for CVE-2017-5715 on AArch64

Implement support for SMCCC v1.1

SMCCC v1.1 comes with a relaxed calling convention for AArch64
callers. The caller only needs to save x0-x3 before doing an SMC
call.

This patch adds support for S

Implement support for SMCCC v1.1

SMCCC v1.1 comes with a relaxed calling convention for AArch64
callers. The caller only needs to save x0-x3 before doing an SMC
call.

This patch adds support for SMCCC_VERSION and SMCCC_ARCH_FEATURES.

Refer to "Firmware Interfaces for mitigating CVE_2017_5715 System
Software on Arm Systems"[0] for more information.

[0] https://developer.arm.com/-/media/developer/pdf/ARM%20DEN%200070A%20Firmware%20interfaces%20for%20mitigating%20CVE-2017-5715_V1.0.pdf

Change-Id: If5b1c55c17d6c5c7cb9c2c3ed355d3a91cdad0a9
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>

show more ...