Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-12-15 15:53:02 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/arm/mach-keystone/mon.c

143 lines
3.1 KiB
C
Raw Normal View History

SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-06 21:58:06 +00:00
// SPDX-License-Identifier: GPL-2.0+
ARM: keystone2: Split monitor code / command code When we switch to including all linker lists in SPL it is important to not include commands as that may lead to link errors due to other things we have already discarded. In this case, we split the code for supporting the monitor out from the code for loading it. Cc: Vitaly Andrianov <vitalya@ti.com> Cc: Nishanth Menon <nm@ti.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2016-03-16 13:10:08 +00:00
/*
arm: mach-keystone: Use appended original image size in image processing When an image is signed/encrypted on K2 devices the image may get padded to meet alignment requirements for the signature/encryption type. The original size is appended as 4 bytes little-endian to the end of the final image. Normally the trailing extra bytes are ignored and so restoring the exact original size is not important. In the case of initrd the original size is important as the kernel uses it to look for additional filesystem data and can do the wrong thing when the size is not correct. Read off the original size and report it back from the image post processing stage. Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-07-16 13:49:38 +00:00
* K2x: Secure commands file
ARM: keystone2: Split monitor code / command code When we switch to including all linker lists in SPL it is important to not include commands as that may lead to link errors due to other things we have already discarded. In this case, we split the code for supporting the monitor out from the code for loading it. Cc: Vitaly Andrianov <vitalya@ti.com> Cc: Nishanth Menon <nm@ti.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2016-03-16 13:10:08 +00:00
*
tree-wide: Replace http:// link with https:// link for ti.com Replace instances of http://www.ti.com with https://www.ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2023-11-01 20:56:03 +00:00
* Copyright (C) 2012-2019 Texas Instruments Incorporated - https://www.ti.com/
ARM: keystone2: Split monitor code / command code When we switch to including all linker lists in SPL it is important to not include commands as that may lead to link errors due to other things we have already discarded. In this case, we split the code for supporting the monitor out from the code for loading it. Cc: Vitaly Andrianov <vitalya@ti.com> Cc: Nishanth Menon <nm@ti.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2016-03-16 13:10:08 +00:00
*/
common: Move hang() to the same header as panic() At present panic() is in the vsprintf.h header file. That does not seem like an obvious choice for hang(), even though it relates to panic(). So let's put hang() in its own header. Signed-off-by: Simon Glass <sjg@chromium.org> [trini: Migrate a few more files] Signed-off-by: Tom Rini <trini@konsulko.com>
2019-12-28 17:45:07 +00:00
#include <hang.h>
common: Drop image.h from common header Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-10 17:40:01 +00:00
#include <image.h>
arm: mach-keystone: Use appended original image size in image processing When an image is signed/encrypted on K2 devices the image may get padded to meet alignment requirements for the signature/encryption type. The original size is appended as 4 bytes little-endian to the end of the final image. Normally the trailing extra bytes are ignored and so restoring the exact original size is not important. In the case of initrd the original size is important as the kernel uses it to look for additional filesystem data and can do the wrong thing when the size is not correct. Read off the original size and report it back from the image post processing stage. Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-07-16 13:49:38 +00:00
#include <asm/unaligned.h>
ARM: keystone2: Split monitor code / command code When we switch to including all linker lists in SPL it is important to not include commands as that may lead to link errors due to other things we have already discarded. In this case, we split the code for supporting the monitor out from the code for loading it. Cc: Vitaly Andrianov <vitalya@ti.com> Cc: Nishanth Menon <nm@ti.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2016-03-16 13:10:08 +00:00
#include <command.h>
#include <mach/mon.h>
arm: mach-keystone: Implements FIT post-processing call for keystone SoCs This commit implements the board_fit_image_post_process() function for the keystone architecture. This function calls into the secure boot monitor for secure authentication/decryption of the image. All needed work is handled by the boot monitor and, depending on the keystone platform, the security functions may be offloaded to other secure processing elements in the SoC. The boot monitor acts as the gateway to these secure functions and the boot monitor for secure devices is available as part of the SECDEV package for KS2. For more details refer doc/README.ti-secure Signed-off-by: Vitaly Andrianov <vitalya@ti.com> Signed-off-by: Madan Srinivas <madans@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2017-04-07 15:00:03 +00:00
#include <spl.h>
ARM: keystone2: Split monitor code / command code When we switch to including all linker lists in SPL it is important to not include commands as that may lead to link errors due to other things we have already discarded. In this case, we split the code for supporting the monitor out from the code for loading it. Cc: Vitaly Andrianov <vitalya@ti.com> Cc: Nishanth Menon <nm@ti.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2016-03-16 13:10:08 +00:00
asm(".arch_extension sec\n\t");
arm: mach-keystone: Updates mon_install for K2G HS On early K2 devices (eg. K2HK) the secure ROM code does not support loading secure code to firewall protected memory, before decrypting, authenticating and executing it. To load the boot monitor on these devices, it is necessary to first authenticate and run a copy loop from non-secure memory that copies the boot monitor behind firewall protected memory, before decrypting and executing it. On K2G, the secure ROM does not allow secure code executing from unprotected memory. Further, ROM first copies the signed and encrypted image into firewall protected memory, then decrypts, authenticates and executes it. As a result of this, we cannot use the copy loop for K2G. The mon_install has to be modified to pass the address the signed and encrypted secure boot monitor image to the authentication API. For backward compatibility with other K2 devices and K2G GP, the mon_install API still supports a single argument. In this case the second argument is set to 0 by u-boot and is ignored by ROM Signed-off-by: Thanh Tran <thanh-tran@ti.com> Signed-off-by: Madan Srinivas <madans@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-07-17 17:59:15 +00:00
int mon_install(u32 addr, u32 dpsc, u32 freq, u32 bm_addr)
ARM: keystone2: Split monitor code / command code When we switch to including all linker lists in SPL it is important to not include commands as that may lead to link errors due to other things we have already discarded. In this case, we split the code for supporting the monitor out from the code for loading it. Cc: Vitaly Andrianov <vitalya@ti.com> Cc: Nishanth Menon <nm@ti.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2016-03-16 13:10:08 +00:00
{
int result;
__asm__ __volatile__ (
"stmfd r13!, {lr}\n"
"mov r0, %1\n"
"mov r1, %2\n"
"mov r2, %3\n"
arm: mach-keystone: Updates mon_install for K2G HS On early K2 devices (eg. K2HK) the secure ROM code does not support loading secure code to firewall protected memory, before decrypting, authenticating and executing it. To load the boot monitor on these devices, it is necessary to first authenticate and run a copy loop from non-secure memory that copies the boot monitor behind firewall protected memory, before decrypting and executing it. On K2G, the secure ROM does not allow secure code executing from unprotected memory. Further, ROM first copies the signed and encrypted image into firewall protected memory, then decrypts, authenticates and executes it. As a result of this, we cannot use the copy loop for K2G. The mon_install has to be modified to pass the address the signed and encrypted secure boot monitor image to the authentication API. For backward compatibility with other K2 devices and K2G GP, the mon_install API still supports a single argument. In this case the second argument is set to 0 by u-boot and is ignored by ROM Signed-off-by: Thanh Tran <thanh-tran@ti.com> Signed-off-by: Madan Srinivas <madans@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-07-17 17:59:15 +00:00
"mov r3, %4\n"
ARM: keystone2: Split monitor code / command code When we switch to including all linker lists in SPL it is important to not include commands as that may lead to link errors due to other things we have already discarded. In this case, we split the code for supporting the monitor out from the code for loading it. Cc: Vitaly Andrianov <vitalya@ti.com> Cc: Nishanth Menon <nm@ti.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2016-03-16 13:10:08 +00:00
"blx r0\n"
arm: mach-keystone: Fixes issue with return values in inline assembly The inline assembly functions in mon.c assume that the caller will check for the return value in r0 according to regular ARM calling conventions. However, this assumption breaks down if the compiler inlines the functions. The caller is then under no obligation to use r0 for the result. To fix this disconnect, we must explicitly move the return value from the smc/bl call to the variable that the function returns. Signed-off-by: Madan Srinivas <madans@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-07-17 18:02:02 +00:00
"mov %0, r0\n"
ARM: keystone2: Split monitor code / command code When we switch to including all linker lists in SPL it is important to not include commands as that may lead to link errors due to other things we have already discarded. In this case, we split the code for supporting the monitor out from the code for loading it. Cc: Vitaly Andrianov <vitalya@ti.com> Cc: Nishanth Menon <nm@ti.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2016-03-16 13:10:08 +00:00
"ldmfd r13!, {lr}\n"
: "=&r" (result)
arm: mach-keystone: Updates mon_install for K2G HS On early K2 devices (eg. K2HK) the secure ROM code does not support loading secure code to firewall protected memory, before decrypting, authenticating and executing it. To load the boot monitor on these devices, it is necessary to first authenticate and run a copy loop from non-secure memory that copies the boot monitor behind firewall protected memory, before decrypting and executing it. On K2G, the secure ROM does not allow secure code executing from unprotected memory. Further, ROM first copies the signed and encrypted image into firewall protected memory, then decrypts, authenticates and executes it. As a result of this, we cannot use the copy loop for K2G. The mon_install has to be modified to pass the address the signed and encrypted secure boot monitor image to the authentication API. For backward compatibility with other K2 devices and K2G GP, the mon_install API still supports a single argument. In this case the second argument is set to 0 by u-boot and is ignored by ROM Signed-off-by: Thanh Tran <thanh-tran@ti.com> Signed-off-by: Madan Srinivas <madans@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-07-17 17:59:15 +00:00
: "r" (addr), "r" (dpsc), "r" (freq), "r" (bm_addr)
: "cc", "r0", "r1", "r2", "r3", "memory");
ARM: keystone2: Split monitor code / command code When we switch to including all linker lists in SPL it is important to not include commands as that may lead to link errors due to other things we have already discarded. In this case, we split the code for supporting the monitor out from the code for loading it. Cc: Vitaly Andrianov <vitalya@ti.com> Cc: Nishanth Menon <nm@ti.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2016-03-16 13:10:08 +00:00
return result;
}
int mon_power_on(int core_id, void *ep)
{
int result;
asm volatile (
"stmfd r13!, {lr}\n"
"mov r1, %1\n"
"mov r2, %2\n"
"mov r0, #0\n"
"smc #0\n"
arm: mach-keystone: Fixes issue with return values in inline assembly The inline assembly functions in mon.c assume that the caller will check for the return value in r0 according to regular ARM calling conventions. However, this assumption breaks down if the compiler inlines the functions. The caller is then under no obligation to use r0 for the result. To fix this disconnect, we must explicitly move the return value from the smc/bl call to the variable that the function returns. Signed-off-by: Madan Srinivas <madans@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-07-17 18:02:02 +00:00
"mov %0, r0\n"
ARM: keystone2: Split monitor code / command code When we switch to including all linker lists in SPL it is important to not include commands as that may lead to link errors due to other things we have already discarded. In this case, we split the code for supporting the monitor out from the code for loading it. Cc: Vitaly Andrianov <vitalya@ti.com> Cc: Nishanth Menon <nm@ti.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2016-03-16 13:10:08 +00:00
"ldmfd r13!, {lr}\n"
: "=&r" (result)
: "r" (core_id), "r" (ep)
: "cc", "r0", "r1", "r2", "memory");
return result;
}
int mon_power_off(int core_id)
{
int result;
asm volatile (
"stmfd r13!, {lr}\n"
"mov r1, %1\n"
"mov r0, #1\n"
"smc #1\n"
arm: mach-keystone: Fixes issue with return values in inline assembly The inline assembly functions in mon.c assume that the caller will check for the return value in r0 according to regular ARM calling conventions. However, this assumption breaks down if the compiler inlines the functions. The caller is then under no obligation to use r0 for the result. To fix this disconnect, we must explicitly move the return value from the smc/bl call to the variable that the function returns. Signed-off-by: Madan Srinivas <madans@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-07-17 18:02:02 +00:00
"mov %0, r0\n"
ARM: keystone2: Split monitor code / command code When we switch to including all linker lists in SPL it is important to not include commands as that may lead to link errors due to other things we have already discarded. In this case, we split the code for supporting the monitor out from the code for loading it. Cc: Vitaly Andrianov <vitalya@ti.com> Cc: Nishanth Menon <nm@ti.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2016-03-16 13:10:08 +00:00
"ldmfd r13!, {lr}\n"
: "=&r" (result)
: "r" (core_id)
: "cc", "r0", "r1", "memory");
return result;
}
arm: mach-keystone: Implements FIT post-processing call for keystone SoCs This commit implements the board_fit_image_post_process() function for the keystone architecture. This function calls into the secure boot monitor for secure authentication/decryption of the image. All needed work is handled by the boot monitor and, depending on the keystone platform, the security functions may be offloaded to other secure processing elements in the SoC. The boot monitor acts as the gateway to these secure functions and the boot monitor for secure devices is available as part of the SECDEV package for KS2. For more details refer doc/README.ti-secure Signed-off-by: Vitaly Andrianov <vitalya@ti.com> Signed-off-by: Madan Srinivas <madans@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2017-04-07 15:00:03 +00:00
#ifdef CONFIG_TI_SECURE_DEVICE
#define KS2_HS_SEC_HEADER_LEN 0x60
#define KS2_HS_SEC_TAG_OFFSET 0x34
#define KS2_AUTH_CMD 130
/**
* k2_hs_bm_auth() - Invokes security functions using a
* proprietary TI interface. This binary and source for
* this is available in the secure development package or
* SECDEV. For details on how to access this please refer
* doc/README.ti-secure
*
* @cmd: Secure monitor command
* @arg1: Argument for command
*
* returns non-zero value on success, zero on error
*/
static int k2_hs_bm_auth(int cmd, void *arg1)
{
int result;
asm volatile (
"stmfd r13!, {r4-r12, lr}\n"
"mov r0, %1\n"
"mov r1, %2\n"
"smc #2\n"
arm: mach-keystone: Fixes issue with return values in inline assembly The inline assembly functions in mon.c assume that the caller will check for the return value in r0 according to regular ARM calling conventions. However, this assumption breaks down if the compiler inlines the functions. The caller is then under no obligation to use r0 for the result. To fix this disconnect, we must explicitly move the return value from the smc/bl call to the variable that the function returns. Signed-off-by: Madan Srinivas <madans@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-07-17 18:02:02 +00:00
"mov %0, r0\n"
arm: mach-keystone: Implements FIT post-processing call for keystone SoCs This commit implements the board_fit_image_post_process() function for the keystone architecture. This function calls into the secure boot monitor for secure authentication/decryption of the image. All needed work is handled by the boot monitor and, depending on the keystone platform, the security functions may be offloaded to other secure processing elements in the SoC. The boot monitor acts as the gateway to these secure functions and the boot monitor for secure devices is available as part of the SECDEV package for KS2. For more details refer doc/README.ti-secure Signed-off-by: Vitaly Andrianov <vitalya@ti.com> Signed-off-by: Madan Srinivas <madans@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2017-04-07 15:00:03 +00:00
"ldmfd r13!, {r4-r12, lr}\n"
: "=&r" (result)
: "r" (cmd), "r" (arg1)
: "cc", "r0", "r1", "memory");
return result;
}
common: fit: Update board_fit_image_post_process() to pass fit and node_offset board_fit_image_post_process() passes only start and size of the image, but type of the image is not passed. So pass fit and node_offset, to derive information about image to be processed. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Tero Kristo <kristo@kernel.org>
2021-06-11 08:45:05 +00:00
void board_fit_image_post_process(const void *fit, int node, void **p_image,
size_t *p_size)
arm: mach-keystone: Implements FIT post-processing call for keystone SoCs This commit implements the board_fit_image_post_process() function for the keystone architecture. This function calls into the secure boot monitor for secure authentication/decryption of the image. All needed work is handled by the boot monitor and, depending on the keystone platform, the security functions may be offloaded to other secure processing elements in the SoC. The boot monitor acts as the gateway to these secure functions and the boot monitor for secure devices is available as part of the SECDEV package for KS2. For more details refer doc/README.ti-secure Signed-off-by: Vitaly Andrianov <vitalya@ti.com> Signed-off-by: Madan Srinivas <madans@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2017-04-07 15:00:03 +00:00
{
int result = 0;
void *image = *p_image;
if (strncmp(image + KS2_HS_SEC_TAG_OFFSET, "KEYS", 4)) {
printf("No signature found in image!\n");
hang();
}
result = k2_hs_bm_auth(KS2_AUTH_CMD, image);
if (result == 0) {
printf("Authentication failed!\n");
hang();
}
/*
arm: mach-keystone: Modify secure image size before copy The size of the secure image does not include the size of the header, subtract this out before we move the image or we grab extra data after the image. Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2017-06-29 13:38:25 +00:00
* Overwrite the image headers after authentication
* and decryption. Update size to reflect removal
arm: mach-keystone: Use appended original image size in image processing When an image is signed/encrypted on K2 devices the image may get padded to meet alignment requirements for the signature/encryption type. The original size is appended as 4 bytes little-endian to the end of the final image. Normally the trailing extra bytes are ignored and so restoring the exact original size is not important. In the case of initrd the original size is important as the kernel uses it to look for additional filesystem data and can do the wrong thing when the size is not correct. Read off the original size and report it back from the image post processing stage. Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-07-16 13:49:38 +00:00
* of header and restore original file size.
arm: mach-keystone: Modify secure image size before copy The size of the secure image does not include the size of the header, subtract this out before we move the image or we grab extra data after the image. Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2017-06-29 13:38:25 +00:00
*/
arm: mach-keystone: Use appended original image size in image processing When an image is signed/encrypted on K2 devices the image may get padded to meet alignment requirements for the signature/encryption type. The original size is appended as 4 bytes little-endian to the end of the final image. Normally the trailing extra bytes are ignored and so restoring the exact original size is not important. In the case of initrd the original size is important as the kernel uses it to look for additional filesystem data and can do the wrong thing when the size is not correct. Read off the original size and report it back from the image post processing stage. Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-07-16 13:49:38 +00:00
*p_size = get_unaligned_le32(image + (*p_size - 4));
arm: mach-keystone: Modify secure image size before copy The size of the secure image does not include the size of the header, subtract this out before we move the image or we grab extra data after the image. Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2017-06-29 13:38:25 +00:00
memcpy(image, image + KS2_HS_SEC_HEADER_LEN, *p_size);
arm: mach-keystone: Implements FIT post-processing call for keystone SoCs This commit implements the board_fit_image_post_process() function for the keystone architecture. This function calls into the secure boot monitor for secure authentication/decryption of the image. All needed work is handled by the boot monitor and, depending on the keystone platform, the security functions may be offloaded to other secure processing elements in the SoC. The boot monitor acts as the gateway to these secure functions and the boot monitor for secure devices is available as part of the SECDEV package for KS2. For more details refer doc/README.ti-secure Signed-off-by: Vitaly Andrianov <vitalya@ti.com> Signed-off-by: Madan Srinivas <madans@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2017-04-07 15:00:03 +00:00
/*
* Output notification of successful authentication to re-assure the
* user that the secure code is being processed as expected. However
* suppress any such log output in case of building for SPL and booting
* via YMODEM. This is done to avoid disturbing the YMODEM serial
* protocol transactions.
*/
if (!(IS_ENABLED(CONFIG_SPL_BUILD) &&
IS_ENABLED(CONFIG_SPL_YMODEM_SUPPORT) &&
spl_boot_device() == BOOT_DEVICE_UART))
printf("Authentication passed\n");
}
#endif
Reference in a new issue Copy permalink