On 17.05.17 10:17, Peter Robinson wrote:
-----Original Message-----
From: Peter Robinson [mailto:pbrobin...@gmail.com]
Sent: Monday, May 15, 2017 6:18 PM
To: Ruchika Gupta <ruchika.gu...@nxp.com>
Cc: u-boot@lists.denx.de; sun.y...@nxp.com; Prabhakar Kushwaha
<prabhakar.kushw...@nxp.com>
Subject: Re: [U-Boot] [PATCH] ARMv8/sec_firmware : Update chosen/kaslr-
seed
On Sat, May 13, 2017 at 1:07 AM, Ruchika Gupta <ruchika.gu...@nxp.com>
wrote:
kASLR support in kernel requires a random number to be passed via
chosen/kaslr-seed propert. sec_firmware generates this random seed
which can then be passed in the device tree node
Is that functionality generic that it can be consumed by other devices?
Sec firmware is proprietary firmware which provides this random seed using HW
engine on NXP devices.
Other devices would need to generate their own random seed to be passed as this
property.
yes, my point was more shouldn't there be a generic framework for this
as the functionality isn't unique to the HW engine on the NXP devices,
even if the HW is, and kASLR is a pretty generic requirement.
I know Tom, Alexander, myself and others discussed such a thing at ELC
in Portland in February and if memory serves providing that seed via
the uefi boot services (I may have that terminology wrong) for ARMv8.
Tom/Alexander do you remember the details of that conversation, know
if anyone was working on it?
I think it's perfectly fine to have a proprietary implementation in
EL3/EL1s that uses whatever hardware provides to fetch a random number.
I'm surprised you provide that number to Linux using dt though.
So far, I was under the impression that the preferred path for kASLR is
to use the EFI_RNG_PROTOCOL protocol from the EFI stub. You are
obviously more than welcome to back that protocol implementation in an
NXP proprietary fashion with home-grown smc calls.
Let me CC Ard to clarify.
Alex
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot