andrius
/
arm-trusted-firmware
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
arm-trusted-firmware/bl32/tsp/tsp_main.c

342 lines
12 KiB
C
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-2014, ARM Limited and Contributors. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* Neither the name of ARM nor the names of its contributors may be used
* to endorse or promote products derived from this software without specific
* prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#include <bl32.h>
#include <tsp.h>
#include <arch_helpers.h>
#include <stdio.h>
#include <platform.h>
#include <debug.h>
#include <spinlock.h>
/*******************************************************************************
* Lock to control access to the console
******************************************************************************/
spinlock_t console_lock;
/*******************************************************************************
* Per cpu data structure to populate parameters for an SMC in C code and use
* a pointer to this structure in assembler code to populate x0-x7
******************************************************************************/
static tsp_args tsp_smc_args[PLATFORM_CORE_COUNT];
/*******************************************************************************
* Per cpu data structure to keep track of TSP activity
******************************************************************************/
static work_statistics tsp_stats[PLATFORM_CORE_COUNT];
/*******************************************************************************
* Single reference to the various entry points exported by the test secure
* payload. A single copy should suffice for all cpus as they are not expected
* to change.
******************************************************************************/
static const entry_info tsp_entry_info = {
tsp_fast_smc_entry,
tsp_cpu_on_entry,
tsp_cpu_off_entry,
tsp_cpu_resume_entry,
tsp_cpu_suspend_entry,
};
static tsp_args *set_smc_args(uint64_t arg0,
uint64_t arg1,
uint64_t arg2,
uint64_t arg3,
uint64_t arg4,
uint64_t arg5,
uint64_t arg6,
uint64_t arg7)
{
uint64_t mpidr = read_mpidr();
uint32_t linear_id;
tsp_args *pcpu_smc_args;
/*
* Return to Secure Monitor by raising an SMC. The results of the
* service are passed as an arguments to the SMC
*/
linear_id = platform_get_core_pos(mpidr);
pcpu_smc_args = &tsp_smc_args[linear_id];
write_sp_arg(pcpu_smc_args, TSP_ARG0, arg0);
write_sp_arg(pcpu_smc_args, TSP_ARG1, arg1);
write_sp_arg(pcpu_smc_args, TSP_ARG2, arg2);
write_sp_arg(pcpu_smc_args, TSP_ARG3, arg3);
write_sp_arg(pcpu_smc_args, TSP_ARG4, arg4);
write_sp_arg(pcpu_smc_args, TSP_ARG5, arg5);
write_sp_arg(pcpu_smc_args, TSP_ARG6, arg6);
write_sp_arg(pcpu_smc_args, TSP_ARG7, arg7);
return pcpu_smc_args;
}
/*******************************************************************************
* TSP main entry point where it gets the opportunity to initialize its secure
* state/applications. Once the state is initialized, it must return to the
* SPD with a pointer to the 'tsp_entry_info' structure.
******************************************************************************/
uint64_t tsp_main(void)
{
uint64_t mpidr = read_mpidr();
uint32_t linear_id = platform_get_core_pos(mpidr);
#if DEBUG
meminfo *mem_layout = bl32_plat_sec_mem_layout();
#endif
/* Initialize the platform */
bl32_platform_setup();
/* Initialize secure/applications state here */
/* Update this cpu's statistics */
tsp_stats[linear_id].smc_count++;
tsp_stats[linear_id].eret_count++;
tsp_stats[linear_id].cpu_on_count++;
spin_lock(&console_lock);
Generate build time and date message at link time. So it updates each time a bootloader changes, not just when bl*_main.c files are recompiled. Fixes ARM-software/tf-issues#33 Change-Id: Ie8e1a7bd7e1913d2e96ac268606284f76af8c5ab Signed-off-by: Jon Medhurst <tixy@linaro.org>
2014-02-17 12:18:24 +00:00
printf("TSP %s\n\r", build_message);
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
INFO("Total memory base : 0x%x\n", mem_layout->total_base);
INFO("Total memory size : 0x%x bytes\n", mem_layout->total_size);
INFO("Free memory base : 0x%x\n", mem_layout->free_base);
INFO("Free memory size : 0x%x bytes\n", mem_layout->free_size);
INFO("cpu 0x%x: %d smcs, %d erets %d cpu on requests\n", mpidr,
tsp_stats[linear_id].smc_count,
tsp_stats[linear_id].eret_count,
tsp_stats[linear_id].cpu_on_count);
spin_unlock(&console_lock);
/*
* TODO: There is a massive assumption that the SPD and SP can see each
* other's memory without issues so it is safe to pass pointers to
* internal memory. Replace this with a shared communication buffer.
*/
return (uint64_t) &tsp_entry_info;
}
/*******************************************************************************
* This function performs any remaining book keeping in the test secure payload
* after this cpu's architectural state has been setup in response to an earlier
* psci cpu_on request.
******************************************************************************/
tsp_args *tsp_cpu_on_main(void)
{
uint64_t mpidr = read_mpidr();
uint32_t linear_id = platform_get_core_pos(mpidr);
/* Update this cpu's statistics */
tsp_stats[linear_id].smc_count++;
tsp_stats[linear_id].eret_count++;
tsp_stats[linear_id].cpu_on_count++;
spin_lock(&console_lock);
printf("SP: cpu 0x%x turned on\n\r", mpidr);
INFO("cpu 0x%x: %d smcs, %d erets %d cpu on requests\n", mpidr,
tsp_stats[linear_id].smc_count,
tsp_stats[linear_id].eret_count,
tsp_stats[linear_id].cpu_on_count);
spin_unlock(&console_lock);
/* Indicate to the SPD that we have completed turned ourselves on */
return set_smc_args(TSP_ON_DONE, 0, 0, 0, 0, 0, 0, 0);
}
/*******************************************************************************
* This function performs any remaining book keeping in the test secure payload
* before this cpu is turned off in response to a psci cpu_off request.
******************************************************************************/
tsp_args *tsp_cpu_off_main(uint64_t arg0,
uint64_t arg1,
uint64_t arg2,
uint64_t arg3,
uint64_t arg4,
uint64_t arg5,
uint64_t arg6,
uint64_t arg7)
{
uint64_t mpidr = read_mpidr();
uint32_t linear_id = platform_get_core_pos(mpidr);
/* Update this cpu's statistics */
tsp_stats[linear_id].smc_count++;
tsp_stats[linear_id].eret_count++;
tsp_stats[linear_id].cpu_off_count++;
spin_lock(&console_lock);
printf("SP: cpu 0x%x off request\n\r", mpidr);
INFO("cpu 0x%x: %d smcs, %d erets %d cpu off requests\n", mpidr,
tsp_stats[linear_id].smc_count,
tsp_stats[linear_id].eret_count,
tsp_stats[linear_id].cpu_off_count);
spin_unlock(&console_lock);
Add power management support in the SPD This patch implements a set of handlers in the SPD which are called by the PSCI runtime service upon receiving a power management operation. These handlers in turn pass control to the Secure Payload image if required before returning control to PSCI. This ensures that the Secure Payload has complete visibility of all power transitions in the system and can prepare accordingly. Change-Id: I2d1dba5629b7cf2d53999d39fe807dfcf3f62fe2
2014-02-09 18:24:19 +00:00
/* Indicate to the SPD that we have completed this request */
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
return set_smc_args(TSP_OFF_DONE, 0, 0, 0, 0, 0, 0, 0);
}
/*******************************************************************************
* This function performs any book keeping in the test secure payload before
* this cpu's architectural state is saved in response to an earlier psci
* cpu_suspend request.
******************************************************************************/
tsp_args *tsp_cpu_suspend_main(uint64_t power_state,
uint64_t arg1,
uint64_t arg2,
uint64_t arg3,
uint64_t arg4,
uint64_t arg5,
uint64_t arg6,
uint64_t arg7)
{
uint64_t mpidr = read_mpidr();
uint32_t linear_id = platform_get_core_pos(mpidr);
/* Update this cpu's statistics */
tsp_stats[linear_id].smc_count++;
tsp_stats[linear_id].eret_count++;
tsp_stats[linear_id].cpu_suspend_count++;
spin_lock(&console_lock);
printf("SP: cpu 0x%x suspend request. power state: 0x%x\n\r",
mpidr, power_state);
INFO("cpu 0x%x: %d smcs, %d erets %d cpu suspend requests\n", mpidr,
tsp_stats[linear_id].smc_count,
tsp_stats[linear_id].eret_count,
tsp_stats[linear_id].cpu_suspend_count);
spin_unlock(&console_lock);
Add power management support in the SPD This patch implements a set of handlers in the SPD which are called by the PSCI runtime service upon receiving a power management operation. These handlers in turn pass control to the Secure Payload image if required before returning control to PSCI. This ensures that the Secure Payload has complete visibility of all power transitions in the system and can prepare accordingly. Change-Id: I2d1dba5629b7cf2d53999d39fe807dfcf3f62fe2
2014-02-09 18:24:19 +00:00
/* Indicate to the SPD that we have completed this request */
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
return set_smc_args(TSP_SUSPEND_DONE, 0, 0, 0, 0, 0, 0, 0);
}
/*******************************************************************************
* This function performs any book keeping in the test secure payload after this
* cpu's architectural state has been restored after wakeup from an earlier psci
* cpu_suspend request.
******************************************************************************/
tsp_args *tsp_cpu_resume_main(uint64_t suspend_level,
uint64_t arg1,
uint64_t arg2,
uint64_t arg3,
uint64_t arg4,
uint64_t arg5,
uint64_t arg6,
uint64_t arg7)
{
uint64_t mpidr = read_mpidr();
uint32_t linear_id = platform_get_core_pos(mpidr);
/* Update this cpu's statistics */
tsp_stats[linear_id].smc_count++;
tsp_stats[linear_id].eret_count++;
tsp_stats[linear_id].cpu_resume_count++;
spin_lock(&console_lock);
printf("SP: cpu 0x%x resumed. suspend level %d \n\r",
mpidr, suspend_level);
INFO("cpu 0x%x: %d smcs, %d erets %d cpu suspend requests\n", mpidr,
tsp_stats[linear_id].smc_count,
tsp_stats[linear_id].eret_count,
tsp_stats[linear_id].cpu_suspend_count);
spin_unlock(&console_lock);
Add power management support in the SPD This patch implements a set of handlers in the SPD which are called by the PSCI runtime service upon receiving a power management operation. These handlers in turn pass control to the Secure Payload image if required before returning control to PSCI. This ensures that the Secure Payload has complete visibility of all power transitions in the system and can prepare accordingly. Change-Id: I2d1dba5629b7cf2d53999d39fe807dfcf3f62fe2
2014-02-09 18:24:19 +00:00
/* Indicate to the SPD that we have completed this request */
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
return set_smc_args(TSP_RESUME_DONE, 0, 0, 0, 0, 0, 0, 0);
}
/*******************************************************************************
* TSP fast smc handler. The secure monitor jumps to this function by
* doing the ERET after populating X0-X7 registers. The arguments are received
* in the function arguments in order. Once the service is rendered, this
* function returns to Secure Monitor by raising SMC
******************************************************************************/
tsp_args *tsp_fast_smc_handler(uint64_t func,
uint64_t arg1,
uint64_t arg2,
uint64_t arg3,
uint64_t arg4,
uint64_t arg5,
uint64_t arg6,
uint64_t arg7)
{
Rework arithmetic operations in Test Secure Payload This patch reworks the service provided by the TSP to perform common arithmetic operations on a set of arguments provided by the non-secure world. For a addition, division, subtraction & multiplication operation requested on two arguments in x0 and x1 the steps are: 1. TSPD saves the non-secure context and passes the operation and its arguments to the TSP. 2. TSP asks the TSPD to return the same arguments once again. This exercises an additional SMC path. 3. TSP now has two copies of both x0 and x1. It performs the operation on the corresponding copies i.e. in case of addition it returns x0+x0 and x1+x1. 4. TSPD receives the result, saves the secure context, restores the non-secure context and passes the result back to the non-secure client. Change-Id: I6eebfa2ae0a6f28b1d2e11a31f575c7a4b96724b Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-09 23:11:46 +00:00
uint64_t results[2];
uint64_t service_args[2];
uint64_t mpidr = read_mpidr();
uint32_t linear_id = platform_get_core_pos(mpidr);
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
Rework arithmetic operations in Test Secure Payload This patch reworks the service provided by the TSP to perform common arithmetic operations on a set of arguments provided by the non-secure world. For a addition, division, subtraction & multiplication operation requested on two arguments in x0 and x1 the steps are: 1. TSPD saves the non-secure context and passes the operation and its arguments to the TSP. 2. TSP asks the TSPD to return the same arguments once again. This exercises an additional SMC path. 3. TSP now has two copies of both x0 and x1. It performs the operation on the corresponding copies i.e. in case of addition it returns x0+x0 and x1+x1. 4. TSPD receives the result, saves the secure context, restores the non-secure context and passes the result back to the non-secure client. Change-Id: I6eebfa2ae0a6f28b1d2e11a31f575c7a4b96724b Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-09 23:11:46 +00:00
/* Update this cpu's statistics */
tsp_stats[linear_id].smc_count++;
tsp_stats[linear_id].eret_count++;
printf("SP: cpu 0x%x received fast smc 0x%x\n", read_mpidr(), func);
INFO("cpu 0x%x: %d smcs, %d erets\n", mpidr,
tsp_stats[linear_id].smc_count,
tsp_stats[linear_id].eret_count);
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
Rework arithmetic operations in Test Secure Payload This patch reworks the service provided by the TSP to perform common arithmetic operations on a set of arguments provided by the non-secure world. For a addition, division, subtraction & multiplication operation requested on two arguments in x0 and x1 the steps are: 1. TSPD saves the non-secure context and passes the operation and its arguments to the TSP. 2. TSP asks the TSPD to return the same arguments once again. This exercises an additional SMC path. 3. TSP now has two copies of both x0 and x1. It performs the operation on the corresponding copies i.e. in case of addition it returns x0+x0 and x1+x1. 4. TSPD receives the result, saves the secure context, restores the non-secure context and passes the result back to the non-secure client. Change-Id: I6eebfa2ae0a6f28b1d2e11a31f575c7a4b96724b Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-09 23:11:46 +00:00
/* Render secure services and obtain results here */
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
results[0] = arg1;
results[1] = arg2;
/*
* Request a service back from dispatcher/secure monitor. This call
* return and thereafter resume exectuion
*/
tsp_get_magic(service_args);
/* Determine the function to perform based on the function ID */
switch (func) {
case TSP_FID_ADD:
results[0] += service_args[0];
results[1] += service_args[1];
break;
case TSP_FID_SUB:
results[0] -= service_args[0];
results[1] -= service_args[1];
break;
case TSP_FID_MUL:
results[0] *= service_args[0];
results[1] *= service_args[1];
break;
case TSP_FID_DIV:
results[0] /= service_args[0] ? service_args[0] : 1;
results[1] /= service_args[1] ? service_args[1] : 1;
break;
default:
break;
}
Rework arithmetic operations in Test Secure Payload This patch reworks the service provided by the TSP to perform common arithmetic operations on a set of arguments provided by the non-secure world. For a addition, division, subtraction & multiplication operation requested on two arguments in x0 and x1 the steps are: 1. TSPD saves the non-secure context and passes the operation and its arguments to the TSP. 2. TSP asks the TSPD to return the same arguments once again. This exercises an additional SMC path. 3. TSP now has two copies of both x0 and x1. It performs the operation on the corresponding copies i.e. in case of addition it returns x0+x0 and x1+x1. 4. TSPD receives the result, saves the secure context, restores the non-secure context and passes the result back to the non-secure client. Change-Id: I6eebfa2ae0a6f28b1d2e11a31f575c7a4b96724b Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-09 23:11:46 +00:00
return set_smc_args(func,
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
results[0],
results[1],
Rework arithmetic operations in Test Secure Payload This patch reworks the service provided by the TSP to perform common arithmetic operations on a set of arguments provided by the non-secure world. For a addition, division, subtraction & multiplication operation requested on two arguments in x0 and x1 the steps are: 1. TSPD saves the non-secure context and passes the operation and its arguments to the TSP. 2. TSP asks the TSPD to return the same arguments once again. This exercises an additional SMC path. 3. TSP now has two copies of both x0 and x1. It performs the operation on the corresponding copies i.e. in case of addition it returns x0+x0 and x1+x1. 4. TSPD receives the result, saves the secure context, restores the non-secure context and passes the result back to the non-secure client. Change-Id: I6eebfa2ae0a6f28b1d2e11a31f575c7a4b96724b Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-09 23:11:46 +00:00
0, 0, 0, 0, 0);
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
}