| b10d4499 | 16-Feb-2017 |
Jeenu Viswambharan <jeenu.viswambharan@arm.com> |
Introduce ARM SiP service to switch execution state
In AArch64, privileged exception levels control the execution state
(a.k.a. register width) of the immediate lower Exception Level; i.e.
whether t
Introduce ARM SiP service to switch execution state
In AArch64, privileged exception levels control the execution state
(a.k.a. register width) of the immediate lower Exception Level; i.e.
whether the lower exception level executes in AArch64 or AArch32 state.
For an exception level to have its execution state changed at run time,
it must request the change by raising a synchronous exception to the
higher exception level.
This patch implements and adds such a provision to the ARM SiP service,
by which an immediate lower exception level can request to switch its
execution state. The execution state is switched if the request is:
- raised from non-secure world;
- raised on the primary CPU, before any secondaries are brought online
with CPU_ON PSCI call;
- raised from an exception level immediately below EL3: EL2, if
implemented; otherwise NS EL1.
If successful, the SMC doesn't return to the caller, but to the entry
point supplied with the call. Otherwise, the caller will observe the SMC
returning with STATE_SW_E_DENIED code. If ARM Trusted Firmware is built
for AArch32, the feature is not supported, and the call will always
fail.
For the ARM SiP service:
- Add SMC function IDs for both AArch32 and AArch64;
- Increment the SiP service minor version to 2;
- Adjust the number of supported SiP service calls.
Add documentation for ARM SiP service.
Fixes ARM-software/tf-issues#436
Change-Id: I4347f2d6232e69fbfbe333b340fcd0caed0a4cea
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
show more ...
|
| 6af03f9c | 25-Dec-2016 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Use #ifdef for AARCH32 instead of #if
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 gr
Use #ifdef for AARCH32 instead of #if
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>
show more ...
|
| 3d8256b2 | 25-Dec-2016 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Use #ifdef for IMAGE_BL* instead of #if
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
Use #ifdef for IMAGE_BL* instead of #if
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>
show more ...
|
| ecdc898d | 17-Jan-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
Use *_END instead of *_LIMIT for linker derived end addresses
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
B
Use *_END instead of *_LIMIT for linker derived end addresses
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>
show more ...
|
| 949a52d2 | 11-Nov-2016 |
Sandrine Bailleux <sandrine.bailleux@arm.com> |
Fix integer overflows in BL1 FWU code
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 do
Fix integer overflows in BL1 FWU code
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>
show more ...
|