Our implementation of printf does not support flag format specifiers.
Our previous format specification as a result was causing the integer
values to be omitted. This change updates the formatting to ensure
accurate and complete error messages are displayed.
Change-Id: I80cfb5fd7ff26e44cfad4e06803d9e0912488136
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
Add a function to check whether a transfer list has been initialized
at the input address. If not, initialize a transfer list at the
specified location with the given size. This is to help ensure that we
don't accidently overwrite a transfer list that's been passed from a
previous stage.
Change-Id: Ic5906626df09d3801435488e258490765e8f81eb
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
Implements mitigation for CVE-2024-5660 that affects Cortex-X925
revisions r0p0, r0p1.
The workaround is to disable the hardware page aggregation at
EL3 by setting CPUECTLR_EL1[46] = 1'b1.
Public Documentation:
https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-5660
Change-Id: I9d5a07ca6b89b27d8876f4349eff2af26c962d8a
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>
Implements mitigation for CVE-2024-5660 that affects Cortex-X2
revisions r0p0, r1p0, r2p0, r2p1.
The workaround is to disable the hardware page aggregation at
EL3 by setting CPUECTLR_EL1[46] = 1'b1
Public Documentation:
https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-5660
Change-Id: If28804e154617a39d7d52c40b3a00a14a39df929
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>
Implements mitigation for CVE-2024-5660 that affects Cortex-A77
revisions r0p0, r1p0, r1p1.
The workaround is to disable the hardware page aggregation at
EL3 by setting CPUECTLR_EL1[46] = 1'b1.
Public Documentation:
https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-5660
Change-Id: Ic71b163883ea624e9f2f77deb8b30c69612938b9
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>
Implements mitigation for CVE-2024-5660 that affects Neoverse-V1
revisions r0p0, r1p0, r1p1, r1p2.
The workaround is to disable the hardware page aggregation at
EL3 by setting CPUECTLR_EL1[46] = 1'b1.
Public Documentation:
https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-5660
Change-Id: Ia59452ea38c66b291790956d7f2880bfcd56d45f
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>
Implements mitigation for CVE-2024-5660 that affects Cortex-A78_AE
revisions r0p0, r0p1, r0p2, r0p3.
The workaround is to disable the hardware page aggregation at
EL3 by setting CPUECTLR_EL1[46] = 1'b1.
Public Documentation:
https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-5660
Change-Id: I33ac653fcb45f687fe9ace1c76a3eb2000459751
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>
Implements mitigation for CVE-2024-5660 that affects Cortex-A78C
revisions r0p0, r0p1, r0p2.
The workaround is to disable the hardware page aggregation at
EL3 by setting CPUECTLR_EL1[46] = 1'b1.
Public Documentation:
https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-5660
Change-Id: Ieb8d7b122320d16bf8987a43dc683ca41227beb5
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>
Implements mitigation for CVE-2024-5660 that affects Cortex-A78
revisions r0p0, r1p0, r1p1, r1p2.
The workaround is to disable the hardware page aggregation at
EL3 by setting CPUECTLR_EL1[46] = 1'b1.
Public Documentation:
https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-5660
Change-Id: I4e40388bef814481943b2459fe35dd7267c625a2
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>
Implements mitigation for CVE-2024-5660 that affects Cortex-X1
revisions r0p0, r1p0, r1p1, r1p2.
The workaround is to disable the hardware page aggregation at
EL3 by setting CPUECTLR_EL1[46] = 1'b1.
Public Documentation:
https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-5660
Change-Id: I3124db3980f2786412369a010ca6abbbbaa3b601
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>
Implements mitigation for CVE-2024-5660 that affects Neoverse-N2
revisions r0p0, r0p1, r0p2, r0p3.
The workaround is to disable the hardware page aggregation at
EL3 by setting CPUECTLR_EL1[46] = 1'b1.
This patch implements the erratum mitigation for Neoverse-N2.
Public Documentation:
https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-5660
Change-Id: I2b9dea78771cc159586a03ff563c0ec79591ea64
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>
Implements mitigation for CVE-2024-5660 that affects Cortex-A710
revisions r0p0, r1p0, r2p0, r2p1.
The workaround is to disable the hardware page aggregation at
EL3 by setting CPUECTLR_EL1[46] = 1'b1.
Public Documentation:
https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-5660
Change-Id: I10feea238600dcceaac7bb75a59db7913ca65cf1
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>
Implements mitigation for CVE-2024-5660 that affects Neoverse-V2
revisions r0p0, r0p1, r0p2.
The workaround is to disable the hardware page aggregation at
EL3 by setting CPUECTLR_EL1[46] = 1'b1.
Public Documentation:
https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-5660
Change-Id: If66687add52d16f68ce54fe5433dd3b3f067ee04
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>
Implements mitigation for CVE-2024-5660 that affects Cortex-X3
revisions r0p0, r1p0, r1p1, r1p2.
The workaround is to disable the hardware page aggregation at
EL3 by setting CPUECTLR_EL1[46] = 1'b1.
Public Documentation:
https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-5660
Change-Id: Ibe90313948102ece3469f2cfe3faccc7f4beeabe
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>
Implements mitigation for CVE-2024-5660 that affects Neoverse-V3
revisions r0p0, r0p1.
The workaround is to disable the hardware page aggregation at
EL3 by setting CPUECTLR_EL1[46] = 1'b1.
Public Documentation:
https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-5660
Change-Id: I9ed2590bf1215bf6a692f01dfd351e469ff072f8
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>
Implements mitigation for CVE-2024-5660 that affects Cortex-X4
revisions r0p0, r0p1, r0p2.
The workaround is to disable the hardware page aggregation at
EL3 by setting CPUECTLR_EL1[46] = 1'b1.
Public Documentation:
https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-5660
Change-Id: I378cb4978919cced03e7febc2ad431c572eac72d
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>
This patch fixes a bug which was introduced in commit
3065513 related to improper saving of EL1 context in the
context management library code when using 128-bit
system registers.
Bug explanation:
The function el1_sysregs_context_save still used the normal
macros that read all the system registers related to the EL1
context, which then involved casting them to uint64_t and
eventually writing them to a memory structure. This means that
the context management library was saving EL1-related SYSREG128
registers with the upper 64 bits zeroed out.
Alternative macros had previously been introduced for the EL2
context in the aforementioned commit, but not for EL1.
Some refactoring has also been done as part of this patch:
- Re-added "common" back to write_el2_ctx_common_sysreg128
- Added dummy SYSREG128 macros for cases when some features
are disabled
- Removed some newlines
Change-Id: I15aa2190794ac099a493e5f430220b1c81e1b558
Signed-off-by: Igor Podgainõi <igor.podgainoi@arm.com>
Just like for SPE, we need to synchronize TRBE samples before we change
the context to ensure everything goes where it was intended to. If that
is not done, the in-flight entries might use any piece of now incorrect
context as there are no implicit ordering requirements.
Prior to root context, the buffer drain hooks would have done that. But
now that must happen much earlier. So add a tsb to prepare_el3_entry as
well.
Annoyingly, the barrier can be reordered relative to other instructions
by default (rule RCKVWP). So add an isb after the psb/tsb to assure that
they are ordered, at least as far as context is concerned.
Then, drop the buffer draining hooks. Everything they need to do is
already done by now. There's a notable difference in that there are no
dsb-s now. Since EL3 does not access the buffers or the feature
specific context, we don't need to wait for them to finish.
Finally, drop a stray isb in the context saving macro. It is now
absorbed into root context, but was missed.
Change-Id: I30797a40ac7f91d0bb71ad271a1597e85092ccd5
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
In the chapter about FEAT_SPE (D16.4 specifically) it is stated that
"Sampling is always disabled at EL3". That means that disabling sampling
(writing PMBLIMITR_EL1.E to 0) is redundant and can be removed. The only
reason we save/restore SPE context is because of that disable, so those
can be removed too.
There's the issue of draining the profiling buffer though. No new
samples will have been generated since entering EL3. However, old
samples might still be in-flight. Unless synchronised by a psb csync,
those might be affected by our extensive context mutation. Adding a psb
in prepare_el3_entry should cater for that. Note that prior to the
introduction of root context this was not a problem as context remained
unchanged and the hooks took care of the rest.
Then, the only time we care about the buffer actually making it to
memory is when we exit coherency. On HW_ASSISTED_COHERENCY systems we
don't have to do anything, it should be handled for us. Systems without
it need a dsb to wait for them to complete. There should be one already
in each cpu's powerdown hook which should work.
While on the topic of barriers, the esb barrier is no longer used.
Remove it.
Change-Id: I9736fc7d109702c63e7d403dc9e2a4272828afb2
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
This patch enables support of FEAT_FPMR by enabling access
to FPMR register. It achieves it by setting the EnFPM bit of
SCR_EL3. This feature is currently enabled for NS world only.
Reference:
https://developer.arm.com/documentation/109697/2024_09/
Feature-descriptions/The-Armv9-5-architecture-extension?lang=en
Change-Id: I580c409b9b22f8ead0737502280fb9093a3d5dd2
Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>
Cortex-X4 erratum 2923935 is a Cat B erratum that applies
to all revisions <= r0p1 and is fixed in r0p2.
The workaround is to set CPUACTLR4_EL1[11:10] to 0b11.
SDEN documentation:
https://developer.arm.com/documentation/SDEN-2432808/latest
Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>
Change-Id: I9207802ad479919a7f77c1271019fa2479e076ee
According to Platform Initialization (PI) Specification [1] and
discussion on edk2 mailing list [2],
StandaloneMm shouldn't create Hob but it should be passed from TF-A.
IOW, TF-A should pass boot information via HOB list to initialise
StandaloneMm properly.
And this HOB lists could be delivered via
- SPM_MM: Transfer List according to the firmware handoff spec[3]
- FF-A v1.1 >= : FF-A boot protocol.
This patch introduces a TF-A HOB creation library and
some of definitions which StandaloneMm requires to boot.
Link: https://uefi.org/sites/default/files/resources/PI_Spec_1_6.pdf [1]
Link: https://edk2.groups.io/g/devel/topic/103675962#114283 [2]
Link: https://github.com/FirmwareHandoff/firmware_handoff [3]
Signed-off-by: Levi Yun <yeoreum.yun@arm.com>
Change-Id: I5e0838adce487110206998a8b79bc3adca922cec
According to Platform Initialization (PI) Specification [1] and
Discussion on edk2 mailing list [2],
StandaloneMm shouldn't create Hob but it should be passed from TF-A.
IOW, TF-A should pass boot information via PHIT Hob to initialize
StandaloneMm properly.
This patch modifies Hob creation code from edk2 codebase
so that TF-A could create Hob information properly to boot StandaloneMm
Link: https://uefi.org/sites/default/files/resources/PI_Spec_1_6.pdf [1]
Link: https://edk2.groups.io/g/devel/topic/103675962#114283 [2]
Signed-off-by: Levi Yun <yeoreum.yun@arm.com>
Change-Id: I5e427b620d8006b118b266370bd08d4b0ff56a83
The ROMLIB build currently has a strong dependency on MbedTLS. This
patch has been introduced to remove this dependency, making it more
flexible.
Change-Id: If8c4cc7cf557687f40b235a4b8f931cfb70943fd
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Remove the unused jmptbl.i file. The ROMLIB Makefile expects
platforms to provide the jmptbl according to their requirements.
Change-Id: I2784eaca5061aa77fdd99f7b2b5ef5a1145475e9
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Add basic CPU library code to support the Alto CPU.
Change-Id: I45958be99c4a350a32a9e511d3705fb568b97236
Signed-off-by: Igor Podgainõi <igor.podgainoi@arm.com>
This change modifies the build rules for static libraries so that
individual rules which use those libraries depend directly on the
archive files that are generated, rather than their phony target aliases
and `-lX` link flags.
The goal of this is to clean up Make's view of the dependencies between
files, avoiding phony targets (which do not honour timestamps) making
their way into intermediate dependencies.
Change-Id: I96d655fcd94dc259ffa6e8970b2be7b8c7e11123
Signed-off-by: Chris Kay <chris.kay@arm.com>
Armv8.6 introduced the FEAT_LS64 extension, which provides a 64 *byte*
store instruction. A related instruction is ST64BV0, which will replace
the lowest 32 bits of the data with a value taken from the ACCDATA_EL1
system register (so that EL0 cannot alter them).
Using that ST64BV0 instruction and accessing the ACCDATA_EL1 system
register is guarded by two SCR_EL3 bits, which we should set to avoid a
trap into EL3, when lower ELs use one of those.
Add the required bits and pieces to make this feature usable:
- Add the ENABLE_FEAT_LS64_ACCDATA build option (defaulting to 0).
- Add the CPUID and SCR_EL3 bit definitions associated with FEAT_LS64.
- Add a feature check to check for the existing four variants of the
LS64 feature and detect future extensions.
- Add code to save and restore the ACCDATA_EL1 register on
secure/non-secure context switches.
- Enable the feature with runtime detection for FVP and Arm FPGA.
Please note that the *basic* FEAT_LS64 feature does not feature any trap
bits, it's only the addition of the ACCDATA_EL1 system register that
adds these traps and the SCR_EL3 bits.
Change-Id: Ie3e2ca2d9c4fbbd45c0cc6089accbb825579138a
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
When building with many cores (-j64), there's a good chance that the
rule to make the build directory is getting executed at the same time as
the rule for romlib.ldflags. On my machine, the former is slower,
resulting in romlib_generator.py not being able to write the file as the
directory doesn't exist yet.
Add an explicit dependency on the build directory for the target.
This ensures that we have a build directory before we start putting
stuff in it.
Change-Id: I120b0dc66c692c759ab1046c735be405b41db87c
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Grouped targets are a feature introduced with GNU Make 4.3 which enable
rules with multiple targets to communicate that all of the targets of
that rule are built simultaneously, rather than independently.
For example, without grouped targets the following rule may be executed
twice:
a.txt b.txt:
touch a.txt b.txt
# $ remake -j2 a.txt b.txt
# touch a.txt b.txt
# touch a.txt b.txt
In this example, both `a.txt` and `b.txt` are touched twice, when the
rule should only be executed once. Instead, this rule can use a grouped
target:
a.txt b.txt &:
touch a.txt b.txt
# $ remake -j2 a.txt b.txt
# touch a.txt b.txt
# remake: 'b.txt' is up to date.
In this case, both `a.txt` and `b.txt` are created once only, as Make
now knows that the recipe will create both files.
Note that pattern rules with multiple targets always behave this way.
Previously, we assumed that the grouped target feature was available,
but on systems still packaging Make 4.2, most prominently Ubuntu 20.04,
this is not the case. This change adds a check to ensure that we do not
use grouped targets if they are unavailable.
Change-Id: Ifd9da35421ae11468d7a25d3cbc76f6036921749
Signed-off-by: Chris Kay <chris.kay@arm.com>
This patch disables trapping to EL3 when the FEAT_D128
specific registers are accessed by setting the SCR_EL3.D128En bit.
If FEAT_D128 is implemented, then FEAT_SYSREG128 is implemented.
With FEAT_SYSREG128 certain system registers are treated as 128-bit,
so we should be context saving and restoring 128-bits instead of 64-bit
when FEAT_D128 is enabled.
FEAT_SYSREG128 adds support for MRRS and MSRR instruction which
helps us to read write to 128-bit system register.
Refer to Arm Architecture Manual for further details.
Change the FVP platform to default to handling this as a dynamic option
so the right decision can be made by the code at runtime.
Change-Id: I1a53db5eac29e56c8fbdcd4961ede3abfcb2411a
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Add the basic CPU library code to support Cortex-A720AE.
The overall library code is adapted based on Cortex-A720 code.
Signed-off-by: David Hu <david.hu2@arm.com>
Signed-off-by: Ahmed Azeem <ahmed.azeem@arm.com>
Change-Id: I3d64dc5a3098cc823e656a5ad3ea05cd71598dc6
It used to be the case that a FEAT_RME build could not be built with
FEAT_BRBE support. BRBE doesn't have a 3-world aware disable and
MDCR_EL3 was not context switched to allow for disabling in Realm world.
As of commit 123002f917 MDCR_EL3 is
context switched. Since the flag for BRBE support is
ENABLE_BRBE_FOR_NS, move brbe_enable() to only happen for NS world. The
other worlds will see BRBE disabled and branch recording prohibited.
This allows for a build with both RME and BRBE.
Note that EL2 BRBE registers are not context switched. Further work is
needed if non-NS support is required.
Change-Id: I82f0f08399dcd080902477dc9636bc4541685f89
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Add basic CPU library code to support the Arcadia CPU.
Change-Id: Iecb0634dc6dcb34e9b5fda4902335530d237cc43
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
