Hi,

Am Do., 13. Mai 2021 um 21:35 Uhr schrieb raghu.ncstate@icloud.com:

Thanks. We should wait for other maintainers/contributors to chime in as well before you decide to fix buildroot.

Nethertheless there has to be a solution for buildroot since there are buildroot defconfigs with support for older ATF versions and folks.

-Raghu

*From:* Heiko Thiery heiko.thiery@gmail.com *Sent:* Thursday, May 13, 2021 12:33 PM *To:* raghu.ncstate@icloud.com *Cc:* tf-a@lists.trustedfirmware.org *Subject:* Re: [TF-A] Stack Protector for platforms not implementing plat_get_stack_protector_canary

Hi Raghu,

Am Do., 13. Mai 2021 um 18:39 Uhr schrieb raghu.ncstate@icloud.com:

Adding tf-a list again.

-----Original Message----- From: raghu.ncstate@icloud.com raghu.ncstate@icloud.com Sent: Thursday, May 13, 2021 9:33 AM To: 'Heiko Thiery' heiko.thiery@gmail.com; ' tf-a-bounces@lists.trustedfirmware.org' < tf-a-bounces@lists.trustedfirmware.org> Subject: RE: [TF-A] Stack Protector for platforms not implementing plat_get_stack_protector_canary

Right. The point I was trying to make is the same as the comment in the C file says "this is better than nothing but not necessarily really secure". I'm just saying SSP without truly random stack canary in an open source project is as good as not having SSP 😊 From an TF-A point of view, I think we want to encourage folks to include TRNG's on their platform and we should not provide an insecure default implementation, since people may assume security properties about it if they don’t look closely enough.

ok. i understand your arguments. Then we have to see how we can solve the problem in buildroot.

Thanks

--

Heiko

Thanks Raghu

-----Original Message----- From: Heiko Thiery heiko.thiery@gmail.com Sent: Thursday, May 13, 2021 8:57 AM To: raghu.ncstate@icloud.com; tf-a-bounces@lists.trustedfirmware.org Subject: Re: [TF-A] Stack Protector for platforms not implementing plat_get_stack_protector_canary

Hi,

Am Do., 13. Mai 2021 um 17:13 Uhr schrieb raghu.ncstate@icloud.com:

...

Without a RNG, implementing a generic function as you have mentioned

below would mean returning a constant value or random numbers that are not cryptographically secure for the stack canary. Neither of those options will really provide any security benefit. In absence of a TRNG or secret seed that can be used to generate secure random numbers, I think turning off SSP is not that much worse than returning bad values.

But as you can read in the comments of some implementations, it is better to return a pseudo value than none at all. Or am I wrong there? And assuming that this is true, it would be good to have an implementation for all those who don't use TRNG like the ones at

https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/rockch... .

...

A quick google search tells me that imx8m may have a random number

generator so the platform code may need to hook up tf-a platform port to the random number.

...

-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Heiko Thiery via TF-A Sent: Thursday, May 13, 2021 12:34 AM To: tf-a@lists.trustedfirmware.org Subject: [TF-A] Stack Protector for platforms not implementing plat_get_stack_protector_canary

Hi all,

I recently encountered a build issue with the imx8m platform. Buildroot will set the SSP (Stack Smashing Protection) option to on by default in the next release. This option also turns on the ENABLE_STACK_PROTECTOR in the ATF. But since the plat_get_stack_protector_canary() function is not implemented for the imx8m for example, the build fails for this platform. My question now is: could you implement a generic function like it is implemented for

some platforms that don't have a real RNG? Or is there a concern here?

...

I must admit that I have no experience with ATF other than building and

deploying it.

...

Thanks

Heiko

TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

Thanks

Heiko