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>:

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/rockchip/common/rockchip_stack_protector.c.

>
> 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