Thanks. We should wait for other maintainers/contributors to chime in as well before you decide to fix buildroot.
-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 mailto:raghu.ncstate@icloud.com >:
Adding tf-a list again.
-----Original Message-----
From: raghu.ncstate@icloud.com mailto:raghu.ncstate@icloud.com <raghu.ncstate@icloud.com mailto:raghu.ncstate@icloud.com >
Sent: Thursday, May 13, 2021 9:33 AM
To: 'Heiko Thiery' <heiko.thiery@gmail.com mailto:heiko.thiery@gmail.com >; 'tf-a-bounces@lists.trustedfirmware.org mailto:tf-a-bounces@lists.trustedfirmware.org ' <tf-a-bounces@lists.trustedfirmware.org mailto: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
mailto:heiko.thiery@gmail.com >
Sent: Thursday, May 13, 2021 8:57 AM
To: raghu.ncstate@icloud.com
mailto:raghu.ncstate@icloud.com ; tf-a-bounces@lists.trustedfirmware.org
mailto: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
mailto: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
mailto: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
mailto: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
mailto:TF-A@lists.trustedfirmware.org
>
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
>
Thanks
--
Heiko