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

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.