Hello Jens,
In this case the information whether pac/bti features are enabled will be passed to the SP via manifest, the same way as crc32 or passed and the SP can act depending on this information. Thank you for your answer!
Br, Gábor
-----Original Message----- From: Jens Wiklander jens.wiklander@linaro.org Sent: Monday, June 17, 2024 3:57 PM To: Gabor Toth Gabor.Toth2@arm.com Cc: op-tee@lists.trustedfirmware.org Subject: Re: BTI in OPTEE
Hi Gabor,
On Mon, Jun 17, 2024 at 12:25 PM Gabor Toth Gabor.Toth2@arm.com wrote:
Hi Guys,
I am working on enabling BTI (and PAC) in trusted-services and I have a question about the topic.
If BTI is disabled in OPTEE, but someone tries to load an SP which was compiled with BTI (contains the related gnu note property) it will be successful. This seems to be a security rish and I am thinking of either panicking or at least sending an error message to remind the user that the requested protection will not be enabled.
As I know there are common parts between TA-s and SP-s loaded by ldelf so I am not sure whether panicking in this scenario will result in any problems or not. What do you think of this proposal?
Couldn't this be dealt with entirely within the SP? I assume there's a way for an SP to test if BTI is enabled
Do you know of any reasons why BTI protected SP-s should be loadable by BTI disabled OPTEE?
BTI and PAC are another layer of protection, security can be maintained without it. I assume that BTI and PAC are more important in some deployments than in others so from OP-TEE point of view we can't generally say which cause of action makes the most sense. If for some reason an SP absolutely must use these security features, then I think the SP should test for that itself and panic or such if needed.
That said, the way that SPs are embedded inside the OP-TEE binary speaks for OP-TEE and SPs to always be in sync, including BTI and PAC.
Cheers, Jens