mirror of
https://github.com/brain-hackers/u-boot-brain
synced 2024-08-21 17:38:51 +09:00
![Tom Rini](/assets/img/avatar_default.png)
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>
41 lines
1.7 KiB
Plaintext
41 lines
1.7 KiB
Plaintext
SPDX-License-Identifier: GPL-2.0+
|
|
/*
|
|
* (C) Copyright 2015
|
|
*/
|
|
|
|
esbc_validate command
|
|
========================================
|
|
|
|
1. esbc_validate command is meant for validating header and
|
|
signature of images (Boot Script and ESBC uboot client).
|
|
SHA-256 and RSA operations are performed using SEC block in HW.
|
|
This command works on both PBL based and Non PBL based Freescale
|
|
platforms.
|
|
Command usage:
|
|
esbc_validate img_hdr_addr [pub_key_hash]
|
|
esbc_validate hdr_addr <hash_val>
|
|
Validates signature using RSA verification.
|
|
$hdr_addr Address of header of the image to be validated.
|
|
$hash_val -Optional. It provides Hash of public/srk key to be
|
|
used to verify signature.
|
|
|
|
2. ESBC uboot client can be linux. Additionally, rootfs and device
|
|
tree blob can also be signed.
|
|
3. In the event of header or signature failure in validation,
|
|
ITS and ITF bits determine further course of action.
|
|
4. In case of soft failure, appropriate error is dumped on console.
|
|
5. In case of hard failure, SoC is issued RESET REQUEST after
|
|
dumping error on the console.
|
|
6. KEY REVOCATION Feature:
|
|
QorIQ platforms like B4/T4 have support of srk key table and key
|
|
revocation in ISBC code in Silicon.
|
|
The srk key table allows the user to have a key table with multiple
|
|
keys and revoke any key in case of particular key gets compromised.
|
|
In case the ISBC code uses the key revocation and srk key table to
|
|
verify the u-boot code, the subsequent chain of trust should also
|
|
use the same.
|
|
6. ISBC KEY EXTENSION Feature:
|
|
This feature allows large number of keys to be used for esbc validation
|
|
of images. A set of public keys is being signed and validated by ISBC
|
|
which can be further used for esbc validation of images.
|