- 22 Jan, 2020 1 commit
-
-
Anthony Steinhauser authored
Even though ERET always causes a jump to another address, aarch64 CPUs speculatively execute following instructions as if the ERET instruction was not a jump instruction. The speculative execution does not cross privilege-levels (to the jump target as one would expect), but it continues on the kernel privilege level as if the ERET instruction did not change the control flow - thus execution anything that is accidentally linked after the ERET instruction. Later, the results of this speculative execution are always architecturally discarded, however they can leak data using microarchitectural side channels. This speculative execution is very reliable (seems to be unconditional) and it manages to complete even relatively performance-heavy operations (e.g. multiple dependent fetches from uncached memory). This was fixed in Linux, FreeBSD, OpenBSD and Optee OS: https://github.com/torvalds/linux/commit/679db70801da9fda91d26caf13bf5b5ccc74e8e8 https://github.com/freebsd/freebsd/commit/29fb48ace4186a41c409fde52bcf4216e9e50b61 https://github.com/openbsd/src/commit/3a08873ece1cb28ace89fd65e8f3c1375cc98de2 https://github.com/OP-TEE/optee_os/commit/abfd092aa19f9c0251e3d5551e2d68a9ebcfec8a It is demonstrated in a SafeSide example: https://github.com/google/safeside/blob/master/demos/eret_hvc_smc_wrapper.cc https://github.com/google/safeside/blob/master/kernel_modules/kmod_eret_hvc_smc/eret_hvc_smc_module.c Signed-off-by: Anthony Steinhauser <asteinhauser@google.com> Change-Id: Iead39b0b9fb4b8d8b5609daaa8be81497ba63a0f
-
- 20 Dec, 2019 8 commits
-
-
Paul Beesley authored
Change-Id: I2bab67f319758dd033aa689d985227cad796cdea Signed-off-by: Paul Beesley <paul.beesley@arm.com>
-
Paul Beesley authored
Change-Id: I851be04fc5de8a95ea11270996f8ca33f0fccadb Signed-off-by: Paul Beesley <paul.beesley@arm.com>
-
Paul Beesley authored
Change-Id: I575188885ebed8c5f0682ac6e0e7dd159155727f Signed-off-by: Paul Beesley <paul.beesley@arm.com>
-
Paul Beesley authored
Change-Id: Ie47009158032c2e8f35febd7bf5458156f334ead Signed-off-by: Paul Beesley <paul.beesley@arm.com>
-
Paul Beesley authored
Change-Id: Idcd2a35cd2b30d77a7ca031f7e0172814bdb8cab Signed-off-by: Paul Beesley <paul.beesley@arm.com>
-
Paul Beesley authored
The contents of this header have been merged into the spm_mm_svc.h header file. Change-Id: I01530b2e4ec1b4c091ce339758025e2216e740a4 Signed-off-by: Paul Beesley <paul.beesley@arm.com>
-
Paul Beesley authored
Change-Id: I91c192924433226b54d33e57d56d146c1c6df81b Signed-off-by: Paul Beesley <paul.beesley@arm.com>
-
Paul Beesley authored
Before adding any new SPM-related components we should first do some cleanup around the existing SPM-MM implementation. The aim is to make sure that any SPM-MM components have names that clearly indicate that they are MM-related. Otherwise, when adding new SPM code, it could quickly become confusing as it would be unclear to which component the code belongs. The secure_partition.h header is a clear example of this, as the name is generic so it could easily apply to any SPM-related code, when it is in fact SPM-MM specific. This patch renames the file and the two structures defined within it, and then modifies any references in files that use the header. Change-Id: I44bd95fab774c358178b3e81262a16da500fda26 Signed-off-by: Paul Beesley <paul.beesley@arm.com>
-
- 19 Nov, 2019 1 commit
-
-
Justin Chadwell authored
Variable shadowing is, according to the C standard, permitted and valid behaviour. However, allowing a local variable to take the same name as a global one can cause confusion and can make refactoring and bug hunting more difficult. This patch moves -Wshadow from WARNING2 into the general warning group so it is always used. It also fixes all warnings that this introduces by simply renaming the local variable to a new name Change-Id: I6b71bdce6580c6e58b5e0b41e4704ab0aa38576e Signed-off-by: Justin Chadwell <justin.chadwell@arm.com>
-
- 01 Aug, 2019 1 commit
-
-
Julius Werner authored
NOTE: __ASSEMBLY__ macro is now deprecated in favor of __ASSEMBLER__. All common C compilers predefine a macro called __ASSEMBLER__ when preprocessing a .S file. There is no reason for TF-A to define it's own __ASSEMBLY__ macro for this purpose instead. To unify code with the export headers (which use __ASSEMBLER__ to avoid one extra dependency), let's deprecate __ASSEMBLY__ and switch the code base over to the predefined standard. Change-Id: Id7d0ec8cf330195da80499c68562b65cb5ab7417 Signed-off-by: Julius Werner <jwerner@chromium.org>
-
- 22 Jan, 2019 1 commit
-
-
Antonio Nino Diaz authored
This implementation is no longer deprecated. Change-Id: I68552d0fd5ba9f08fad4345e4657e8e3c5362a36 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-