arm: mach-k3: Add secure device support

K3 devices have High Security (HS) variants along with the non-HS already
supported. Like the previous generation devices (OMAP/Keystone2) K3
supports boot chain-of-trust by authenticating and optionally decrypting
images as they are unpacked from FIT images. Add support for this here.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
This commit is contained in:
Andrew F. Davis 2019-04-12 12:54:45 -04:00 committed by Tom Rini
parent ff6043a5fd
commit 3a543a8084
4 changed files with 66 additions and 1 deletions

View File

@ -733,6 +733,7 @@ S: Supported
F: arch/arm/mach-omap2/omap5/sec_entry_cpu1.S F: arch/arm/mach-omap2/omap5/sec_entry_cpu1.S
F: arch/arm/mach-omap2/sec-common.c F: arch/arm/mach-omap2/sec-common.c
F: arch/arm/mach-omap2/config_secure.mk F: arch/arm/mach-omap2/config_secure.mk
F: arch/arm/mach-k3/security.c
F: configs/am335x_hs_evm_defconfig F: configs/am335x_hs_evm_defconfig
F: configs/am335x_hs_evm_uart_defconfig F: configs/am335x_hs_evm_uart_defconfig
F: configs/am43xx_hs_evm_defconfig F: configs/am43xx_hs_evm_defconfig

View File

@ -1464,7 +1464,7 @@ endchoice
config TI_SECURE_DEVICE config TI_SECURE_DEVICE
bool "HS Device Type Support" bool "HS Device Type Support"
depends on ARCH_KEYSTONE || ARCH_OMAP2PLUS depends on ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_K3
help help
If a high secure (HS) device type is being used, this config If a high secure (HS) device type is being used, this config
must be set. This option impacts various aspects of the must be set. This option impacts various aspects of the

View File

@ -6,4 +6,5 @@
obj-$(CONFIG_SOC_K3_AM6) += am6_init.o obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
obj-$(CONFIG_ARM64) += arm64-mmu.o obj-$(CONFIG_ARM64) += arm64-mmu.o
obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
obj-$(CONFIG_TI_SECURE_DEVICE) += security.o
obj-y += common.o obj-y += common.o

View File

@ -0,0 +1,63 @@
// SPDX-License-Identifier: GPL-2.0
/*
* K3: Security functions
*
* Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
* Andrew F. Davis <afd@ti.com>
*/
#include <common.h>
#include <dm.h>
#include <linux/soc/ti/ti_sci_protocol.h>
#include <mach/spl.h>
#include <spl.h>
void board_fit_image_post_process(void **p_image, size_t *p_size)
{
struct udevice *dev;
struct ti_sci_handle *ti_sci;
struct ti_sci_proc_ops *proc_ops;
u64 image_addr;
u32 image_size;
int ret;
/* Get handle to Device Management and Security Controller (SYSFW) */
ret = uclass_get_device_by_name(UCLASS_FIRMWARE, "dmsc", &dev);
if (ret) {
printf("Failed to get handle to SYSFW (%d)\n", ret);
hang();
}
ti_sci = (struct ti_sci_handle *)(ti_sci_get_handle_from_sysfw(dev));
proc_ops = &ti_sci->ops.proc_ops;
image_addr = (uintptr_t)*p_image;
debug("Authenticating image at address 0x%016llx\n", image_addr);
/* Authenticate image */
ret = proc_ops->proc_auth_boot_image(ti_sci, &image_addr, &image_size);
if (ret) {
printf("Authentication failed!\n");
hang();
}
/*
* The image_size returned may be 0 when the authentication process has
* moved the image. When this happens no further processing on the
* image is needed or often even possible as it may have also been
* placed behind a firewall when moved.
*/
*p_size = image_size;
/*
* 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");
}