Hi Raghu,
Thanks for reviewing the proposal. Please find my answers below.
1) The idea was to use the same hash algorithm throughout all TF-A code for consistency and not introduce any new build flags. One of the initial implementations even didn't calculate the hash itself but was reading verified data provided by the Chain of Trust (CoT) for the purpose of optimisation.
Existing definition of TF_MBEDTLS_HASH_ALG_ID in 'drivers\auth\mbedtls\mbedtls_common.mk' at line #76:
ifeq (${HASH_ALG}, sha384) TF_MBEDTLS_HASH_ALG_ID := TF_MBEDTLS_SHA384 else ifeq (${HASH_ALG}, sha512) TF_MBEDTLS_HASH_ALG_ID := TF_MBEDTLS_SHA512 else TF_MBEDTLS_HASH_ALG_ID := TF_MBEDTLS_SHA256 endif
passed to 'include\drivers\auth\mbedtls\mbedtls_config.h', line #72
#define MBEDTLS_SHA256_C #if (TF_MBEDTLS_HASH_ALG_ID != TF_MBEDTLS_SHA256) #define MBEDTLS_SHA512_C #endif
and used in Mbed TLS to define MBEDTLS_MD_MAX_SIZE in 'include\mbedtls\md.h':
#if defined(MBEDTLS_SHA512_C) #define MBEDTLS_MD_MAX_SIZE 64 /* longest known is SHA512 */ #else #define MBEDTLS_MD_MAX_SIZE 32 /* longest known is SHA256 or less */ #endif
makes impossible usage HASH_ALG=sha256 for TF-A and sha512 for Measured Boot calculations, because the following chain of function calls arm_bl1_set_bl2_hash() -> crypto_mod_calc_hash() -> crypto_lib_desc.calc_hash() -> calc_hash() -> mbedtls_md_info_from_type() returns CRYPTO_ERR_HASH error caused by insufficient space in internal Mbed TLS buffers and fixing this issue needs extra modifications in make and header files.
Upgrading/changing the hash algorithm will require re-building of TF-A and re-flashing BL1 in ROM, so please explain what you mean by "potentially break measured boot on old devices in case a hash algorithm is broken"
The functionality for getting the hash algorithm from the platform (e.g. eFuses) can be added later as a platform build option and requires fixing the issue described above.
2) Yes, Measured Boot requires TF-A built with TRUSTED_BOARD_BOOT option enabled, and as BL2 image is a part of CoT it is verified by BL1.
3) Yes. Event Log implementation is based on TCG Specifications. BL2 loads images, calculates their hashes and writes data into Event Log stored in Secure memory.
4) It is planned to add fTPM service implementation to TF-A, see Javier's message: https://lists.trustedfirmware.org/pipermail/tf-a/2020-March/000339.html
Stuart could also comment on the naming convention.
5) N/A
6) Event Log is a complex structure with entries of different lengths, and TFTF test checks the length of each field against the remaining size of the Event Log's data to be processed before accessing and printing the actual data.
Thanks. Alexei.
________________________________ From: TF-A tf-a-bounces@lists.trustedfirmware.org on behalf of Raghu Krishnamurthy via TF-A tf-a@lists.trustedfirmware.org Sent: 21 March 2020 05:53 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Proposal for Measured Boot Implementation
Hi Alexei,
Thanks. This looks good at first glance. However, i do have some questions that aren't obvious to me by reading the description below and looking at code. Questions are numbered based on your original email. Perhaps these can be discussed in the TF-A forum if it is inconvenient over email.
1) Would be good if the hash alg comes from the config file. This will make the implementation "crypto agile" from the very beginning. It is common to want to upgrade/change the hash algorithm and since BL1 is in ROM, you potentially break measured boot on old devices in case a hash algorithm is broken. The other option is to get the hash algorithm from the platform, perhaps a platform gets it from eFuses as opposed to config files. 2) It looks like you are using memory allocated in the loaded DTB as the equivalent of a TPM "PCR". How is this protected from direct modification by BL2? Or is it not protected because BL2 forms a part of the Root-of-Trust for Measurement(RTM)?(since it's signature is verified by BL1?) 3) What does "Event Log" refer to? Is it the same event log proposed by TCG in the platform firmware profile ? As a general question, how close is the measured boot in TF-A/PSA going to be to TCG ? Will BL2 extend measurements for other images ? 4) Would be great not to refer to "TPM" in the measured boot implementation. Here we are implementing measured boot without a TPM, but it could be implemented with a TPM. Maybe it should be tcg event log? 5) OK. 6) What does validate event log mean here? More details ?
Thanks -Raghu
On 3/20/20 7:15 AM, Alexei Fedorov via TF-A wrote:
Hello,
I'm preparing the next set of patches for Measured Boot support in TF-A, please find some details on design and implementation below.
SHA256/384/512 hash algorithm for Measured Boot related hash calculations is passed as an existing build 'HASH_ALG' build parameter.
BL1 calculates BL2 image hash and passes these data to BL2 via FW_CONFIG/TB_FW_CONFIG device tree in new 'bl2_hash_data' byte array
added in 'fvp_fw_config.dts'.
These changes are part of the patch under review, please see https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3555
Event Log is calculated by BL2 in Secure Memory and copied to Non-secure memory. Address in Non-secure memory is calculated as:
"nt_fw_config_addr + nt_fw_config_max_size"
with values obtained from 'tb_fw_config':
nt_fw_config_addr = <0x0 0x80000000>; nt_fw_config_max_size = <0x200>;
Event Log address and size is passed by TOS_FW_CONFIG and NT_FW_CONFIG device tree in 2 new added properties:
Property name: 'tpm_event_log_addr' Value type is an unsigned 64-bit integer specifying the physical address of the Event Log.
Property name: 'tpm_event_log_size' Value type is an unsigned 32-bit integer specifying the size of the
Event Log.
/* TPM Event Log Config */ tpm_event_log { compatible = "arm,nt_fw"; tpm_event_log_addr = <0x0 0x0>; tpm_event_log_size = <0x0>; };
- TF-A provides Event Log to the BL33 (TFTF/UEFI/U-boot) in 'nt_fw_config' device tree, which address is passed by BL31 as 'arg0' parameter,
see TFTF patch:
https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/3327
- A new test which validates and prints Event Log data passed in 'nt_fw_config' to BL33 will be added to TFTF.
Please review and provide your comments on the proposed design.
Regards. Alexei.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Alexei,
Thanks for your response.
1) This is an implementation issue that can and probably should be fixed. If i understand correctly, the point of having mbedtls_md_info_from_type() and cousins is so that you don't have to hard code hash algorithms. I assume the reason TF-A is written this way is to minimize size.
Upgrading/changing the hash algorithm will require re-building of TF-A and re-flashing BL1 in ROM.
True, the way it is implemented today. I'm saying it might be worth removing this limitation. I missed the fact that this is a limitation even on TRUSTED_BOARD_BOOT today, let alone measured boot, so this is a general problem that needs to be solved. Adding sha512.c into the BL1 when MEASURED_BOOT is enabled may not be such a huge increase in size after all and may be acceptable. This will remove the limitation of tying down the code in ROM to a particular crytpo algorithm, ie make it crypto agile. Making the crypto algorithms used data driven through configs/eFuses is desirable over having them hard coded. This has a code size trade-off but if a signature scheme, key size, or hash algorithm is broken, you can create config/eFuse update without having to change ROM code, and hence NOT leaving older devices vulnerable/unsupported. What you have now is good given what we have today, but i strongly encourage the community to consider crypto-agility for BL1(which btw is not novel). This is inline with what fconf is aiming to do.
2) Thanks for clarifying. With this design, the Root-of-Trust for measurement(RTM) is the entire secure world software stack, including the config files. If the config files are in the RTM, you can use fields in the config file to indicate the crypto algoirthm, without hard-coding them at compile time. Also, note that having a huge RTM like the entire secure software stack is okay for now but definitely increases the attack surface to defeat measured boot. Ideally, you want nothing outside of BL1 to be the RTM. This can be done by providing platform hooks to "extend" the measurement into a platform specific "PCR" equivalent with IMPDEF protections(or a real TPM for that matter).
3,4,5,6) Thanks for clarifying. Question: Is it accurate to say that, ultimately, in this design, a platform will require a trusted application that talks to a real TPM or implements a fTPM, to provide the RTS(Root-of-Trust for storage) and RTR(Root-of-Trust for reporting)?
Thanks Raghu
On 3/25/20 9:01 AM, Alexei Fedorov wrote:
Hi Raghu,
Thanks for reviewing the proposal. Please find my answers below.
- The idea was to use the same hash algorithm throughout all TF-A
code for consistency and not introduce any new build flags. One of the initial implementations even didn't calculate the hash itself but was reading verified data provided by the Chain of Trust (CoT) for the purpose of optimisation.
Existing definition of TF_MBEDTLS_HASH_ALG_ID in 'drivers\auth\mbedtls\mbedtls_common.mk' at line #76:
ifeq (${HASH_ALG}, sha384) TF_MBEDTLS_HASH_ALG_ID := TF_MBEDTLS_SHA384 else ifeq (${HASH_ALG}, sha512) TF_MBEDTLS_HASH_ALG_ID := TF_MBEDTLS_SHA512 else TF_MBEDTLS_HASH_ALG_ID := TF_MBEDTLS_SHA256 endif
passed to 'include\drivers\auth\mbedtls\mbedtls_config.h', line #72
#define MBEDTLS_SHA256_C #if (TF_MBEDTLS_HASH_ALG_ID != TF_MBEDTLS_SHA256) #define MBEDTLS_SHA512_C #endif
and used in Mbed TLS to define MBEDTLS_MD_MAX_SIZE in 'include\mbedtls\md.h':
#if defined(MBEDTLS_SHA512_C) #define MBEDTLS_MD_MAX_SIZE 64 /* longest known is SHA512 */ #else #define MBEDTLS_MD_MAX_SIZE 32 /* longest known is SHA256 or less */ #endif
makes impossible usage HASH_ALG=sha256 for TF-A and sha512 for Measured Boot calculations, because the following chain of function calls arm_bl1_set_bl2_hash() -> crypto_mod_calc_hash() -> crypto_lib_desc.calc_hash() -> calc_hash() -> mbedtls_md_info_from_type() returns CRYPTO_ERR_HASH error caused by insufficient space in internal Mbed TLS buffers and fixing this issue needs extra modifications in make and header files.
Upgrading/changing the hash algorithm will require re-building of TF-A and re-flashing BL1 in ROM, so please explain what you mean by "potentially break measured boot on old devices in case a hash algorithm is broken"
The functionality for getting the hash algorithm from the platform (e.g. eFuses) can be added later as a platform build option and requires fixing the issue described above.
- Yes, Measured Boot requires TF-A built with TRUSTED_BOARD_BOOT option
enabled, and as BL2 image is a part of CoT it is verified by BL1.
- Yes. Event Log implementation is based on TCG Specifications.
BL2 loads images, calculates their hashes and writes data into Event Log stored in Secure memory.
- It is planned to add fTPM service implementation to TF-A, see
Javier's message: https://lists.trustedfirmware.org/pipermail/tf-a/2020-March/000339.html
Stuart could also comment on the naming convention.
N/A
Event Log is a complex structure with entries of different lengths, and
TFTF test checks the length of each field against the remaining size of the Event Log's data to be processed before accessing and printing the actual data.
Thanks. Alexei.
*From:* TF-A tf-a-bounces@lists.trustedfirmware.org on behalf of Raghu Krishnamurthy via TF-A tf-a@lists.trustedfirmware.org *Sent:* 21 March 2020 05:53 *To:* tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org *Subject:* Re: [TF-A] Proposal for Measured Boot Implementation Hi Alexei,
Thanks. This looks good at first glance. However, i do have some questions that aren't obvious to me by reading the description below and looking at code. Questions are numbered based on your original email. Perhaps these can be discussed in the TF-A forum if it is inconvenient over email.
- Would be good if the hash alg comes from the config file. This will
make the implementation "crypto agile" from the very beginning. It is common to want to upgrade/change the hash algorithm and since BL1 is in ROM, you potentially break measured boot on old devices in case a hash algorithm is broken. The other option is to get the hash algorithm from the platform, perhaps a platform gets it from eFuses as opposed to config files. 2) It looks like you are using memory allocated in the loaded DTB as the equivalent of a TPM "PCR". How is this protected from direct modification by BL2? Or is it not protected because BL2 forms a part of the Root-of-Trust for Measurement(RTM)?(since it's signature is verified by BL1?) 3) What does "Event Log" refer to? Is it the same event log proposed by TCG in the platform firmware profile ? As a general question, how close is the measured boot in TF-A/PSA going to be to TCG ? Will BL2 extend measurements for other images ? 4) Would be great not to refer to "TPM" in the measured boot implementation. Here we are implementing measured boot without a TPM, but it could be implemented with a TPM. Maybe it should be tcg event log? 5) OK. 6) What does validate event log mean here? More details ?
Thanks -Raghu
On 3/20/20 7:15 AM, Alexei Fedorov via TF-A wrote:
Hello,
I'm preparing the next set of patches for Measured Boot support in TF-A, please find some details on design and implementation below.
- SHA256/384/512 hash algorithm for Measured Boot related hash calculations
is passed as an existing build 'HASH_ALG' build parameter.
- BL1 calculates BL2 image hash and passes these data to BL2 via
FW_CONFIG/TB_FW_CONFIG device tree in new 'bl2_hash_data' byte array added in 'fvp_fw_config.dts'.
These changes are part of the patch under review, please see https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3555
- Event Log is calculated by BL2 in Secure Memory and copied to
Non-secure memory. Address in Non-secure memory is calculated as:
"nt_fw_config_addr + nt_fw_config_max_size"
with values obtained from 'tb_fw_config':
nt_fw_config_addr = <0x0 0x80000000>; nt_fw_config_max_size = <0x200>;
- Event Log address and size is passed by TOS_FW_CONFIG and NT_FW_CONFIG
device tree in 2 new added properties:
Property name: 'tpm_event_log_addr' Value type is an unsigned 64-bit integer specifying the physical address of the Event Log.
Property name: 'tpm_event_log_size' Value type is an unsigned 32-bit integer specifying the size of the Event Log.
/* TPM Event Log Config */ tpm_event_log { compatible = "arm,nt_fw"; tpm_event_log_addr = <0x0 0x0>; tpm_event_log_size = <0x0>; };
- TF-A provides Event Log to the BL33 (TFTF/UEFI/U-boot) in 'nt_fw_config'
device tree, which address is passed by BL31 as 'arg0' parameter, see TFTF patch:
https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/3327
- A new test which validates and prints Event Log data passed
in 'nt_fw_config' to BL33 will be added to TFTF.
Please review and provide your comments on the proposed design.
Regards. Alexei.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Raghu,
- Thanks for clarifying. With this design, the Root-of-Trust for measurement(RTM)
is the entire secure world software stack, including the config files. If the config files are in the RTM, you can use fields in the config file to indicate the crypto algoirthm, without hard-coding them at compile time. Also, note that having a huge RTM like the entire secure software stack is okay for now but definitely increases the attack surface to defeat measured boot. Ideally, you want nothing outside of BL1 to be the RTM. This can be done by providing platform hooks to "extend" the measurement into a platform specific "PCR" equivalent with IMPDEF protections(or a real TPM for that matter).
I think allowing for BL1 to write the measurement of BL2 into an implemention defined secure location sounds reasonable (including a TPM).
But, in the end some entity needs to transfer that measurement from the secure location into the real TPM and you have to trust that entity functions correctly.
I don't see how you can get out of having to trust BL2 for measured boot. You have to trust BL2 to do signature verification of all BL3x images as part of verified boot. You have to trust BL2 to accurately measure the BL3x images. Just like with BL1, ideally, BL2 would place all measurements directly into a TPM. But, the alternative is to pass the measurements in secure memory to some secure application that will do it after SEL1, SEL0 are up and running.
3,4,5,6) Thanks for clarifying. Question: Is it accurate to say that, ultimately, in this design, a platform will require a trusted application that talks to a real TPM or implements a fTPM, to provide the RTS(Root-of-Trust for storage) and RTR (Root-of-Trust for reporting)?
It needs some TPM implementation-- could be a trusted application. But, it is also valid to have a TPM that belongs to the normal world. BL2 takes measurements, places them into the TPM, then hands things off to UEFI. UEFI in turn hands things off to the OS kernel which directly operates the TPM via a kernel driver.
So, it's not necessarily a trusted application.
Thanks, Stuart
Hi Stuart,
Thanks for your response. Agree with what you are saying. So there are 2 implementation options. One where BL1 and BLX pass measurements through the DTB as the current implementation proposal specifies. The other is where each BLx hooks to the platform to "extend" the measurement, where the platform may extend it to a secure location or to a TPM directly or wherever else. The implementation currently does not *appear* to provide the platform hook for the option where BL1 (and other BL's???)write directly to a TPM/IMPDEF secure location. Perhaps the implementation here should be changed to add a platform API to extend measurements, and the arm platform implementation should write the measurements into the DTB. It would also help if the implementation used the DTB memory location to behave similar to a PCR or multiple PCR's(virtual PCR's perhaps) and BLX's extend into virtual PCR's, and finally have SEL0/SEL1 or a platform mechanism to transfer the virtual PCR's into physical PCR's.
-Raghu
On 3/25/20 1:01 PM, Stuart Yoder wrote:
Hi Raghu,
- Thanks for clarifying. With this design, the Root-of-Trust for
measurement(RTM) is the entire secure world software stack, including the config files. If the config files are in the RTM, you can use fields in the config file to indicate the crypto algoirthm, without hard-coding them at compile time. Also, note that having a huge RTM like the entire secure software stack is okay for now but definitely increases the attack surface to defeat measured boot. Ideally, you want nothing outside of BL1 to be the RTM. This can be done by providing platform hooks to "extend" the measurement into a platform specific "PCR" equivalent with IMPDEF protections(or a real TPM for that matter).
I think allowing for BL1 to write the measurement of BL2 into an implemention defined secure location sounds reasonable (including a TPM).
But, in the end some entity needs to transfer that measurement from the secure location into the real TPM and you have to trust that entity functions correctly.
I don't see how you can get out of having to trust BL2 for measured boot. You have to trust BL2 to do signature verification of all BL3x images as part of verified boot. You have to trust BL2 to accurately measure the BL3x images. Just like with BL1, ideally, BL2 would place all measurements directly into a TPM. But, the alternative is to pass the measurements in secure memory to some secure application that will do it after SEL1, SEL0 are up and running.
3,4,5,6) Thanks for clarifying. Question: Is it accurate to say that, ultimately, in this design, a platform will require a trusted application that talks to a real TPM or implements a fTPM, to provide the RTS(Root-of-Trust for storage) and RTR (Root-of-Trust for reporting)?
It needs some TPM implementation-- could be a trusted application. But, it is also valid to have a TPM that belongs to the normal world. BL2 takes measurements, places them into the TPM, then hands things off to UEFI. UEFI in turn hands things off to the OS kernel which directly operates the TPM via a kernel driver.
So, it's not necessarily a trusted application.
Thanks, Stuart
On 3/25/20 3:55 PM, Raghu Krishnamurthy wrote:
Hi Stuart,
Thanks for your response. Agree with what you are saying. So there are 2 implementation options. One where BL1 and BLX pass measurements through the DTB as the current implementation proposal specifies. The other is where each BLx hooks to the platform to "extend" the measurement, where the platform may extend it to a secure location or to a TPM directly or wherever else.
In the case of TPM measured boot, you still have to have an event log which also contains the PCR, measurement, and metadata. So, even if BL1/2 record measurements directly into the TPM an event log has to be passed forward to UEFI and the OS.
So, a mechanism is needed to pass the event log forward, and the DTB is being used for that.
The implementation currently does not *appear* to provide the platform hook for the option where BL1 (and other BL's???)write directly to a TPM/IMPDEF secure location. Perhaps the implementation here should be changed to add a platform API to extend measurements, and the arm platform implementation should write the measurements into the DTB.
I thought that the API to extend measurement was platform specific, and so the part of TF-A making the measurements was abstracted away from the underlying implementation which should be platform specific. I'll let Alexei comment further.
It would also help if the implementation used the DTB memory location to behave similar to a PCR or multiple PCR's(virtual PCR's perhaps) and BLX's extend into virtual PCR's, and finally have SEL0/SEL1 or a platform mechanism to transfer the virtual PCR's into physical PCR's.
My take on this was that the TCG event log, held in secure memory, has all the information needed to enable an SEL0/1 component transfer the measurements into the physical PCRs. Just pass the event log to SEL0/1 and it can replay the measurements into the TPM.
You have to have the event log anyway, so why would using a second mechanism like virtual PCRs to hold measurements help?
Thanks, Stuart
You have to have the event log anyway, so why would using a second mechanism like virtual PCRs to hold measurements help?
The event log can be used like you say, in the case where there is a later point in boot time such as SEL0/SEL1 or whatever talks to the fTPM/dTPM, transfers it over to the physical PCR's. In this case, you don't really need virtual PCR's. It can perhaps be used as a debug mechanism to verify what is being written into the physical PCR matches your virtual PCR(suppose there is a bug in parsing event log) and for logging the expected PCR values at different stages of boot. The implementation will also look the same in that you always invoke the platform hook to extend PCR's, as would be the case where you are extending measurements to a physical PCR as you boot(ie in BL1, BL2, BLX etc), except that the platform hook will be empty or print the value or record the measurement into a virtual PCR.
Thanks Raghu
On 3/25/20 3:21 PM, Stuart Yoder wrote:
On 3/25/20 3:55 PM, Raghu Krishnamurthy wrote:
Hi Stuart,
Thanks for your response. Agree with what you are saying. So there are 2 implementation options. One where BL1 and BLX pass measurements through the DTB as the current implementation proposal specifies. The other is where each BLx hooks to the platform to "extend" the measurement, where the platform may extend it to a secure location or to a TPM directly or wherever else.
In the case of TPM measured boot, you still have to have an event log which also contains the PCR, measurement, and metadata. So, even if BL1/2 record measurements directly into the TPM an event log has to be passed forward to UEFI and the OS.
So, a mechanism is needed to pass the event log forward, and the DTB is being used for that.
The implementation currently does not *appear* to provide the platform hook for the option where BL1 (and other BL's???)write directly to a TPM/IMPDEF secure location. Perhaps the implementation here should be changed to add a platform API to extend measurements, and the arm platform implementation should write the measurements into the DTB.
I thought that the API to extend measurement was platform specific, and so the part of TF-A making the measurements was abstracted away from the underlying implementation which should be platform specific. I'll let Alexei comment further.
It would also help if the implementation used the DTB memory location to behave similar to a PCR or multiple PCR's(virtual PCR's perhaps) and BLX's extend into virtual PCR's, and finally have SEL0/SEL1 or a platform mechanism to transfer the virtual PCR's into physical PCR's.
My take on this was that the TCG event log, held in secure memory, has all the information needed to enable an SEL0/1 component transfer the measurements into the physical PCRs. Just pass the event log to SEL0/1 and it can replay the measurements into the TPM.
You have to have the event log anyway, so why would using a second mechanism like virtual PCRs to hold measurements help?
Thanks, Stuart
Hi,
Thank you Stuart for the detailed explanation of the basis of the design considirations for Measured Boot/Event Log. Radhu, thanks for all your inputs and the proposed changes for the current design which are much appreciated. I would suggest that for now it would be practical to go ahead with the current FVP platform specific implementation of the Measured Boot which we could modify later in case of any new requirements and change request arise. For the making the crypto algorithm used data driven through platform configuration/eFuses I'm thinking of providing a new function with API which would set TCG hash algoritm based on the build option, configuration or values read from eFuses. Please share your thoughts on that.
Regards. Alexei
________________________________ From: Raghu Krishnamurthy raghu.ncstate@icloud.com Sent: 25 March 2020 22:47 To: Stuart Yoder Stuart.Yoder@arm.com; Alexei Fedorov Alexei.Fedorov@arm.com; tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Proposal for Measured Boot Implementation
You have to have the event log anyway, so why would using a second mechanism like virtual PCRs to hold measurements help?
The event log can be used like you say, in the case where there is a later point in boot time such as SEL0/SEL1 or whatever talks to the fTPM/dTPM, transfers it over to the physical PCR's. In this case, you don't really need virtual PCR's. It can perhaps be used as a debug mechanism to verify what is being written into the physical PCR matches your virtual PCR(suppose there is a bug in parsing event log) and for logging the expected PCR values at different stages of boot. The implementation will also look the same in that you always invoke the platform hook to extend PCR's, as would be the case where you are extending measurements to a physical PCR as you boot(ie in BL1, BL2, BLX etc), except that the platform hook will be empty or print the value or record the measurement into a virtual PCR.
Thanks Raghu
On 3/25/20 3:21 PM, Stuart Yoder wrote:
On 3/25/20 3:55 PM, Raghu Krishnamurthy wrote:
Hi Stuart,
Thanks for your response. Agree with what you are saying. So there are 2 implementation options. One where BL1 and BLX pass measurements through the DTB as the current implementation proposal specifies. The other is where each BLx hooks to the platform to "extend" the measurement, where the platform may extend it to a secure location or to a TPM directly or wherever else.
In the case of TPM measured boot, you still have to have an event log which also contains the PCR, measurement, and metadata. So, even if BL1/2 record measurements directly into the TPM an event log has to be passed forward to UEFI and the OS.
So, a mechanism is needed to pass the event log forward, and the DTB is being used for that.
The implementation currently does not *appear* to provide the platform hook for the option where BL1 (and other BL's???)write directly to a TPM/IMPDEF secure location. Perhaps the implementation here should be changed to add a platform API to extend measurements, and the arm platform implementation should write the measurements into the DTB.
I thought that the API to extend measurement was platform specific, and so the part of TF-A making the measurements was abstracted away from the underlying implementation which should be platform specific. I'll let Alexei comment further.
It would also help if the implementation used the DTB memory location to behave similar to a PCR or multiple PCR's(virtual PCR's perhaps) and BLX's extend into virtual PCR's, and finally have SEL0/SEL1 or a platform mechanism to transfer the virtual PCR's into physical PCR's.
My take on this was that the TCG event log, held in secure memory, has all the information needed to enable an SEL0/1 component transfer the measurements into the physical PCRs. Just pass the event log to SEL0/1 and it can replay the measurements into the TPM.
You have to have the event log anyway, so why would using a second mechanism like virtual PCRs to hold measurements help?
Thanks, Stuart
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Thanks Alexei. You proposal sounds reasonable.
-Raghu
On 3/26/20 10:39 AM, Alexei Fedorov wrote:
Hi,
Thank you Stuart for the detailed explanation of the basis of the design considirations for Measured Boot/Event Log. Radhu, thanks for all your inputs and the proposed changes for the current design which are much appreciated. I would suggest that for now it would be practical to go ahead with the current FVP platform specific implementation of the Measured Boot which we could modify later in case of any new requirements and change request arise. Forthe making the crypto algorithm used data driven through platform configuration/eFuses I'm thinking of providing a new function with API which would set TCG hash algoritm based on the build option, configuration or values read from eFuses. Please share your thoughts on that.
Regards. Alexei
*From:* Raghu Krishnamurthy raghu.ncstate@icloud.com *Sent:* 25 March 2020 22:47 *To:* Stuart Yoder Stuart.Yoder@arm.com; Alexei Fedorov Alexei.Fedorov@arm.com; tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org *Subject:* Re: [TF-A] Proposal for Measured Boot Implementation
You have to have the event log anyway, so why would using a second
> mechanism like > virtual PCRs to hold measurements help? The event log can be used like you say, in the case where there is a later point in boot time such as SEL0/SEL1 or whatever talks to the fTPM/dTPM, transfers it over to the physical PCR's. In this case, you don't really need virtual PCR's. It can perhaps be used as a debug mechanism to verify what is being written into the physical PCR matches your virtual PCR(suppose there is a bug in parsing event log) and for logging the expected PCR values at different stages of boot. The implementation will also look the same in that you always invoke the platform hook to extend PCR's, as would be the case where you are extending measurements to a physical PCR as you boot(ie in BL1, BL2, BLX etc), except that the platform hook will be empty or print the value or record the measurement into a virtual PCR.
Thanks Raghu
On 3/25/20 3:21 PM, Stuart Yoder wrote:
On 3/25/20 3:55 PM, Raghu Krishnamurthy wrote:
Hi Stuart,
Thanks for your response. Agree with what you are saying. So there are 2 implementation options. One where BL1 and BLX pass measurements through the DTB as the current implementation proposal specifies. The other is where each BLx hooks to the platform to "extend" the measurement, where the platform may extend it to a secure location or to a TPM directly or wherever else.
In the case of TPM measured boot, you still have to have an event log which also contains the PCR, measurement, and metadata. So, even if BL1/2 record measurements directly into the TPM an event log has to be passed forward to UEFI and the OS.
So, a mechanism is needed to pass the event log forward, and the DTB is being used for that.
The implementation currently does not *appear* to provide the platform hook for the option where BL1 (and other BL's???)write directly to a TPM/IMPDEF secure location. Perhaps the implementation here should be changed to add a platform API to extend measurements, and the arm platform implementation should write the measurements into the DTB.
I thought that the API to extend measurement was platform specific, and so the part of TF-A making the measurements was abstracted away from the underlying implementation which should be platform specific. I'll let Alexei comment further.
It would also help if the implementation used the DTB memory location to behave similar to a PCR or multiple PCR's(virtual PCR's perhaps) and BLX's extend into virtual PCR's, and finally have SEL0/SEL1 or a platform mechanism to transfer the virtual PCR's into physical PCR's.
My take on this was that the TCG event log, held in secure memory, has all the information needed to enable an SEL0/1 component transfer the measurements into the physical PCRs. Just pass the event log to SEL0/1 and it can replay the measurements into the TPM.
You have to have the event log anyway, so why would using a second mechanism like virtual PCRs to hold measurements help?
Thanks, Stuart
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
tf-a@lists.trustedfirmware.org
-
Alexei Fedorov -
Raghu Krishnamurthy -
Stuart Yoder