Hi,
Happy new year!
For NVIDIA Tegra platforms, we need the capability to query the BL31 version (e.g. 2.7, 2.8, 2.8.x) from the NWd at runtime. I could not find an FID that returns this value.
I propose we introduce a new runtime service in bl31 that returns the version_string to the NWd to support this requirement.
Thoughts?
-Varun
Hello Varun,
Happy New Year to you too!
This sounds like a reasonable idea to me.
JFYI we introduced an interface to query TF-A semantic version in the following patch:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=dddf4...
This is available for any BLx image, not just BL31. At the time, it was just meant to be used internally within TF-A so it's missing the SMC handler to return this information to normal world.
Best regards, Sandrine
On 1/10/23 23:42, Varun Wadekar via TF-A wrote:
Hi,
Happy new year!
For NVIDIA Tegra platforms, we need the capability to query the BL31 version (e.g. 2.7, 2.8, 2.8.x) from the NWd at runtime. I could not find an FID that returns this value.
I propose we introduce a new runtime service in bl31 that returns the version_string to the NWd to support this requirement.
Thoughts?
-Varun
Hi Sandrine,
This is a good start. Can you help define the SMC FID and the return value for this use case?
Please consider the requirement to return a 3-digit value (x.y.z) to support LTS versions too.
Thanks.
-----Original Message----- From: Sandrine Bailleux sandrine.bailleux@arm.com Sent: Wednesday, 11 January 2023 8:50 AM To: Varun Wadekar vwadekar@nvidia.com Cc: tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Query BL31 version from NWd
External email: Use caution opening links or attachments
Hello Varun,
Happy New Year to you too!
This sounds like a reasonable idea to me.
JFYI we introduced an interface to query TF-A semantic version in the following patch:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.truste...
This is available for any BLx image, not just BL31. At the time, it was just meant to be used internally within TF-A so it's missing the SMC handler to return this information to normal world.
Best regards, Sandrine
On 1/10/23 23:42, Varun Wadekar via TF-A wrote:
Hi,
Happy new year!
For NVIDIA Tegra platforms, we need the capability to query the BL31 version (e.g. 2.7, 2.8, 2.8.x) from the NWd at runtime. I could not find an FID that returns this value.
I propose we introduce a new runtime service in bl31 that returns the version_string to the NWd to support this requirement.
Thoughts?
-Varun
Hi Varun,
Can you allude to the use case here you need this information for? Just so we can flush out any other information needed. With the reference of LTS I was thinking the platform was trying to find out if a security fix is supported or a hardware erratum mitigation was available. Is that the type of use case we are talking about here? Anything else?
Thanks
Joanna
From: Varun Wadekar via TF-A tf-a@lists.trustedfirmware.org Date: Wednesday, 11 January 2023 at 14:33 To: Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.org tfa-lts@lists.trustedfirmware.org, tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: Query BL31 version from NWd Hi Sandrine,
This is a good start. Can you help define the SMC FID and the return value for this use case?
Please consider the requirement to return a 3-digit value (x.y.z) to support LTS versions too.
Thanks.
-----Original Message----- From: Sandrine Bailleux sandrine.bailleux@arm.com Sent: Wednesday, 11 January 2023 8:50 AM To: Varun Wadekar vwadekar@nvidia.com Cc: tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Query BL31 version from NWd
External email: Use caution opening links or attachments
Hello Varun,
Happy New Year to you too!
This sounds like a reasonable idea to me.
JFYI we introduced an interface to query TF-A semantic version in the following patch:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.truste...
This is available for any BLx image, not just BL31. At the time, it was just meant to be used internally within TF-A so it's missing the SMC handler to return this information to normal world.
Best regards, Sandrine
On 1/10/23 23:42, Varun Wadekar via TF-A wrote:
Hi,
Happy new year!
For NVIDIA Tegra platforms, we need the capability to query the BL31 version (e.g. 2.7, 2.8, 2.8.x) from the NWd at runtime. I could not find an FID that returns this value.
I propose we introduce a new runtime service in bl31 that returns the version_string to the NWd to support this requirement.
Thoughts?
-Varun
-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
Hi Joanna,
The use case right now is to identify and log the firmware version. Eventually, this information will be used to ensure that the platform is using a feature/errata/bug fix.
-Varun
From: Joanna Farley Joanna.Farley@arm.com Sent: Wednesday, 11 January 2023 3:03 PM To: Varun Wadekar vwadekar@nvidia.com; Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Re: Query BL31 version from NWd
External email: Use caution opening links or attachments
Hi Varun,
Can you allude to the use case here you need this information for? Just so we can flush out any other information needed. With the reference of LTS I was thinking the platform was trying to find out if a security fix is supported or a hardware erratum mitigation was available. Is that the type of use case we are talking about here? Anything else?
Thanks
Joanna
From: Varun Wadekar via TF-A <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Date: Wednesday, 11 January 2023 at 14:33 To: Sandrine Bailleux <Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org <tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org>, tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Subject: [TF-A] Re: Query BL31 version from NWd Hi Sandrine,
This is a good start. Can you help define the SMC FID and the return value for this use case?
Please consider the requirement to return a 3-digit value (x.y.z) to support LTS versions too.
Thanks.
-----Original Message----- From: Sandrine Bailleux <sandrine.bailleux@arm.commailto:sandrine.bailleux@arm.com> Sent: Wednesday, 11 January 2023 8:50 AM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Query BL31 version from NWd
External email: Use caution opening links or attachments
Hello Varun,
Happy New Year to you too!
This sounds like a reasonable idea to me.
JFYI we introduced an interface to query TF-A semantic version in the following patch:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.truste...https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trustedfirmware.org%2FTF-A%2Ftrusted-firmware-a.git%2Fcommit%2F%3Fid%3Ddddf4283b043ad0a81d27bd5bb2f0c647c511e11&data=05%7C01%7Cvwadekar%40nvidia.com%7Ce9a3d0e30c954499faeb08daf3e5039b%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638090462192025132%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GN8g%2Bs5gHTuPzo5F7a0v1I6jfs1QbX4l%2FVmF%2Fh%2BB3gA%3D&reserved=0
This is available for any BLx image, not just BL31. At the time, it was just meant to be used internally within TF-A so it's missing the SMC handler to return this information to normal world.
Best regards, Sandrine
On 1/10/23 23:42, Varun Wadekar via TF-A wrote:
Hi,
Happy new year!
For NVIDIA Tegra platforms, we need the capability to query the BL31 version (e.g. 2.7, 2.8, 2.8.x) from the NWd at runtime. I could not find an FID that returns this value.
I propose we introduce a new runtime service in bl31 that returns the version_string to the NWd to support this requirement.
Thoughts?
-Varun
-- TF-A mailing list -- tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.orgmailto:tf-a-leave@lists.trustedfirmware.org
Hi Varun,
One forthcoming feature in development that may prove useful in this space is support for the Errata Management specification (aka Errata ABI) that can be seen here https://developer.arm.com/Architectures/Secure%20Monitor%20Calling%20Convent...
Work is on going and support for this is hoped to be available later this year.
If you have other needs for other runtime interrogation of the EL3 image feel free to elaborate for discussion.
Joanna
From: Varun Wadekar vwadekar@nvidia.com Date: Thursday, 12 January 2023 at 09:40 To: Joanna Farley Joanna.Farley@arm.com, Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.org tfa-lts@lists.trustedfirmware.org, tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: RE: [TF-A] Re: Query BL31 version from NWd Hi Joanna,
The use case right now is to identify and log the firmware version. Eventually, this information will be used to ensure that the platform is using a feature/errata/bug fix.
-Varun
From: Joanna Farley Joanna.Farley@arm.com Sent: Wednesday, 11 January 2023 3:03 PM To: Varun Wadekar vwadekar@nvidia.com; Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Re: Query BL31 version from NWd
External email: Use caution opening links or attachments
Hi Varun,
Can you allude to the use case here you need this information for? Just so we can flush out any other information needed. With the reference of LTS I was thinking the platform was trying to find out if a security fix is supported or a hardware erratum mitigation was available. Is that the type of use case we are talking about here? Anything else?
Thanks
Joanna
From: Varun Wadekar via TF-A <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Date: Wednesday, 11 January 2023 at 14:33 To: Sandrine Bailleux <Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org <tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org>, tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Subject: [TF-A] Re: Query BL31 version from NWd Hi Sandrine,
This is a good start. Can you help define the SMC FID and the return value for this use case?
Please consider the requirement to return a 3-digit value (x.y.z) to support LTS versions too.
Thanks.
-----Original Message----- From: Sandrine Bailleux <sandrine.bailleux@arm.commailto:sandrine.bailleux@arm.com> Sent: Wednesday, 11 January 2023 8:50 AM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Query BL31 version from NWd
External email: Use caution opening links or attachments
Hello Varun,
Happy New Year to you too!
This sounds like a reasonable idea to me.
JFYI we introduced an interface to query TF-A semantic version in the following patch:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.truste...https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trustedfirmware.org%2FTF-A%2Ftrusted-firmware-a.git%2Fcommit%2F%3Fid%3Ddddf4283b043ad0a81d27bd5bb2f0c647c511e11&data=05%7C01%7Cvwadekar%40nvidia.com%7Ce9a3d0e30c954499faeb08daf3e5039b%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638090462192025132%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GN8g%2Bs5gHTuPzo5F7a0v1I6jfs1QbX4l%2FVmF%2Fh%2BB3gA%3D&reserved=0
This is available for any BLx image, not just BL31. At the time, it was just meant to be used internally within TF-A so it's missing the SMC handler to return this information to normal world.
Best regards, Sandrine
On 1/10/23 23:42, Varun Wadekar via TF-A wrote:
Hi,
Happy new year!
For NVIDIA Tegra platforms, we need the capability to query the BL31 version (e.g. 2.7, 2.8, 2.8.x) from the NWd at runtime. I could not find an FID that returns this value.
I propose we introduce a new runtime service in bl31 that returns the version_string to the NWd to support this requirement.
Thoughts?
-Varun
-- TF-A mailing list -- tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.orgmailto:tf-a-leave@lists.trustedfirmware.org
Hi,
A bit confused. Are you saying that the capability to query the firmware version is not required? The errata management spec solves another problem IMO.
Right now, we want a way to query the firmware version so that we can ensure the right binary is getting used on a platform. One reason is to know that the errata fixes are present. But the version will be helpful to ensure that some platform features or bug fixes are also present.
Once implemented, future platforms will query the firmware version for diagnostic and documentation purposes.
-Varun
From: Joanna Farley Joanna.Farley@arm.com Sent: Thursday, 12 January 2023 10:28 AM To: Varun Wadekar vwadekar@nvidia.com; Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Re: Query BL31 version from NWd
External email: Use caution opening links or attachments
Hi Varun,
One forthcoming feature in development that may prove useful in this space is support for the Errata Management specification (aka Errata ABI) that can be seen here https://developer.arm.com/Architectures/Secure%20Monitor%20Calling%20Convent...https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.arm.com%2FArchitectures%2FSecure%2520Monitor%2520Calling%2520Convention&data=05%7C01%7Cvwadekar%40nvidia.com%7C714b3a4d209849d2602408daf487ac61%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638091160828780773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9LR6i%2BNEt9VGlDWNXh5xEnO4%2BjdBu07A42%2Fls8prGSU%3D&reserved=0
Work is on going and support for this is hoped to be available later this year.
If you have other needs for other runtime interrogation of the EL3 image feel free to elaborate for discussion.
Joanna
From: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Date: Thursday, 12 January 2023 at 09:40 To: Joanna Farley <Joanna.Farley@arm.commailto:Joanna.Farley@arm.com>, Sandrine Bailleux <Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org <tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org>, tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Subject: RE: [TF-A] Re: Query BL31 version from NWd Hi Joanna,
The use case right now is to identify and log the firmware version. Eventually, this information will be used to ensure that the platform is using a feature/errata/bug fix.
-Varun
From: Joanna Farley <Joanna.Farley@arm.commailto:Joanna.Farley@arm.com> Sent: Wednesday, 11 January 2023 3:03 PM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>; Sandrine Bailleux <Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Re: Query BL31 version from NWd
External email: Use caution opening links or attachments
Hi Varun,
Can you allude to the use case here you need this information for? Just so we can flush out any other information needed. With the reference of LTS I was thinking the platform was trying to find out if a security fix is supported or a hardware erratum mitigation was available. Is that the type of use case we are talking about here? Anything else?
Thanks
Joanna
From: Varun Wadekar via TF-A <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Date: Wednesday, 11 January 2023 at 14:33 To: Sandrine Bailleux <Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org <tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org>, tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Subject: [TF-A] Re: Query BL31 version from NWd Hi Sandrine,
This is a good start. Can you help define the SMC FID and the return value for this use case?
Please consider the requirement to return a 3-digit value (x.y.z) to support LTS versions too.
Thanks.
-----Original Message----- From: Sandrine Bailleux <sandrine.bailleux@arm.commailto:sandrine.bailleux@arm.com> Sent: Wednesday, 11 January 2023 8:50 AM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Query BL31 version from NWd
External email: Use caution opening links or attachments
Hello Varun,
Happy New Year to you too!
This sounds like a reasonable idea to me.
JFYI we introduced an interface to query TF-A semantic version in the following patch:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.truste...https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trustedfirmware.org%2FTF-A%2Ftrusted-firmware-a.git%2Fcommit%2F%3Fid%3Ddddf4283b043ad0a81d27bd5bb2f0c647c511e11&data=05%7C01%7Cvwadekar%40nvidia.com%7C714b3a4d209849d2602408daf487ac61%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638091160828780773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=a%2Buohp%2BSeDtaENbFrK99faUtP0vNox2F%2FrNfn6yR3Ik%3D&reserved=0
This is available for any BLx image, not just BL31. At the time, it was just meant to be used internally within TF-A so it's missing the SMC handler to return this information to normal world.
Best regards, Sandrine
On 1/10/23 23:42, Varun Wadekar via TF-A wrote:
Hi,
Happy new year!
For NVIDIA Tegra platforms, we need the capability to query the BL31 version (e.g. 2.7, 2.8, 2.8.x) from the NWd at runtime. I could not find an FID that returns this value.
I propose we introduce a new runtime service in bl31 that returns the version_string to the NWd to support this requirement.
Thoughts?
-Varun
-- TF-A mailing list -- tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.orgmailto:tf-a-leave@lists.trustedfirmware.org
Hi Varun,
Would it not be better to interrogate BL31 for your precise runtime requirements, such as for specific errata via the Errata ABI? I’m not sure that the version is a particularly reliable indicator of features/bug fixes/errata present in BL31, especially for LTS versions, which are targets for back-ported features.
Chris
From: Varun Wadekar via TF-A tf-a@lists.trustedfirmware.org Date: Thursday, 12 January 2023 at 11:06 To: Joanna Farley Joanna.Farley@arm.com, Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.org tfa-lts@lists.trustedfirmware.org, tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: Query BL31 version from NWd Hi,
A bit confused. Are you saying that the capability to query the firmware version is not required? The errata management spec solves another problem IMO.
Right now, we want a way to query the firmware version so that we can ensure the right binary is getting used on a platform. One reason is to know that the errata fixes are present. But the version will be helpful to ensure that some platform features or bug fixes are also present.
Once implemented, future platforms will query the firmware version for diagnostic and documentation purposes.
-Varun
From: Joanna Farley Joanna.Farley@arm.com Sent: Thursday, 12 January 2023 10:28 AM To: Varun Wadekar vwadekar@nvidia.com; Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Re: Query BL31 version from NWd
External email: Use caution opening links or attachments
Hi Varun,
One forthcoming feature in development that may prove useful in this space is support for the Errata Management specification (aka Errata ABI) that can be seen here https://developer.arm.com/Architectures/Secure%20Monitor%20Calling%20Convent...https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.arm.com%2FArchitectures%2FSecure%2520Monitor%2520Calling%2520Convention&data=05%7C01%7Cvwadekar%40nvidia.com%7C714b3a4d209849d2602408daf487ac61%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638091160828780773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9LR6i%2BNEt9VGlDWNXh5xEnO4%2BjdBu07A42%2Fls8prGSU%3D&reserved=0
Work is on going and support for this is hoped to be available later this year.
If you have other needs for other runtime interrogation of the EL3 image feel free to elaborate for discussion.
Joanna
From: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Date: Thursday, 12 January 2023 at 09:40 To: Joanna Farley <Joanna.Farley@arm.commailto:Joanna.Farley@arm.com>, Sandrine Bailleux <Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org <tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org>, tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Subject: RE: [TF-A] Re: Query BL31 version from NWd Hi Joanna,
The use case right now is to identify and log the firmware version. Eventually, this information will be used to ensure that the platform is using a feature/errata/bug fix.
-Varun
From: Joanna Farley <Joanna.Farley@arm.commailto:Joanna.Farley@arm.com> Sent: Wednesday, 11 January 2023 3:03 PM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>; Sandrine Bailleux <Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Re: Query BL31 version from NWd
External email: Use caution opening links or attachments
Hi Varun,
Can you allude to the use case here you need this information for? Just so we can flush out any other information needed. With the reference of LTS I was thinking the platform was trying to find out if a security fix is supported or a hardware erratum mitigation was available. Is that the type of use case we are talking about here? Anything else?
Thanks
Joanna
From: Varun Wadekar via TF-A <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Date: Wednesday, 11 January 2023 at 14:33 To: Sandrine Bailleux <Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org <tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org>, tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Subject: [TF-A] Re: Query BL31 version from NWd Hi Sandrine,
This is a good start. Can you help define the SMC FID and the return value for this use case?
Please consider the requirement to return a 3-digit value (x.y.z) to support LTS versions too.
Thanks.
-----Original Message----- From: Sandrine Bailleux <sandrine.bailleux@arm.commailto:sandrine.bailleux@arm.com> Sent: Wednesday, 11 January 2023 8:50 AM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Query BL31 version from NWd
External email: Use caution opening links or attachments
Hello Varun,
Happy New Year to you too!
This sounds like a reasonable idea to me.
JFYI we introduced an interface to query TF-A semantic version in the following patch:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.truste...https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trustedfirmware.org%2FTF-A%2Ftrusted-firmware-a.git%2Fcommit%2F%3Fid%3Ddddf4283b043ad0a81d27bd5bb2f0c647c511e11&data=05%7C01%7Cvwadekar%40nvidia.com%7C714b3a4d209849d2602408daf487ac61%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638091160828780773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=a%2Buohp%2BSeDtaENbFrK99faUtP0vNox2F%2FrNfn6yR3Ik%3D&reserved=0
This is available for any BLx image, not just BL31. At the time, it was just meant to be used internally within TF-A so it's missing the SMC handler to return this information to normal world.
Best regards, Sandrine
On 1/10/23 23:42, Varun Wadekar via TF-A wrote:
Hi,
Happy new year!
For NVIDIA Tegra platforms, we need the capability to query the BL31 version (e.g. 2.7, 2.8, 2.8.x) from the NWd at runtime. I could not find an FID that returns this value.
I propose we introduce a new runtime service in bl31 that returns the version_string to the NWd to support this requirement.
Thoughts?
-Varun
-- TF-A mailing list -- tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.orgmailto:tf-a-leave@lists.trustedfirmware.org
Hi,
The Errata ABI only solves part of the problem. We don't have a discovery mechanism for everything that is implemented by the firmware. For example, general bug fixes cannot be discovered. The firmware version is a good indicator. It provides some way to track the deployment across multiple programs/platforms.
LTS is better positioned as we will introduce more granularity to the firmware version thus allowing greater control over deployment. It would be great to ask the mainline to use the same versioning scheme. But the mechanism to read the firmware version at runtime is missing today.
-Varun
From: Chris Kay Chris.Kay@arm.com Sent: Thursday, 12 January 2023 11:32 AM To: Varun Wadekar vwadekar@nvidia.com; Joanna Farley Joanna.Farley@arm.com; Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Re: Query BL31 version from NWd
External email: Use caution opening links or attachments
Hi Varun,
Would it not be better to interrogate BL31 for your precise runtime requirements, such as for specific errata via the Errata ABI? I'm not sure that the version is a particularly reliable indicator of features/bug fixes/errata present in BL31, especially for LTS versions, which are targets for back-ported features.
Chris
From: Varun Wadekar via TF-A <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Date: Thursday, 12 January 2023 at 11:06 To: Joanna Farley <Joanna.Farley@arm.commailto:Joanna.Farley@arm.com>, Sandrine Bailleux <Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org <tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org>, tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Subject: [TF-A] Re: Query BL31 version from NWd Hi,
A bit confused. Are you saying that the capability to query the firmware version is not required? The errata management spec solves another problem IMO.
Right now, we want a way to query the firmware version so that we can ensure the right binary is getting used on a platform. One reason is to know that the errata fixes are present. But the version will be helpful to ensure that some platform features or bug fixes are also present.
Once implemented, future platforms will query the firmware version for diagnostic and documentation purposes.
-Varun
From: Joanna Farley <Joanna.Farley@arm.commailto:Joanna.Farley@arm.com> Sent: Thursday, 12 January 2023 10:28 AM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>; Sandrine Bailleux <Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Re: Query BL31 version from NWd
External email: Use caution opening links or attachments
Hi Varun,
One forthcoming feature in development that may prove useful in this space is support for the Errata Management specification (aka Errata ABI) that can be seen here https://developer.arm.com/Architectures/Secure%20Monitor%20Calling%20Convent...https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.arm.com%2FArchitectures%2FSecure%2520Monitor%2520Calling%2520Convention&data=05%7C01%7Cvwadekar%40nvidia.com%7C11bafd985e1f4f0d3cac08daf490b249%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638091199565180568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=R65fxJVRsgPLnpKe6HKeFt55RMXRHZP9qGrZEwiYx7g%3D&reserved=0
Work is on going and support for this is hoped to be available later this year.
If you have other needs for other runtime interrogation of the EL3 image feel free to elaborate for discussion.
Joanna
From: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Date: Thursday, 12 January 2023 at 09:40 To: Joanna Farley <Joanna.Farley@arm.commailto:Joanna.Farley@arm.com>, Sandrine Bailleux <Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org <tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org>, tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Subject: RE: [TF-A] Re: Query BL31 version from NWd Hi Joanna,
The use case right now is to identify and log the firmware version. Eventually, this information will be used to ensure that the platform is using a feature/errata/bug fix.
-Varun
From: Joanna Farley <Joanna.Farley@arm.commailto:Joanna.Farley@arm.com> Sent: Wednesday, 11 January 2023 3:03 PM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>; Sandrine Bailleux <Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Re: Query BL31 version from NWd
External email: Use caution opening links or attachments
Hi Varun,
Can you allude to the use case here you need this information for? Just so we can flush out any other information needed. With the reference of LTS I was thinking the platform was trying to find out if a security fix is supported or a hardware erratum mitigation was available. Is that the type of use case we are talking about here? Anything else?
Thanks
Joanna
From: Varun Wadekar via TF-A <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Date: Wednesday, 11 January 2023 at 14:33 To: Sandrine Bailleux <Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org <tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org>, tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Subject: [TF-A] Re: Query BL31 version from NWd Hi Sandrine,
This is a good start. Can you help define the SMC FID and the return value for this use case?
Please consider the requirement to return a 3-digit value (x.y.z) to support LTS versions too.
Thanks.
-----Original Message----- From: Sandrine Bailleux <sandrine.bailleux@arm.commailto:sandrine.bailleux@arm.com> Sent: Wednesday, 11 January 2023 8:50 AM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Query BL31 version from NWd
External email: Use caution opening links or attachments
Hello Varun,
Happy New Year to you too!
This sounds like a reasonable idea to me.
JFYI we introduced an interface to query TF-A semantic version in the following patch:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.truste...https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trustedfirmware.org%2FTF-A%2Ftrusted-firmware-a.git%2Fcommit%2F%3Fid%3Ddddf4283b043ad0a81d27bd5bb2f0c647c511e11&data=05%7C01%7Cvwadekar%40nvidia.com%7C11bafd985e1f4f0d3cac08daf490b249%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638091199565180568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MphH0c5jcuu9Vlbkx28n0n%2FskHq%2B1gZK1Jq0F5kiUfU%3D&reserved=0
This is available for any BLx image, not just BL31. At the time, it was just meant to be used internally within TF-A so it's missing the SMC handler to return this information to normal world.
Best regards, Sandrine
On 1/10/23 23:42, Varun Wadekar via TF-A wrote:
Hi,
Happy new year!
For NVIDIA Tegra platforms, we need the capability to query the BL31 version (e.g. 2.7, 2.8, 2.8.x) from the NWd at runtime. I could not find an FID that returns this value.
I propose we introduce a new runtime service in bl31 that returns the version_string to the NWd to support this requirement.
Thoughts?
-Varun
-- TF-A mailing list -- tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.orgmailto:tf-a-leave@lists.trustedfirmware.org
Hi,
On 1/12/23 13:24, Varun Wadekar via TF-A wrote:
Hi,
The Errata ABI only solves part of the problem. We don’t have a discovery mechanism for everything that is implemented by the firmware. For example, general bug fixes cannot be discovered. The firmware version is a good indicator. It provides some way to track the deployment across multiple programs/platforms.
LTS is better positioned as we will introduce more granularity to the firmware version thus allowing greater control over deployment. It would be great to ask the mainline to use the same versioning scheme. But the mechanism to read the firmware version at runtime is missing today.
I don't think that version should be used for any feature checking. We have used it in past and stop to use it because there is no control over out of tree code. And it is forcing some dependencies and someone has to keep track of features present is certain version. It is good to be aware about version but not for checking any functionality.
It means solid and stable feature discovery mechanism is preferred approach.
Thanks, Michal
Even the same version of TF-A for different platforms would have different feature set. The other way can be populating a bitmap for various feature during boot time for later use. This way we don't need someone to keep track of features.
Thanks, Manish ________________________________ From: Michal Simek via TF-A tf-a@lists.trustedfirmware.org Sent: 12 January 2023 12:43 To: Varun Wadekar vwadekar@nvidia.com; Chris Kay Chris.Kay@arm.com; Joanna Farley Joanna.Farley@arm.com; Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.org tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: Query BL31 version from NWd
Hi,
On 1/12/23 13:24, Varun Wadekar via TF-A wrote:
Hi,
The Errata ABI only solves part of the problem. We don’t have a discovery mechanism for everything that is implemented by the firmware. For example, general bug fixes cannot be discovered. The firmware version is a good indicator. It provides some way to track the deployment across multiple programs/platforms.
LTS is better positioned as we will introduce more granularity to the firmware version thus allowing greater control over deployment. It would be great to ask the mainline to use the same versioning scheme. But the mechanism to read the firmware version at runtime is missing today.
I don't think that version should be used for any feature checking. We have used it in past and stop to use it because there is no control over out of tree code. And it is forcing some dependencies and someone has to keep track of features present is certain version. It is good to be aware about version but not for checking any functionality.
It means solid and stable feature discovery mechanism is preferred approach.
Thanks, Michal -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
On 1/12/23 13:50, Manish Pandey2 wrote:
Even the same version of TF-A for different platforms would have different feature set. The other way can be populating a bitmap for various feature during boot time for later use. This way we don't need someone to keep track of features.
yep. And it is quite visible that feature presence should be layered across modules. One thing is generic tf-a features and another one is platform specific. Also through these bits features can be deprecated/removed.
Thanks, Michal
Quite reasonable that from the GP TEE Specification POV, the version number associated with a particular binary is nothing directly to do with the source code version number. All that the spec cares about is that BL3 is capable of reporting a single value that increase when changes are made that impact the BL3 binary.
Don
-----Original Message----- From: Michal Simek monstr@monstr.eu Sent: 12 January 2023 12:54 To: Manish Pandey2 Manish.Pandey2@arm.com; Varun Wadekar vwadekar@nvidia.com; Chris Kay Chris.Kay@arm.com; Joanna Farley Joanna.Farley@arm.com; Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.org Subject: [TFA-LTS] Re: [TF-A] Re: Query BL31 version from NWd
On 1/12/23 13:50, Manish Pandey2 wrote:
Even the same version of TF-A for different platforms would have different feature set. The other way can be populating a bitmap for various feature during boot time for later use. This way we don't need someone to keep track of features.
yep. And it is quite visible that feature presence should be layered across modules. One thing is generic tf-a features and another one is platform specific. Also through these bits features can be deprecated/removed.
Thanks, Michal
-- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: https://gbr01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.monstr.... p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
_______________________________________________ TF-A LTS mailing list -- tfa-lts@lists.trustedfirmware.org To unsubscribe send an email to tfa-lts-leave@lists.trustedfirmware.org CAUTION: This email originated from outside of Trustonic. The message might not be safe, be cautious of attachments and links herein. If in doubt, contact the sender by other means or discard this message, especially if the origin is unexpected and the sender is unknown.
Trustonic Limited is a company registered in England and Wales (registered number 07890730) with its registered office at Unit 1.16, St Johns Innovation Centre, Cowley Road, Cambridge, England, CB4 0WS, with VAT number GB349613479.
Regarding change of version number.
It is a GlobalPlaform (GP) TEE requirement that firmware version shall change if the s/w underlying the Trusted OS changes.
In a system where the BL31 is directly loading the a binary blob containing Trusted OS including HAL, monitor mode code etc, I think it is a requirement that it reflects all changes in BL31 in revision of its version number.
Remote and Higher level applications cannot be expected to have detailed knowledge of remote or underlying systems, but can be expected to have an understanding of safe version ranges.
In the GP spec: gpd.tee.firmware.implementation.version The detailed version number of the firmware which supports the Trusted OS implementation. This includes all privileged software involved in the secure booting and support of the TEE apart from the Trusted OS and Trusted Applications.
If this is not acceptable then more active participation in the standards setting would be helpful.
Regards
Don
-----Original Message----- From: Michal Simek monstr@monstr.eu Sent: 12 January 2023 12:44 To: Varun Wadekar vwadekar@nvidia.com; Chris Kay Chris.Kay@arm.com; Joanna Farley Joanna.Farley@arm.com; Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.org Subject: [TFA-LTS] Re: [TF-A] Re: Query BL31 version from NWd
Hi,
On 1/12/23 13:24, Varun Wadekar via TF-A wrote:
Hi,
The Errata ABI only solves part of the problem. We don’t have a discovery mechanism for everything that is implemented by the firmware. For example, general bug fixes cannot be discovered. The firmware version is a good indicator. It provides some way to track the deployment across multiple programs/platforms.
LTS is better positioned as we will introduce more granularity to the firmware version thus allowing greater control over deployment. It would be great to ask the mainline to use the same versioning scheme. But the mechanism to read the firmware version at runtime is missing today.
I don't think that version should be used for any feature checking. We have used it in past and stop to use it because there is no control over out of tree code. And it is forcing some dependencies and someone has to keep track of features present is certain version. It is good to be aware about version but not for checking any functionality.
It means solid and stable feature discovery mechanism is preferred approach.
Thanks, Michal _______________________________________________ TF-A LTS mailing list -- tfa-lts@lists.trustedfirmware.org To unsubscribe send an email to tfa-lts-leave@lists.trustedfirmware.org CAUTION: This email originated from outside of Trustonic. The message might not be safe, be cautious of attachments and links herein. If in doubt, contact the sender by other means or discard this message, especially if the origin is unexpected and the sender is unknown.
Trustonic Limited is a company registered in England and Wales (registered number 07890730) with its registered office at Unit 1.16, St Johns Innovation Centre, Cowley Road, Cambridge, England, CB4 0WS, with VAT number GB349613479.
The feature set for any one TF-A version of BL31 can always be varied from build to build. The closest thing we have to an immutable version of the software is the Git commit/tag, but it obviously doesn’t reflect how BL31 was compiled. The most that the TF-A version alone will ever tell you is which features _could be_ enabled. It’s a similar problem to the one we have with the Arm architecture version, where we can’t use it reliably for architectural feature detection – we have to run individual feature checks.
I think the only way for any version number to encode anything more than solely the possible feature set is if the platform derives a separate version number for a combination of a commit + build configuration. We could expose the TF-A version for informational/diagnostic reasons, but I would be very hesitant to encourage anybody rely on it for anything more than that.
Chris
From: Don Felton don.felton@trustonic.com Date: Thursday, 12 January 2023 at 14:49 To: Michal Simek monstr@monstr.eu, Varun Wadekar vwadekar@nvidia.com, Chris Kay Chris.Kay@arm.com, Joanna Farley Joanna.Farley@arm.com, Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.org tfa-lts@lists.trustedfirmware.org, tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: RE: [TFA-LTS] Re: [TF-A] Re: Query BL31 version from NWd Regarding change of version number.
It is a GlobalPlaform (GP) TEE requirement that firmware version shall change if the s/w underlying the Trusted OS changes.
In a system where the BL31 is directly loading the a binary blob containing Trusted OS including HAL, monitor mode code etc, I think it is a requirement that it reflects all changes in BL31 in revision of its version number.
Remote and Higher level applications cannot be expected to have detailed knowledge of remote or underlying systems, but can be expected to have an understanding of safe version ranges.
In the GP spec: gpd.tee.firmware.implementation.version The detailed version number of the firmware which supports the Trusted OS implementation. This includes all privileged software involved in the secure booting and support of the TEE apart from the Trusted OS and Trusted Applications.
If this is not acceptable then more active participation in the standards setting would be helpful.
Regards
Don
-----Original Message----- From: Michal Simek monstr@monstr.eu Sent: 12 January 2023 12:44 To: Varun Wadekar vwadekar@nvidia.com; Chris Kay Chris.Kay@arm.com; Joanna Farley Joanna.Farley@arm.com; Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.org Subject: [TFA-LTS] Re: [TF-A] Re: Query BL31 version from NWd
Hi,
On 1/12/23 13:24, Varun Wadekar via TF-A wrote:
Hi,
The Errata ABI only solves part of the problem. We don’t have a discovery mechanism for everything that is implemented by the firmware. For example, general bug fixes cannot be discovered. The firmware version is a good indicator. It provides some way to track the deployment across multiple programs/platforms.
LTS is better positioned as we will introduce more granularity to the firmware version thus allowing greater control over deployment. It would be great to ask the mainline to use the same versioning scheme. But the mechanism to read the firmware version at runtime is missing today.
I don't think that version should be used for any feature checking. We have used it in past and stop to use it because there is no control over out of tree code. And it is forcing some dependencies and someone has to keep track of features present is certain version. It is good to be aware about version but not for checking any functionality.
It means solid and stable feature discovery mechanism is preferred approach.
Thanks, Michal _______________________________________________ TF-A LTS mailing list -- tfa-lts@lists.trustedfirmware.org To unsubscribe send an email to tfa-lts-leave@lists.trustedfirmware.org CAUTION: This email originated from outside of Trustonic. The message might not be safe, be cautious of attachments and links herein. If in doubt, contact the sender by other means or discard this message, especially if the origin is unexpected and the sender is unknown.
Trustonic Limited is a company registered in England and Wales (registered number 07890730) with its registered office at Unit 1.16, St Johns Innovation Centre, Cowley Road, Cambridge, England, CB4 0WS, with VAT number GB349613479.
Just to reinforce what Chris says the TF-A release numbers (eg v2.8) both on the mainline branches and the forthcoming LTS branches are source code release numbers not binary release numbers. For that as Chris explains there is the need for further information on how that source code was built into a binary.
Joanna
From: Chris Kay Chris.Kay@arm.com Date: Thursday, 12 January 2023 at 15:45 To: Don Felton don.felton@trustonic.com, Michal Simek monstr@monstr.eu, Varun Wadekar vwadekar@nvidia.com, Joanna Farley Joanna.Farley@arm.com, Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.org tfa-lts@lists.trustedfirmware.org, tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: Re: [TFA-LTS] Re: [TF-A] Re: Query BL31 version from NWd The feature set for any one TF-A version of BL31 can always be varied from build to build. The closest thing we have to an immutable version of the software is the Git commit/tag, but it obviously doesn’t reflect how BL31 was compiled. The most that the TF-A version alone will ever tell you is which features _could be_ enabled. It’s a similar problem to the one we have with the Arm architecture version, where we can’t use it reliably for architectural feature detection – we have to run individual feature checks.
I think the only way for any version number to encode anything more than solely the possible feature set is if the platform derives a separate version number for a combination of a commit + build configuration. We could expose the TF-A version for informational/diagnostic reasons, but I would be very hesitant to encourage anybody rely on it for anything more than that.
Chris
From: Don Felton don.felton@trustonic.com Date: Thursday, 12 January 2023 at 14:49 To: Michal Simek monstr@monstr.eu, Varun Wadekar vwadekar@nvidia.com, Chris Kay Chris.Kay@arm.com, Joanna Farley Joanna.Farley@arm.com, Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.org tfa-lts@lists.trustedfirmware.org, tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: RE: [TFA-LTS] Re: [TF-A] Re: Query BL31 version from NWd Regarding change of version number.
It is a GlobalPlaform (GP) TEE requirement that firmware version shall change if the s/w underlying the Trusted OS changes.
In a system where the BL31 is directly loading the a binary blob containing Trusted OS including HAL, monitor mode code etc, I think it is a requirement that it reflects all changes in BL31 in revision of its version number.
Remote and Higher level applications cannot be expected to have detailed knowledge of remote or underlying systems, but can be expected to have an understanding of safe version ranges.
In the GP spec: gpd.tee.firmware.implementation.version The detailed version number of the firmware which supports the Trusted OS implementation. This includes all privileged software involved in the secure booting and support of the TEE apart from the Trusted OS and Trusted Applications.
If this is not acceptable then more active participation in the standards setting would be helpful.
Regards
Don
-----Original Message----- From: Michal Simek monstr@monstr.eu Sent: 12 January 2023 12:44 To: Varun Wadekar vwadekar@nvidia.com; Chris Kay Chris.Kay@arm.com; Joanna Farley Joanna.Farley@arm.com; Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.org Subject: [TFA-LTS] Re: [TF-A] Re: Query BL31 version from NWd
Hi,
On 1/12/23 13:24, Varun Wadekar via TF-A wrote:
Hi,
The Errata ABI only solves part of the problem. We don’t have a discovery mechanism for everything that is implemented by the firmware. For example, general bug fixes cannot be discovered. The firmware version is a good indicator. It provides some way to track the deployment across multiple programs/platforms.
LTS is better positioned as we will introduce more granularity to the firmware version thus allowing greater control over deployment. It would be great to ask the mainline to use the same versioning scheme. But the mechanism to read the firmware version at runtime is missing today.
I don't think that version should be used for any feature checking. We have used it in past and stop to use it because there is no control over out of tree code. And it is forcing some dependencies and someone has to keep track of features present is certain version. It is good to be aware about version but not for checking any functionality.
It means solid and stable feature discovery mechanism is preferred approach.
Thanks, Michal _______________________________________________ TF-A LTS mailing list -- tfa-lts@lists.trustedfirmware.org To unsubscribe send an email to tfa-lts-leave@lists.trustedfirmware.org CAUTION: This email originated from outside of Trustonic. The message might not be safe, be cautious of attachments and links herein. If in doubt, contact the sender by other means or discard this message, especially if the origin is unexpected and the sender is unknown.
Trustonic Limited is a company registered in England and Wales (registered number 07890730) with its registered office at Unit 1.16, St Johns Innovation Centre, Cowley Road, Cambridge, England, CB4 0WS, with VAT number GB349613479.
I think we should think about a solution to reliably determine git commit, version, and build configuration. For example, from a security perspective were security relevant build options enabled?
BRANCH_PROTECTION DEBUG ENABLE_FEAT_CSV2_2 ENABLE_FEAT_DIT ENABLE_FEAT_PAN ENABLE_FEAT_SB ENABLE_STACK_PROTECTOR TRUSTED_BOARD_BOOT SUPPORT_STACK_MEMTAG ERRATA_SPECULATIVE_AT
Stuart
On 1/12/23 10:24 AM, Joanna Farley via TF-A wrote:
Just to reinforce what Chris says the TF-A release numbers (eg v2.8) both on the mainline branches and the forthcoming LTS branches are source code release numbers not binary release numbers. For that as Chris explains there is the need for further information on how that source code was built into a binary.
Joanna
*From: *Chris Kay Chris.Kay@arm.com *Date: *Thursday, 12 January 2023 at 15:45 *To: *Don Felton don.felton@trustonic.com, Michal Simek monstr@monstr.eu, Varun Wadekar vwadekar@nvidia.com, Joanna Farley Joanna.Farley@arm.com, Sandrine Bailleux Sandrine.Bailleux@arm.com *Cc: *tfa-lts@lists.trustedfirmware.org tfa-lts@lists.trustedfirmware.org, tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org *Subject: *Re: [TFA-LTS] Re: [TF-A] Re: Query BL31 version from NWd
The feature set for any one TF-A version of BL31 can always be varied from build to build. The closest thing we have to an immutable version of the software is the Git commit/tag, but it obviously doesn’t reflect how BL31 was compiled. The most that the TF-A version alone will ever tell you is which features _/could be_/ enabled. It’s a similar problem to the one we have with the Arm architecture version, where we can’t use it reliably for architectural feature detection – we have to run individual feature checks.
I think the only way for any version number to encode anything more than solely the possible feature set is if the platform derives a separate version number for a combination of a commit + build configuration. We could expose the TF-A version for informational/diagnostic reasons, but I would be very hesitant to encourage anybody rely on it for anything more than that.
Chris
*From: *Don Felton don.felton@trustonic.com *Date: *Thursday, 12 January 2023 at 14:49 *To: *Michal Simek monstr@monstr.eu, Varun Wadekar vwadekar@nvidia.com, Chris Kay Chris.Kay@arm.com, Joanna Farley Joanna.Farley@arm.com, Sandrine Bailleux Sandrine.Bailleux@arm.com *Cc: *tfa-lts@lists.trustedfirmware.org tfa-lts@lists.trustedfirmware.org, tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org *Subject: *RE: [TFA-LTS] Re: [TF-A] Re: Query BL31 version from NWd
Regarding change of version number.
It is a GlobalPlaform (GP) TEE requirement that firmware version shall change if the s/w underlying the Trusted OS changes.
In a system where the BL31 is directly loading the a binary blob containing Trusted OS including HAL, monitor mode code etc, I think it is a requirement that it reflects all changes in BL31 in revision of its version number.
Remote and Higher level applications cannot be expected to have detailed knowledge of remote or underlying systems, but can be expected to have an understanding of safe version ranges.
In the GP spec: gpd.tee.firmware.implementation.version The detailed version number of the firmware which supports the Trusted OS implementation. This includes all privileged software involved in the secure booting and support of the TEE apart from the Trusted OS and Trusted Applications.
If this is not acceptable then more active participation in the standards setting would be helpful.
Regards
Don
-----Original Message----- From: Michal Simek monstr@monstr.eu Sent: 12 January 2023 12:44 To: Varun Wadekar vwadekar@nvidia.com; Chris Kay Chris.Kay@arm.com; Joanna Farley Joanna.Farley@arm.com; Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.org Subject: [TFA-LTS] Re: [TF-A] Re: Query BL31 version from NWd
Hi,
On 1/12/23 13:24, Varun Wadekar via TF-A wrote:
Hi,
The Errata ABI only solves part of the problem. We don’t have a discovery mechanism for everything that is implemented by the firmware. For example, general bug fixes cannot be discovered. The firmware version is a good indicator. It provides some way to track the deployment across multiple programs/platforms.
LTS is better positioned as we will introduce more granularity to the firmware version thus allowing greater control over deployment. It would be great to ask the mainline to use the same versioning scheme. But the mechanism to read the firmware version at runtime is missing
today.
I don't think that version should be used for any feature checking. We have used it in past and stop to use it because there is no control over out of tree code. And it is forcing some dependencies and someone has to keep track of features present is certain version. It is good to be aware about version but not for checking any functionality.
It means solid and stable feature discovery mechanism is preferred approach.
Thanks, Michal _______________________________________________ TF-A LTS mailing list -- tfa-lts@lists.trustedfirmware.org To unsubscribe send an email to tfa-lts-leave@lists.trustedfirmware.org CAUTION: This email originated from outside of Trustonic. The message might not be safe, be cautious of attachments and links herein. If in doubt, contact the sender by other means or discard this message, especially if the origin is unexpected and the sender is unknown.
Trustonic Limited is a company registered in England and Wales (registered number 07890730) with its registered office at Unit 1.16, St Johns Innovation Centre, Cowley Road, Cambridge, England, CB4 0WS, with VAT number GB349613479.
Hi,
Thanks for the feedback. AFAIU, from the discussions so far, we have the following options.
1. PLATFORM_FIRMWARE_VERSION ABI to export the binary version used by the platform. The version number generation and traceability are left for the platforms to manage. We can assume a x.y.z format for the return value. 2. PLATFORM_FEATURES ABI to export a bitmap (? ) of the platform’s features. This will be a per-platform interpretation. 3. FIRMWARE_FEATURES ABI to export a bitmap (?) of the firmware-enabled features. This ABI can cover the build options.
We might want to club 2 and 3, but there is also value in keeping them separate.
Thoughts?
From: Stuart Yoder stuart.yoder@arm.com Sent: Thursday, 12 January 2023 4:47 PM To: Joanna Farley Joanna.Farley@arm.com; Chris Kay Chris.Kay@arm.com; Don Felton don.felton@trustonic.com; Michal Simek monstr@monstr.eu; Varun Wadekar vwadekar@nvidia.com; Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Re: [TFA-LTS] Re: Re: Query BL31 version from NWd
External email: Use caution opening links or attachments
I think we should think about a solution to reliably determine git commit, version, and build configuration. For example, from a security perspective were security relevant build options enabled?
BRANCH_PROTECTION DEBUG ENABLE_FEAT_CSV2_2 ENABLE_FEAT_DIT ENABLE_FEAT_PAN ENABLE_FEAT_SB ENABLE_STACK_PROTECTOR TRUSTED_BOARD_BOOT SUPPORT_STACK_MEMTAG ERRATA_SPECULATIVE_AT
Stuart On 1/12/23 10:24 AM, Joanna Farley via TF-A wrote: Just to reinforce what Chris says the TF-A release numbers (eg v2.8) both on the mainline branches and the forthcoming LTS branches are source code release numbers not binary release numbers. For that as Chris explains there is the need for further information on how that source code was built into a binary.
Joanna
From: Chris Kay Chris.Kay@arm.commailto:Chris.Kay@arm.com Date: Thursday, 12 January 2023 at 15:45 To: Don Felton don.felton@trustonic.commailto:don.felton@trustonic.com, Michal Simek monstr@monstr.eumailto:monstr@monstr.eu, Varun Wadekar vwadekar@nvidia.commailto:vwadekar@nvidia.com, Joanna Farley Joanna.Farley@arm.commailto:Joanna.Farley@arm.com, Sandrine Bailleux Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org, tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: Re: [TFA-LTS] Re: [TF-A] Re: Query BL31 version from NWd The feature set for any one TF-A version of BL31 can always be varied from build to build. The closest thing we have to an immutable version of the software is the Git commit/tag, but it obviously doesn’t reflect how BL31 was compiled. The most that the TF-A version alone will ever tell you is which features _could be_ enabled. It’s a similar problem to the one we have with the Arm architecture version, where we can’t use it reliably for architectural feature detection – we have to run individual feature checks.
I think the only way for any version number to encode anything more than solely the possible feature set is if the platform derives a separate version number for a combination of a commit + build configuration. We could expose the TF-A version for informational/diagnostic reasons, but I would be very hesitant to encourage anybody rely on it for anything more than that.
Chris
From: Don Felton don.felton@trustonic.commailto:don.felton@trustonic.com Date: Thursday, 12 January 2023 at 14:49 To: Michal Simek monstr@monstr.eumailto:monstr@monstr.eu, Varun Wadekar vwadekar@nvidia.commailto:vwadekar@nvidia.com, Chris Kay Chris.Kay@arm.commailto:Chris.Kay@arm.com, Joanna Farley Joanna.Farley@arm.commailto:Joanna.Farley@arm.com, Sandrine Bailleux Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org, tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: RE: [TFA-LTS] Re: [TF-A] Re: Query BL31 version from NWd Regarding change of version number.
It is a GlobalPlaform (GP) TEE requirement that firmware version shall change if the s/w underlying the Trusted OS changes.
In a system where the BL31 is directly loading the a binary blob containing Trusted OS including HAL, monitor mode code etc, I think it is a requirement that it reflects all changes in BL31 in revision of its version number.
Remote and Higher level applications cannot be expected to have detailed knowledge of remote or underlying systems, but can be expected to have an understanding of safe version ranges.
In the GP spec: gpd.tee.firmware.implementation.version The detailed version number of the firmware which supports the Trusted OS implementation. This includes all privileged software involved in the secure booting and support of the TEE apart from the Trusted OS and Trusted Applications.
If this is not acceptable then more active participation in the standards setting would be helpful.
Regards
Don
-----Original Message----- From: Michal Simek monstr@monstr.eumailto:monstr@monstr.eu Sent: 12 January 2023 12:44 To: Varun Wadekar vwadekar@nvidia.commailto:vwadekar@nvidia.com; Chris Kay Chris.Kay@arm.commailto:Chris.Kay@arm.com; Joanna Farley Joanna.Farley@arm.commailto:Joanna.Farley@arm.com; Sandrine Bailleux Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: [TFA-LTS] Re: [TF-A] Re: Query BL31 version from NWd
Hi,
On 1/12/23 13:24, Varun Wadekar via TF-A wrote:
Hi,
The Errata ABI only solves part of the problem. We don’t have a discovery mechanism for everything that is implemented by the firmware. For example, general bug fixes cannot be discovered. The firmware version is a good indicator. It provides some way to track the deployment across multiple programs/platforms.
LTS is better positioned as we will introduce more granularity to the firmware version thus allowing greater control over deployment. It would be great to ask the mainline to use the same versioning scheme. But the mechanism to read the firmware version at runtime is missing today.
I don't think that version should be used for any feature checking. We have used it in past and stop to use it because there is no control over out of tree code. And it is forcing some dependencies and someone has to keep track of features present is certain version. It is good to be aware about version but not for checking any functionality.
It means solid and stable feature discovery mechanism is preferred approach.
Thanks, Michal _______________________________________________ TF-A LTS mailing list -- tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org To unsubscribe send an email to tfa-lts-leave@lists.trustedfirmware.orgmailto:tfa-lts-leave@lists.trustedfirmware.org CAUTION: This email originated from outside of Trustonic. The message might not be safe, be cautious of attachments and links herein. If in doubt, contact the sender by other means or discard this message, especially if the origin is unexpected and the sender is unknown.
Trustonic Limited is a company registered in England and Wales (registered number 07890730) with its registered office at Unit 1.16, St Johns Innovation Centre, Cowley Road, Cambridge, England, CB4 0WS, with VAT number GB349613479.
Hi All,
Just to make sure everyone is aware (as I only mentioned the “string” format as that was under discussion), and apologies if this is a non-issue.
GlobalPlatform (GP) specifies the following 3 things need to be provided by the Trusted OS to the Trusted Application, and so the Trusted OS will expect to be able to be discoverable if s/w below the Trusted OS is provided separately (as is generally the case) (From GlobalPlatform TEE Internal Core version 1.3)
gpd.tee.firmware.implementation.version
String
Since: TEE Internal Core API v1.1
The detailed version number of the firmware which supports the Trusted OS implementation. This includes all privileged software involved in the secure booting and support of the TEE apart from the Trusted OS and Trusted Applications.
The value of this property SHALL change whenever anything changes in this code, i.e. any patch SHALL change this string. The value of this property MAY be the empty string if there is no such software.
gpd.tee.firmware.implementation.binaryversion
Binary
Since: TEE Internal Core API v1.1
A binary value which is equivalent to gpd.tee.firmware.implementation.version. May be derived from some form of certificate indicating the firmware has been signed, a measurement of the image, a checksum, a direct binary conversion of gpd.tee.firmware.implementation.version, or any other binary value that the Trusted OS manufacturer chooses to provide. The Trusted OS manufacturer’s documentation SHALL state the format of this value.
The value of this property SHALL change whenever anything changes in this code, i.e. any patch SHALL change this binary. The value of this property MAY be a zero‑length value if there is no such firmware.
gpd.tee.firmware.manufacturer
String
Since: TEE Internal Core API v1.1
Name of the manufacturer of the firmware which supports the Trusted OS or the empty string if there is no such firmware.
(“No such firmware” covers cases where the Trusted OS includes directly all the TEE code and there is no lower layers. E.g. ROM based XIP Trusted OS)
There is a corresponding set for the Trusted OS itself, so that between the two sets the TA (and anything it communicates to) has only a small set of material to review.
This has been a requirement for TEE’s since June 2014 (TEE Internal Core API v1.1).
I do realise the original request was to enable discovery from the NWd but the need seems to align and so I am now concerned that if this isn’t just a matter of redirecting something that already exists then BL3 is missing SWd functionality as well.
(gpd.tee.firmware.implementation.binaryversion is assumed to hold some form of full manufacturer signed certificate but GP doesn’t specify format)
Anyway, where the BL3 is directly booting the Trusted OS (i.e. a Trusted OS that includes all the HAL inc Monitor Mode code) , then it would seem to me that it needs to provide the above material. When it boots some form of HAL F/W layer that then boots the Trusted OS, then from the Trusted OS POV, this becomes a HAL F/W layer problem (and so just something for TF-A in general to handle).
I will admit that I don’t know of anyone using the BL parts of TF-A without the runtime HAL like parts.
Don
From: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Sent: 16 January 2023 12:17 To: Stuart Yoder <stuart.yoder@arm.commailto:stuart.yoder@arm.com>; Joanna Farley <Joanna.Farley@arm.commailto:Joanna.Farley@arm.com>; Chris Kay <Chris.Kay@arm.commailto:Chris.Kay@arm.com>; Don Felton <don.felton@trustonic.commailto:don.felton@trustonic.com>; Michal Simek <monstr@monstr.eumailto:monstr@monstr.eu>; Sandrine Bailleux <Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: RE: [TF-A] Re: [TFA-LTS] Re: Re: Query BL31 version from NWd
Hi,
Thanks for the feedback. AFAIU, from the discussions so far, we have the following options.
1. PLATFORM_FIRMWARE_VERSION ABI to export the binary version used by the platform. The version number generation and traceability are left for the platforms to manage. We can assume a x.y.z format for the return value. 2. PLATFORM_FEATURES ABI to export a bitmap (? ) of the platform’s features. This will be a per-platform interpretation. 3. FIRMWARE_FEATURES ABI to export a bitmap (?) of the firmware-enabled features. This ABI can cover the build options.
We might want to club 2 and 3, but there is also value in keeping them separate.
Thoughts?
From: Stuart Yoder <stuart.yoder@arm.commailto:stuart.yoder@arm.com> Sent: Thursday, 12 January 2023 4:47 PM To: Joanna Farley <Joanna.Farley@arm.commailto:Joanna.Farley@arm.com>; Chris Kay <Chris.Kay@arm.commailto:Chris.Kay@arm.com>; Don Felton <don.felton@trustonic.commailto:don.felton@trustonic.com>; Michal Simek <monstr@monstr.eumailto:monstr@monstr.eu>; Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>; Sandrine Bailleux <Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com> Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Re: [TFA-LTS] Re: Re: Query BL31 version from NWd
External email: Use caution opening links or attachments
I think we should think about a solution to reliably determine git commit, version, and build configuration. For example, from a security perspective were security relevant build options enabled?
BRANCH_PROTECTION DEBUG ENABLE_FEAT_CSV2_2 ENABLE_FEAT_DIT ENABLE_FEAT_PAN ENABLE_FEAT_SB ENABLE_STACK_PROTECTOR TRUSTED_BOARD_BOOT SUPPORT_STACK_MEMTAG ERRATA_SPECULATIVE_AT
Stuart On 1/12/23 10:24 AM, Joanna Farley via TF-A wrote: Just to reinforce what Chris says the TF-A release numbers (eg v2.8) both on the mainline branches and the forthcoming LTS branches are source code release numbers not binary release numbers. For that as Chris explains there is the need for further information on how that source code was built into a binary.
Joanna
From: Chris Kay Chris.Kay@arm.commailto:Chris.Kay@arm.com Date: Thursday, 12 January 2023 at 15:45 To: Don Felton don.felton@trustonic.commailto:don.felton@trustonic.com, Michal Simek monstr@monstr.eumailto:monstr@monstr.eu, Varun Wadekar vwadekar@nvidia.commailto:vwadekar@nvidia.com, Joanna Farley Joanna.Farley@arm.commailto:Joanna.Farley@arm.com, Sandrine Bailleux Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org, tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: Re: [TFA-LTS] Re: [TF-A] Re: Query BL31 version from NWd The feature set for any one TF-A version of BL31 can always be varied from build to build. The closest thing we have to an immutable version of the software is the Git commit/tag, but it obviously doesn’t reflect how BL31 was compiled. The most that the TF-A version alone will ever tell you is which features _could be_ enabled. It’s a similar problem to the one we have with the Arm architecture version, where we can’t use it reliably for architectural feature detection – we have to run individual feature checks.
I think the only way for any version number to encode anything more than solely the possible feature set is if the platform derives a separate version number for a combination of a commit + build configuration. We could expose the TF-A version for informational/diagnostic reasons, but I would be very hesitant to encourage anybody rely on it for anything more than that.
Chris
From: Don Felton don.felton@trustonic.commailto:don.felton@trustonic.com Date: Thursday, 12 January 2023 at 14:49 To: Michal Simek monstr@monstr.eumailto:monstr@monstr.eu, Varun Wadekar vwadekar@nvidia.commailto:vwadekar@nvidia.com, Chris Kay Chris.Kay@arm.commailto:Chris.Kay@arm.com, Joanna Farley Joanna.Farley@arm.commailto:Joanna.Farley@arm.com, Sandrine Bailleux Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org, tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: RE: [TFA-LTS] Re: [TF-A] Re: Query BL31 version from NWd Regarding change of version number.
It is a GlobalPlaform (GP) TEE requirement that firmware version shall change if the s/w underlying the Trusted OS changes.
In a system where the BL31 is directly loading the a binary blob containing Trusted OS including HAL, monitor mode code etc, I think it is a requirement that it reflects all changes in BL31 in revision of its version number.
Remote and Higher level applications cannot be expected to have detailed knowledge of remote or underlying systems, but can be expected to have an understanding of safe version ranges.
In the GP spec: gpd.tee.firmware.implementation.version The detailed version number of the firmware which supports the Trusted OS implementation. This includes all privileged software involved in the secure booting and support of the TEE apart from the Trusted OS and Trusted Applications.
If this is not acceptable then more active participation in the standards setting would be helpful.
Regards
Don
-----Original Message----- From: Michal Simek monstr@monstr.eumailto:monstr@monstr.eu Sent: 12 January 2023 12:44 To: Varun Wadekar vwadekar@nvidia.commailto:vwadekar@nvidia.com; Chris Kay Chris.Kay@arm.commailto:Chris.Kay@arm.com; Joanna Farley Joanna.Farley@arm.commailto:Joanna.Farley@arm.com; Sandrine Bailleux Sandrine.Bailleux@arm.commailto:Sandrine.Bailleux@arm.com Cc: tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: [TFA-LTS] Re: [TF-A] Re: Query BL31 version from NWd
Hi,
On 1/12/23 13:24, Varun Wadekar via TF-A wrote:
Hi,
The Errata ABI only solves part of the problem. We don’t have a discovery mechanism for everything that is implemented by the firmware. For example, general bug fixes cannot be discovered. The firmware version is a good indicator. It provides some way to track the deployment across multiple programs/platforms.
LTS is better positioned as we will introduce more granularity to the firmware version thus allowing greater control over deployment. It would be great to ask the mainline to use the same versioning scheme. But the mechanism to read the firmware version at runtime is missing today.
I don't think that version should be used for any feature checking. We have used it in past and stop to use it because there is no control over out of tree code. And it is forcing some dependencies and someone has to keep track of features present is certain version. It is good to be aware about version but not for checking any functionality.
It means solid and stable feature discovery mechanism is preferred approach.
Thanks, Michal _______________________________________________ TF-A LTS mailing list -- tfa-lts@lists.trustedfirmware.orgmailto:tfa-lts@lists.trustedfirmware.org To unsubscribe send an email to tfa-lts-leave@lists.trustedfirmware.orgmailto:tfa-lts-leave@lists.trustedfirmware.org CAUTION: This email originated from outside of Trustonic. The message might not be safe, be cautious of attachments and links herein. If in doubt, contact the sender by other means or discard this message, especially if the origin is unexpected and the sender is unknown.
Trustonic Limited is a company registered in England and Wales (registered number 07890730) with its registered office at Unit 1.16, St Johns Innovation Centre, Cowley Road, Cambridge, England, CB4 0WS, with VAT number GB349613479.
Trustonic Limited is a company registered in England and Wales (registered number 07890730) with its registered office at Unit 1.16, St Johns Innovation Centre, Cowley Road, Cambridge, England, CB4 0WS, with VAT number GB349613479.
tf-a@lists.trustedfirmware.org
-
Chris Kay -
Don Felton -
Joanna Farley -
Manish Pandey2 -
Michal Simek -
Sandrine Bailleux -
Stuart Yoder -
Varun Wadekar