arm-trusted-firmware/bl32/tsp/aarch64/tsp_entrypoint.S

464 lines
13 KiB
ArmAsm
Raw Normal View History

Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/*
* Copyright (c) 2013-2020, ARM Limited and Contributors. All rights reserved.
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
*
* SPDX-License-Identifier: BSD-3-Clause
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
*/
#include <platform_def.h>
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
#include <arch.h>
#include <asm_macros.S>
#include <bl32/tsp/tsp.h>
#include <lib/xlat_tables/xlat_tables_defs.h>
#include "../tsp_private.h"
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
.globl tsp_entrypoint
.globl tsp_vector_table
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/* ---------------------------------------------
* Populate the params in x0-x7 from the pointer
* to the smc args structure in x0.
* ---------------------------------------------
*/
.macro restore_args_call_smc
ldp x6, x7, [x0, #TSP_ARG6]
ldp x4, x5, [x0, #TSP_ARG4]
ldp x2, x3, [x0, #TSP_ARG2]
ldp x0, x1, [x0, #TSP_ARG0]
smc #0
.endm
.macro save_eret_context reg1 reg2
mrs \reg1, elr_el1
mrs \reg2, spsr_el1
stp \reg1, \reg2, [sp, #-0x10]!
stp x30, x18, [sp, #-0x10]!
.endm
.macro restore_eret_context reg1 reg2
ldp x30, x18, [sp], #0x10
ldp \reg1, \reg2, [sp], #0x10
msr elr_el1, \reg1
msr spsr_el1, \reg2
.endm
Add new alignment parameter to func assembler macro Assembler programmers are used to being able to define functions with a specific aligment with a pattern like this: .align X myfunction: However, this pattern is subtly broken when instead of a direct label like 'myfunction:', you use the 'func myfunction' macro that's standard in Trusted Firmware. Since the func macro declares a new section for the function, the .align directive written above it actually applies to the *previous* section in the assembly file, and the function it was supposed to apply to is linked with default alignment. An extreme case can be seen in Rockchip's plat_helpers.S which contains this code: [...] endfunc plat_crash_console_putc .align 16 func platform_cpu_warmboot [...] This assembles into the following plat_helpers.o: Sections: Idx Name Size [...] Algn 9 .text.plat_crash_console_putc 00010000 [...] 2**16 10 .text.platform_cpu_warmboot 00000080 [...] 2**3 As can be seen, the *previous* function actually got the alignment constraint, and it is also 64KB big even though it contains only two instructions, because the .align directive at the end of its section forces the assembler to insert a giant sled of NOPs. The function we actually wanted to align has the default constraint. This code only works at all because the linker just happens to put the two functions right behind each other when linking the final image, and since the end of plat_crash_console_putc is aligned the start of platform_cpu_warmboot will also be. But it still wastes almost 64KB of image space unnecessarily, and it will break under certain circumstances (e.g. if the plat_crash_console_putc function becomes unused and its section gets garbage-collected out). There's no real way to fix this with the existing func macro. Code like func myfunc .align X happens to do the right thing, but is still not really correct code (because the function label is inserted before the .align directive, so the assembler is technically allowed to insert padding at the beginning of the function which would then get executed as instructions if the function was called). Therefore, this patch adds a new parameter with a default value to the func macro that allows overriding its alignment. Also fix up all existing instances of this dangerous antipattern. Change-Id: I5696a07e2fde896f21e0e83644c95b7b6ac79a10 Signed-off-by: Julius Werner <jwerner@chromium.org>
2017-08-01 23:16:36 +01:00
func tsp_entrypoint _align=3
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
#if ENABLE_PIE
/*
* ------------------------------------------------------------
* If PIE is enabled fixup the Global descriptor Table only
* once during primary core cold boot path.
*
* Compile time base address, required for fixup, is calculated
* using "pie_fixup" label present within first page.
* ------------------------------------------------------------
*/
pie_fixup:
ldr x0, =pie_fixup
Increase type widths to satisfy width requirements Usually, C has no problem up-converting types to larger bit sizes. MISRA rule 10.7 requires that you not do this, or be very explicit about this. This resolves the following required rule: bl1/aarch64/bl1_context_mgmt.c:81:[MISRA C-2012 Rule 10.7 (required)]<None> The width of the composite expression "0U | ((mode & 3U) << 2U) | 1U | 0x3c0U" (32 bits) is less that the right hand operand "18446744073709547519ULL" (64 bits). This also resolves MISRA defects such as: bl2/aarch64/bl2arch_setup.c:18:[MISRA C-2012 Rule 12.2 (required)] In the expression "3U << 20", shifting more than 7 bits, the number of bits in the essential type of the left expression, "3U", is not allowed. Further, MISRA requires that all shifts don't overflow. The definition of PAGE_SIZE was (1U << 12), and 1U is 8 bits. This caused about 50 issues. This fixes the violation by changing the definition to 1UL << 12. Since this uses 32bits, it should not create any issues for aarch32. This patch also contains a fix for a build failure in the sun50i_a64 platform. Specifically, these misra fixes removed a single and instruction, 92407e73 and x19, x19, #0xffffffff from the cm_setup_context function caused a relocation in psci_cpus_on_start to require a linker-generated stub. This increased the size of the .text section and caused an alignment later on to go over a page boundary and round up to the end of RAM before placing the .data section. This sectionn is of non-zero size and therefore causes a link error. The fix included in this reorders the functions during link time without changing their ording with respect to alignment. Change-Id: I76b4b662c3d262296728a8b9aab7a33b02087f16 Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
2020-08-04 22:18:52 +01:00
and x0, x0, #~(PAGE_SIZE_MASK)
mov_imm x1, (BL32_LIMIT - BL32_BASE)
add x1, x1, x0
bl fixup_gdt_reloc
#endif /* ENABLE_PIE */
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/* ---------------------------------------------
* Set the exception vector to something sane.
* ---------------------------------------------
*/
adr x0, tsp_exceptions
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
msr vbar_el1, x0
isb
/* ---------------------------------------------
* Enable the SError interrupt now that the
* exception vectors have been setup.
* ---------------------------------------------
*/
msr daifclr, #DAIF_ABT_BIT
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/* ---------------------------------------------
* Enable the instruction cache, stack pointer
* and data access alignment checks and disable
* speculative loads.
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
* ---------------------------------------------
*/
mov x1, #(SCTLR_I_BIT | SCTLR_A_BIT | SCTLR_SA_BIT)
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
mrs x0, sctlr_el1
orr x0, x0, x1
bic x0, x0, #SCTLR_DSSBS_BIT
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
msr sctlr_el1, x0
isb
Make generic code work in presence of system caches On the ARMv8 architecture, cache maintenance operations by set/way on the last level of integrated cache do not affect the system cache. This means that such a flush or clean operation could result in the data being pushed out to the system cache rather than main memory. Another CPU could access this data before it enables its data cache or MMU. Such accesses could be serviced from the main memory instead of the system cache. If the data in the sysem cache has not yet been flushed or evicted to main memory then there could be a loss of coherency. The only mechanism to guarantee that the main memory will be updated is to use cache maintenance operations to the PoC by MVA(See section D3.4.11 (System level caches) of ARMv8-A Reference Manual (Issue A.g/ARM DDI0487A.G). This patch removes the reliance of Trusted Firmware on the flush by set/way operation to ensure visibility of data in the main memory. Cache maintenance operations by MVA are now used instead. The following are the broad category of changes: 1. The RW areas of BL2/BL31/BL32 are invalidated by MVA before the C runtime is initialised. This ensures that any stale cache lines at any level of cache are removed. 2. Updates to global data in runtime firmware (BL31) by the primary CPU are made visible to secondary CPUs using a cache clean operation by MVA. 3. Cache maintenance by set/way operations are only used prior to power down. NOTE: NON-UPSTREAM TRUSTED FIRMWARE CODE SHOULD MAKE EQUIVALENT CHANGES IN ORDER TO FUNCTION CORRECTLY ON PLATFORMS WITH SUPPORT FOR SYSTEM CACHES. Fixes ARM-software/tf-issues#205 Change-Id: I64f1b398de0432813a0e0881d70f8337681f6e9a
2015-09-11 16:03:13 +01:00
/* ---------------------------------------------
* Invalidate the RW memory used by the BL32
* image. This includes the data and NOBITS
* sections. This is done to safeguard against
* possible corruption of this memory by dirty
* cache lines in a system cache as a result of
* use by an earlier boot loader stage.
* ---------------------------------------------
*/
adr x0, __RW_START__
adr x1, __RW_END__
sub x1, x1, x0
bl inv_dcache_range
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/* ---------------------------------------------
* Zero out NOBITS sections. There are 2 of them:
* - the .bss section;
* - the coherent memory section.
* ---------------------------------------------
*/
ldr x0, =__BSS_START__
ldr x1, =__BSS_SIZE__
Introduce unified API to zero memory 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. Fixes ARM-software/tf-issues#408 Change-Id: Iafd9663fc1070413c3e1904e54091cf60effaa82 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
2016-12-02 13:51:54 +00:00
bl zeromem
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
#if USE_COHERENT_MEM
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
ldr x0, =__COHERENT_RAM_START__
ldr x1, =__COHERENT_RAM_UNALIGNED_SIZE__
Introduce unified API to zero memory 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. Fixes ARM-software/tf-issues#408 Change-Id: Iafd9663fc1070413c3e1904e54091cf60effaa82 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
2016-12-02 13:51:54 +00:00
bl zeromem
#endif
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/* --------------------------------------------
* Allocate a stack whose memory will be marked
* as Normal-IS-WBWA when the MMU is enabled.
* There is no risk of reading stale stack
* memory after enabling the MMU as only the
* primary cpu is running at the moment.
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
* --------------------------------------------
*/
bl plat_set_my_stack
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/* ---------------------------------------------
* Initialize the stack protector canary before
* any C code is called.
* ---------------------------------------------
*/
#if STACK_PROTECTOR_ENABLED
bl update_stack_protector_canary
#endif
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/* ---------------------------------------------
* Perform TSP setup
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
* ---------------------------------------------
*/
bl tsp_setup
#if ENABLE_PAUTH
/* ---------------------------------------------
Refactor ARMv8.3 Pointer Authentication support code This patch provides the following features and makes modifications listed below: - Individual APIAKey key generation for each CPU. - New key generation on every BL31 warm boot and TSP CPU On event. - Per-CPU storage of APIAKey added in percpu_data[] of cpu_data structure. - `plat_init_apiakey()` function replaced with `plat_init_apkey()` which returns 128-bit value and uses Generic timer physical counter value to increase the randomness of the generated key. The new function can be used for generation of all ARMv8.3-PAuth keys - ARMv8.3-PAuth specific code placed in `lib\extensions\pauth`. - New `pauth_init_enable_el1()` and `pauth_init_enable_el3()` functions generate, program and enable APIAKey_EL1 for EL1 and EL3 respectively; pauth_disable_el1()` and `pauth_disable_el3()` functions disable PAuth for EL1 and EL3 respectively; `pauth_load_bl31_apiakey()` loads saved per-CPU APIAKey_EL1 from cpu-data structure. - Combined `save_gp_pauth_registers()` function replaces calls to `save_gp_registers()` and `pauth_context_save()`; `restore_gp_pauth_registers()` replaces `pauth_context_restore()` and `restore_gp_registers()` calls. - `restore_gp_registers_eret()` function removed with corresponding code placed in `el3_exit()`. - Fixed the issue when `pauth_t pauth_ctx` structure allocated space for 12 uint64_t PAuth registers instead of 10 by removal of macro CTX_PACGAKEY_END from `include/lib/el3_runtime/aarch64/context.h` and assigning its value to CTX_PAUTH_REGS_END. - Use of MODE_SP_ELX and MODE_SP_EL0 macro definitions in `msr spsel` instruction instead of hard-coded values. - Changes in documentation related to ARMv8.3-PAuth and ARMv8.5-BTI. Change-Id: Id18b81cc46f52a783a7e6a09b9f149b6ce803211 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2019-09-13 14:11:59 +01:00
* Program APIAKey_EL1
* and enable pointer authentication
* ---------------------------------------------
*/
Refactor ARMv8.3 Pointer Authentication support code This patch provides the following features and makes modifications listed below: - Individual APIAKey key generation for each CPU. - New key generation on every BL31 warm boot and TSP CPU On event. - Per-CPU storage of APIAKey added in percpu_data[] of cpu_data structure. - `plat_init_apiakey()` function replaced with `plat_init_apkey()` which returns 128-bit value and uses Generic timer physical counter value to increase the randomness of the generated key. The new function can be used for generation of all ARMv8.3-PAuth keys - ARMv8.3-PAuth specific code placed in `lib\extensions\pauth`. - New `pauth_init_enable_el1()` and `pauth_init_enable_el3()` functions generate, program and enable APIAKey_EL1 for EL1 and EL3 respectively; pauth_disable_el1()` and `pauth_disable_el3()` functions disable PAuth for EL1 and EL3 respectively; `pauth_load_bl31_apiakey()` loads saved per-CPU APIAKey_EL1 from cpu-data structure. - Combined `save_gp_pauth_registers()` function replaces calls to `save_gp_registers()` and `pauth_context_save()`; `restore_gp_pauth_registers()` replaces `pauth_context_restore()` and `restore_gp_registers()` calls. - `restore_gp_registers_eret()` function removed with corresponding code placed in `el3_exit()`. - Fixed the issue when `pauth_t pauth_ctx` structure allocated space for 12 uint64_t PAuth registers instead of 10 by removal of macro CTX_PACGAKEY_END from `include/lib/el3_runtime/aarch64/context.h` and assigning its value to CTX_PAUTH_REGS_END. - Use of MODE_SP_ELX and MODE_SP_EL0 macro definitions in `msr spsel` instruction instead of hard-coded values. - Changes in documentation related to ARMv8.3-PAuth and ARMv8.5-BTI. Change-Id: Id18b81cc46f52a783a7e6a09b9f149b6ce803211 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2019-09-13 14:11:59 +01:00
bl pauth_init_enable_el1
#endif /* ENABLE_PAUTH */
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/* ---------------------------------------------
* Jump to main function.
* ---------------------------------------------
*/
bl tsp_main
/* ---------------------------------------------
* Tell TSPD that we are done initialising
* ---------------------------------------------
*/
mov x1, x0
mov x0, #TSP_ENTRY_DONE
smc #0
tsp_entrypoint_panic:
b tsp_entrypoint_panic
endfunc tsp_entrypoint
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/* -------------------------------------------
* Table of entrypoint vectors provided to the
* TSPD for the various entrypoints
* -------------------------------------------
*/
vector_base tsp_vector_table
b tsp_yield_smc_entry
b tsp_fast_smc_entry
b tsp_cpu_on_entry
b tsp_cpu_off_entry
b tsp_cpu_resume_entry
b tsp_cpu_suspend_entry
b tsp_sel1_intr_entry
b tsp_system_off_entry
b tsp_system_reset_entry
b tsp_abort_yield_smc_entry
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/*---------------------------------------------
* This entrypoint is used by the TSPD when this
* cpu is to be turned off through a CPU_OFF
* psci call to ask the TSP to perform any
* bookeeping necessary. In the current
* implementation, the TSPD expects the TSP to
* re-initialise its state so nothing is done
* here except for acknowledging the request.
* ---------------------------------------------
*/
func tsp_cpu_off_entry
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
bl tsp_cpu_off_main
restore_args_call_smc
endfunc tsp_cpu_off_entry
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/*---------------------------------------------
* This entrypoint is used by the TSPD when the
* system is about to be switched off (through
* a SYSTEM_OFF psci call) to ask the TSP to
* perform any necessary bookkeeping.
* ---------------------------------------------
*/
func tsp_system_off_entry
bl tsp_system_off_main
restore_args_call_smc
endfunc tsp_system_off_entry
/*---------------------------------------------
* This entrypoint is used by the TSPD when the
* system is about to be reset (through a
* SYSTEM_RESET psci call) to ask the TSP to
* perform any necessary bookkeeping.
* ---------------------------------------------
*/
func tsp_system_reset_entry
bl tsp_system_reset_main
restore_args_call_smc
endfunc tsp_system_reset_entry
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/*---------------------------------------------
* This entrypoint is used by the TSPD when this
* cpu is turned on using a CPU_ON psci call to
* ask the TSP to initialise itself i.e. setup
* the mmu, stacks etc. Minimal architectural
* state will be initialised by the TSPD when
* this function is entered i.e. Caches and MMU
* will be turned off, the execution state
* will be aarch64 and exceptions masked.
* ---------------------------------------------
*/
func tsp_cpu_on_entry
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/* ---------------------------------------------
* Set the exception vector to something sane.
* ---------------------------------------------
*/
adr x0, tsp_exceptions
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
msr vbar_el1, x0
isb
/* Enable the SError interrupt */
msr daifclr, #DAIF_ABT_BIT
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/* ---------------------------------------------
* Enable the instruction cache, stack pointer
* and data access alignment checks
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
* ---------------------------------------------
*/
mov x1, #(SCTLR_I_BIT | SCTLR_A_BIT | SCTLR_SA_BIT)
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
mrs x0, sctlr_el1
orr x0, x0, x1
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
msr sctlr_el1, x0
isb
/* --------------------------------------------
* Give ourselves a stack whose memory will be
* marked as Normal-IS-WBWA when the MMU is
* enabled.
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
* --------------------------------------------
*/
bl plat_set_my_stack
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/* --------------------------------------------
* Enable MMU and D-caches together.
* --------------------------------------------
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
*/
mov x0, #0
bl bl32_plat_enable_mmu
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
Refactor ARMv8.3 Pointer Authentication support code This patch provides the following features and makes modifications listed below: - Individual APIAKey key generation for each CPU. - New key generation on every BL31 warm boot and TSP CPU On event. - Per-CPU storage of APIAKey added in percpu_data[] of cpu_data structure. - `plat_init_apiakey()` function replaced with `plat_init_apkey()` which returns 128-bit value and uses Generic timer physical counter value to increase the randomness of the generated key. The new function can be used for generation of all ARMv8.3-PAuth keys - ARMv8.3-PAuth specific code placed in `lib\extensions\pauth`. - New `pauth_init_enable_el1()` and `pauth_init_enable_el3()` functions generate, program and enable APIAKey_EL1 for EL1 and EL3 respectively; pauth_disable_el1()` and `pauth_disable_el3()` functions disable PAuth for EL1 and EL3 respectively; `pauth_load_bl31_apiakey()` loads saved per-CPU APIAKey_EL1 from cpu-data structure. - Combined `save_gp_pauth_registers()` function replaces calls to `save_gp_registers()` and `pauth_context_save()`; `restore_gp_pauth_registers()` replaces `pauth_context_restore()` and `restore_gp_registers()` calls. - `restore_gp_registers_eret()` function removed with corresponding code placed in `el3_exit()`. - Fixed the issue when `pauth_t pauth_ctx` structure allocated space for 12 uint64_t PAuth registers instead of 10 by removal of macro CTX_PACGAKEY_END from `include/lib/el3_runtime/aarch64/context.h` and assigning its value to CTX_PAUTH_REGS_END. - Use of MODE_SP_ELX and MODE_SP_EL0 macro definitions in `msr spsel` instruction instead of hard-coded values. - Changes in documentation related to ARMv8.3-PAuth and ARMv8.5-BTI. Change-Id: Id18b81cc46f52a783a7e6a09b9f149b6ce803211 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2019-09-13 14:11:59 +01:00
#if ENABLE_PAUTH
/* ---------------------------------------------
* Program APIAKey_EL1
* and enable pointer authentication
* ---------------------------------------------
*/
bl pauth_init_enable_el1
#endif /* ENABLE_PAUTH */
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/* ---------------------------------------------
* Enter C runtime to perform any remaining
* book keeping
* ---------------------------------------------
*/
bl tsp_cpu_on_main
restore_args_call_smc
/* Should never reach here */
tsp_cpu_on_entry_panic:
b tsp_cpu_on_entry_panic
endfunc tsp_cpu_on_entry
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/*---------------------------------------------
* This entrypoint is used by the TSPD when this
* cpu is to be suspended through a CPU_SUSPEND
* psci call to ask the TSP to perform any
* bookeeping necessary. In the current
* implementation, the TSPD saves and restores
* the EL1 state.
* ---------------------------------------------
*/
func tsp_cpu_suspend_entry
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
bl tsp_cpu_suspend_main
restore_args_call_smc
endfunc tsp_cpu_suspend_entry
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/*-------------------------------------------------
* This entrypoint is used by the TSPD to pass
* control for `synchronously` handling a S-EL1
* Interrupt which was triggered while executing
* in normal world. 'x0' contains a magic number
* which indicates this. TSPD expects control to
* be handed back at the end of interrupt
* processing. This is done through an SMC.
* The handover agreement is:
*
* 1. PSTATE.DAIF are set upon entry. 'x1' has
* the ELR_EL3 from the non-secure state.
* 2. TSP has to preserve the callee saved
* general purpose registers, SP_EL1/EL0 and
* LR.
* 3. TSP has to preserve the system and vfp
* registers (if applicable).
* 4. TSP can use 'x0-x18' to enable its C
* runtime.
* 5. TSP returns to TSPD using an SMC with
* 'x0' = TSP_HANDLED_S_EL1_INTR
* ------------------------------------------------
*/
func tsp_sel1_intr_entry
#if DEBUG
mov_imm x2, TSP_HANDLE_SEL1_INTR_AND_RETURN
cmp x0, x2
b.ne tsp_sel1_int_entry_panic
#endif
/*-------------------------------------------------
* Save any previous context needed to perform
* an exception return from S-EL1 e.g. context
* from a previous Non secure Interrupt.
* Update statistics and handle the S-EL1
* interrupt before returning to the TSPD.
* IRQ/FIQs are not enabled since that will
* complicate the implementation. Execution
* will be transferred back to the normal world
* in any case. The handler can return 0
* if the interrupt was handled or TSP_PREEMPTED
* if the expected interrupt was preempted
* by an interrupt that should be handled in EL3
* e.g. Group 0 interrupt in GICv3. In both
* the cases switch to EL3 using SMC with id
* TSP_HANDLED_S_EL1_INTR. Any other return value
* from the handler will result in panic.
* ------------------------------------------------
*/
save_eret_context x2 x3
bl tsp_update_sync_sel1_intr_stats
bl tsp_common_int_handler
/* Check if the S-EL1 interrupt has been handled */
cbnz x0, tsp_sel1_intr_check_preemption
b tsp_sel1_intr_return
tsp_sel1_intr_check_preemption:
/* Check if the S-EL1 interrupt has been preempted */
mov_imm x1, TSP_PREEMPTED
cmp x0, x1
b.ne tsp_sel1_int_entry_panic
tsp_sel1_intr_return:
mov_imm x0, TSP_HANDLED_S_EL1_INTR
restore_eret_context x2 x3
smc #0
/* Should never reach here */
tsp_sel1_int_entry_panic:
no_ret plat_panic_handler
endfunc tsp_sel1_intr_entry
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/*---------------------------------------------
* This entrypoint is used by the TSPD when this
* cpu resumes execution after an earlier
* CPU_SUSPEND psci call to ask the TSP to
* restore its saved context. In the current
* implementation, the TSPD saves and restores
* EL1 state so nothing is done here apart from
* acknowledging the request.
* ---------------------------------------------
*/
func tsp_cpu_resume_entry
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
bl tsp_cpu_resume_main
restore_args_call_smc
/* Should never reach here */
no_ret plat_panic_handler
endfunc tsp_cpu_resume_entry
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/*---------------------------------------------
* This entrypoint is used by the TSPD to ask
* the TSP to service a fast smc request.
* ---------------------------------------------
*/
func tsp_fast_smc_entry
bl tsp_smc_handler
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
restore_args_call_smc
/* Should never reach here */
no_ret plat_panic_handler
endfunc tsp_fast_smc_entry
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
/*---------------------------------------------
* This entrypoint is used by the TSPD to ask
* the TSP to service a Yielding SMC request.
* We will enable preemption during execution
* of tsp_smc_handler.
* ---------------------------------------------
*/
func tsp_yield_smc_entry
msr daifclr, #DAIF_FIQ_BIT | DAIF_IRQ_BIT
bl tsp_smc_handler
msr daifset, #DAIF_FIQ_BIT | DAIF_IRQ_BIT
restore_args_call_smc
/* Should never reach here */
no_ret plat_panic_handler
endfunc tsp_yield_smc_entry
/*---------------------------------------------------------------------
* This entrypoint is used by the TSPD to abort a pre-empted Yielding
* SMC. It could be on behalf of non-secure world or because a CPU
* suspend/CPU off request needs to abort the preempted SMC.
* --------------------------------------------------------------------
*/
func tsp_abort_yield_smc_entry
/*
* Exceptions masking is already done by the TSPD when entering this
* hook so there is no need to do it here.
*/
/* Reset the stack used by the pre-empted SMC */
bl plat_set_my_stack
/*
* Allow some cleanup such as releasing locks.
*/
bl tsp_abort_smc_handler
restore_args_call_smc
/* Should never reach here */
bl plat_panic_handler
endfunc tsp_abort_yield_smc_entry