On Juno, the secure privileged invasive debug authentication signal
(SPIDEN) is controlled by board SCC registers, which by default enable
SPIDEN. Disable secure privileged external debug in release builds by
programming the appropriate Juno SoC registers.
Change-Id: I61045f09a47dc647bbe95e1b7a60e768f5499f49
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
This patch introduces the following three platform interfaces:
* void plat_psci_stat_accounting_start(const psci_power_state_t *state_info)
This is an optional hook that platforms can implement in order
to perform accounting before entering a low power state. This
typically involves capturing a timestamp.
* void plat_psci_stat_accounting_stop(const psci_power_state_t *state_info)
This is an optional hook that platforms can implement in order
to perform accounting after exiting from a low power state. This
typically involves capturing a timestamp.
* u_register_t plat_psci_stat_get_residency(unsigned int lvl,
const psci_power_state_t *state_info,
unsigned int last_cpu_index)
This is an optional hook that platforms can implement in order
to calculate the PSCI stat residency.
If any of these interfaces are overridden by the platform, it is
recommended that all of them are.
By default `ENABLE_PSCI_STAT` is disabled. If `ENABLE_PSCI_STAT`
is set but `ENABLE_PMF` is not set then an alternative PSCI stat
collection backend must be provided. If both are set, then default
weak definitions of these functions are provided, using PMF to
calculate the residency.
NOTE: Previously, platforms did not have to explicitly set
`ENABLE_PMF` since this was automatically done by the top-level
Makefile.
Change-Id: I17b47804dea68c77bc284df15ee1ccd66bc4b79b
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
Replace all use of memset by zeromem when zeroing moderately-sized
structure by applying the following transformation:
memset(x, 0, sizeof(x)) => zeromem(x, sizeof(x))
As the Trusted Firmware is compiled with -ffreestanding, it forbids the
compiler from using __builtin_memset and forces it to generate calls to
the slow memset implementation. Zeromem is a near drop in replacement
for this use case, with a more efficient implementation on both AArch32
and AArch64.
Change-Id: Ia7f3a90e888b96d056881be09f0b4d65b41aa79e
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
Introduce zeromem_dczva function on AArch64 that can handle unaligned
addresses and make use of DC ZVA instruction to zero a whole block at a
time. This zeroing takes place directly in the cache to speed it up
without doing external memory access.
Remove the zeromem16 function on AArch64 and replace it with an alias to
zeromem. This zeromem16 function is now deprecated.
Remove the 16-bytes alignment constraint on __BSS_START__ in
firmware-design.md as it is now not mandatory anymore (it used to comply
with zeromem16 requirements).
Change the 16-bytes alignment constraints in SP min's linker script to a
8-bytes alignment constraint as the AArch32 zeromem implementation is now
more efficient on 8-bytes aligned addresses.
Introduce zero_normalmem and zeromem helpers in platform agnostic header
that are implemented this way:
* AArch32:
* zero_normalmem: zero using usual data access
* zeromem: alias for zero_normalmem
* AArch64:
* zero_normalmem: zero normal memory using DC ZVA instruction
(needs MMU enabled)
* zeromem: zero using usual data access
Usage guidelines: in most cases, zero_normalmem should be preferred.
There are 2 scenarios where zeromem (or memset) must be used instead:
* Code that must run with MMU disabled (which means all memory is
considered device memory for data accesses).
* Code that fills device memory with null bytes.
Optionally, the following rule can be applied if performance is
important:
* Code zeroing small areas (few bytes) that are not secrets should use
memset to take advantage of compiler optimizations.
Note: Code zeroing security-related critical information should use
zero_normalmem/zeromem instead of memset to avoid removal by
compilers' optimizations in some cases or misbehaving versions of GCC.
FixesARM-software/tf-issues#408
Change-Id: Iafd9663fc1070413c3e1904e54091cf60effaa82
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
With GCC 6.2 compiler, more C undefined behaviour is being flagged as
warnings, which result in build errors in ARM TF build.
The specific issue that this patch resolves is the use of (1 << 31),
which is predominantly used in case statements, where 1 is represented
as a signed int. When shifted to msb the behaviour is undefined.
The resolution is to specify 1 as an unsigned int using a convenience
macro ULL(). A duplicate macro MAKE_ULL() is replaced.
FixesARM-software/tf-issues#438
Change-Id: I08e3053bbcf4c022ee2be33a75bd0056da4073e1
Signed-off-by: David Cunado <david.cunado@arm.com>
One nasty part of ATF is some of boolean macros are always defined
as 1 or 0, and the rest of them are only defined under certain
conditions.
For the former group, "#if FOO" or "#if !FOO" must be used because
"#ifdef FOO" is always true. (Options passed by $(call add_define,)
are the cases.)
For the latter, "#ifdef FOO" or "#ifndef FOO" should be used because
checking the value of an undefined macro is strange.
For AARCH32/AARCH64, these macros are defined in the top-level
Makefile as follows:
ifeq (${ARCH},aarch32)
$(eval $(call add_define,AARCH32))
else
$(eval $(call add_define,AARCH64))
endif
This means only one of the two is defined. So, AARCH32/AARCH64
belongs to the latter group where we should use #ifdef or #ifndef.
The conditionals are mostly coded correctly, but I see some mistakes.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
One nasty part of ATF is some of boolean macros are always defined
as 1 or 0, and the rest of them are only defined under certain
conditions.
For the former group, "#if FOO" or "#if !FOO" must be used because
"#ifdef FOO" is always true. (Options passed by $(call add_define,)
are the cases.)
For the latter, "#ifdef FOO" or "#ifndef FOO" should be used because
checking the value of an undefined macro is strange.
Here, IMAGE_BL* is handled by make_helpers/build_macro.mk like
follows:
$(eval IMAGE := IMAGE_BL$(call uppercase,$(3)))
$(OBJ): $(2)
@echo " CC $$<"
$$(Q)$$(CC) $$(TF_CFLAGS) $$(CFLAGS) -D$(IMAGE) -c $$< -o $$@
This means, IMAGE_BL* is defined when building the corresponding
image, but *undefined* for the other images.
So, IMAGE_BL* belongs to the latter group where we should use #ifdef
or #ifndef.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
We have lots of duplicated defines (and comment blocks too).
Move them to include/plat/common/common_def.h.
While we are here, suffix the end address with _END instead of
_LIMIT. The _END is a better fit to indicate the linker-derived
real end address.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The usage of _LIMIT seems odd here, so rename as follows:
BL_CODE_LIMIT --> BL_CODE_END
BL_RO_DATA_LIMIT --> BL_RO_DATA_END
BL1_CODE_LIMIT --> BL1_CODE_END
BL1_RO_DATA_LIMIT --> BL1_RO_DATA_END
Basically, we want to use _LIMIT and _END properly as follows:
*_SIZE + *_MAX_SIZE = *_LIMIT
*_SIZE + *_SIZE = *_END
The _LIMIT is generally defined by platform_def.h to indicate the
platform-dependent memory constraint. So, its typical usage is
ASSERT(. <= BL31_LIMIT, "BL31 image has exceeded its limit.")
in a linker script.
On the other hand, _END is used to indicate the end address of the
compiled image, i.e. we do not know it until the image is linked.
Here, all of these macros belong to the latter, so should be
suffixed with _END.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
We are duplicating this macro define, and it is useful enough
to be placed in the common place.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Commit 0029624fe2 ("Add
PLAT_xxx_ADDR_SPACE_SIZE definition") deprecates 'ADDR_SPACE_SIZE' in
favor of PLAT_(PHY|VIRT)_ADDRESS_SPACE_SIZE. Migrate the zynqmp platform
to use the new interface.
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Depending on the compiler used, it might try to link in libc even though
it's not required. Stop it from doing that.
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
The platform.mk sets build options required for ZynqMP, but users
can still change them from the command line, like:
make PLAT=zynqmp RESET_TO_BL31=0 CROSS_COMPILE=...
Then, the makefile shows an error message in that case:
Using BL31 as the reset vector is only one option supported on ZynqMP.
Please set RESET_TO_BL31 to 1.
If the option is not user-configurable, the makefile can specify
"override" to prevent users from changing it. We do not need the
error message for the case that never happens.
Likewise, ENABLE_PLAT_COMPAT := 0 and PROGRAMMABLE_RESET_ADDRESS := 1
are mandatory to avoid build error.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Before adding a base address and a size to compute the end
address of an image to copy or authenticate, check this
won't result in an integer overflow. If it does then consider
the input arguments are invalid.
As a result, bl1_plat_mem_check() can now safely assume the
end address (computed as the sum of the base address and size
of the memory region) doesn't overflow, as the validation is
done upfront in bl1_fwu_image_copy/auth(). A debug assertion
has been added nonetheless in the ARM implementation in order
to help catching such problems, should bl1_plat_mem_check()
be called in a different context in the future.
Fixes TFV-1: Malformed Firmware Update SMC can result in copy
of unexpectedly large data into secure memory
Change-Id: I8b8f8dd4c8777705722c7bd0e8b57addcba07e25
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Signed-off-by: Dan Handley <dan.handley@arm.com>
ASM_ASSERT failure and panic messages are suppressed at present. This
patch enables printing the PC location for panic messages, and file name
and line number upon assembly assert failure.
Change-Id: I80cb715988e7ce766f64da1e1d7065a74a096a0c
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
The previous code required that a certificate be signed with the ROT
key before the platform's NV counter could be updated with the value
in the certificate. This implies that the Non-Trusted NV counter was
not being updated for Non-Trusted content certificates, as they cannot
be signed with the ROT key in the TBBR CoT scheme.
The code is reworked to only allow updating the platform's Trusted NV
counter when a certificate protected by the Trusted NV counter is
signed with the ROT key.
Content certificates protected by the Non-Trusted NV counter are
allowed to update the platform's Non-Trusted NV counter, assuming
that the certificate value is higher than the platform's value.
A new optional platform API has been introduced, named
plat_set_nv_ctr2(). Platforms may choose to implement it and perform
additional checks based on the authentication image descriptor before
modifying the NV counters. A default weak implementation is available
that just calls into plat_set_nv_ctr().
FixesARM-software/tf-issues#426
Change-Id: I4fc978fd28a3007bc0cef972ff1f69ad0413b79c
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
Earlier patches introduced GIC Redistributor power management for ARM
platforms. This patch modifies FVP power management to power down
Redistributor during CPU power on/off.
Change-Id: I2adb9c50a7dd750019fe3b4e576b5d5fc364bffb
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
As with other ARM platform GIC APIs, these directly invoke the GICv3
driver APIs for Redistributor power management.
For the sake of uniform GIC API, empty stubs are placed for those GIC
drivers that lack Redistributor component.
Change-Id: Iad0d760d4dbca790998f7768cda621ff3b15a864
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
This patch enables TRUSTED_BOARD_BOOT (Authentication and FWU)
support, for AArch64, when LOAD_IMAGE_V2 is enabled.
This patch also enables LOAD_IMAGE_V2 for ARM platforms.
Change-Id: I294a2eebce7a30b6784c80c9d4ac7752808ee3ad
Signed-off-by: Yatharth Kochar <yatharth.kochar@arm.com>
Some files have incorrect copyright notices, this patch fixes all
files with deviations from the standard notice.
Change-Id: I66b73e78a50a235acb55f1e2ec2052a42c0570d2
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
The capabilities exposed by the PSCI generic layer depends on the hooks
populated by the platform in `plat_arm_psci_pm_ops`. Currently ARM
Standard platforms statically define this structure. However, some
platforms may want to modify the hooks at runtime before registering
them with the generic layer.
This patch introduces a new ARM platform layer API
`plat_arm_psci_override_pm_ops` which allows the platform to probe
the power controller and modify `plat_arm_psci_pm_ops` if required.
Consequently, 'plat_arm_psci_pm_ops' is no longer qualified as
`const` on ARM Standard platforms.
Change-Id: I7dbb44b7bd36c20ec14ded5ee45a96816ca2ab9d
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
This patch introduces an additional layer of abstraction between
CSS power management hooks and the SCPI driver. A new set of APIs
are introduced in order to abstract out power management operations
from underlying communication mechanism with the SCP.
The SCPI and the associated MHU drivers are moved into a `drivers`
folder in CSS. The new SCP communication abstraction layer is added
in the `drivers/scp` folder. The existing CSS power management
uses the new APIs to reflect this abstraction.
Change-Id: I7d775129fc0558e9703c2724523fb8f0a916838c
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
There are many instances in ARM Trusted Firmware where control is
transferred to functions from which return isn't expected. Such jumps
are made using 'bl' instruction to provide the callee with the location
from which it was jumped to. Additionally, debuggers infer the caller by
examining where 'lr' register points to. If a 'bl' of the nature
described above falls at the end of an assembly function, 'lr' will be
left pointing to a location outside of the function range. This misleads
the debugger back trace.
This patch defines a 'no_ret' macro to be used when jumping to functions
from which return isn't expected. The macro ensures to use 'bl'
instruction for the jump, and also, for debug builds, places a 'nop'
instruction immediately thereafter (unless instructed otherwise) so as
to leave 'lr' pointing within the function range.
Change-Id: Ib34c69fc09197cfd57bc06e147cc8252910e01b0
Co-authored-by: Douglas Raillard <douglas.raillard@arm.com>
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
This patch makes following miscellaneous fixes:
* pl011_console.S: Fixed the bit mask used to check if the
transmit FIFO is full or empty.
* smcc_macros.S: Added `_fsxc` suffix while updating the SPSR.
By default the assembler assumes `_fc` suffix which does not
update all the fields in SPSR. By adding `_fsxc` suffix all
the fields gets updated.
* platform_helpers.S: Removed the weak definition for
`plat_my_core_pos()` as this is a mandatory function which
needs to be defined by all platforms.
Change-Id: I8302292533c943686fff8d7c749a07132c052a3b
Signed-off-by: Yatharth Kochar <yatharth.kochar@arm.com>
Commit b91d935fee
("Add CFI debug frame information for ASM functions") modifies the
assembly macros 'func' and 'endfunc' to include CFI debug frame
information.
The rockchip platform uses a custom version of the 'func' macro with the
common 'endfunc' macro. The custom macro wasn't updated in
b91d935fee resulting in the following
build error:
plat/rockchip/rk3399/drivers/pmu/plat_pmu_macros.S: Assembler messages:
plat/rockchip/rk3399/drivers/pmu/plat_pmu_macros.S:155: Error: .cfi_endproc without corresponding .cfi_startproc
Makefile:532: recipe for target 'build/rk3399/release/bl31/plat_helpers.o' failed
make: *** [build/rk3399/release/bl31/plat_helpers.o] Error 1
Fixing this by updating the sram_func macro in the rk3399 port.
Fixes: b91d935fee ("Add CFI debug frame information for ASM functions")
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Add dependency information in the user guide for ARM_RECOM_STATE_ID_ENC
that needs to be set when using PSCI_EXTENDED_STATE_ID on ARM
platforms. Also clarify the build error message.
Change-Id: Id125a0299b179f5f222bca4e2503204bf89a3c59
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
The callback IRQ is delivered to the NS OS. Provide an interface to
allow the NS OS to obtain the callback data from the secure HW.
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
The IPI hardware is secure and managed by ATF, nevertheless we deliver
the IRQ to the rich OS. The IRQ is needed to receive PM callbacks.
Enable the IPI interrupt when the rich OS probes the API version.
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>