> Date: Wed, 17 May 2017 17:57:04 -0400 > From: Tom Rini <tr...@konsulko.com> > > On Wed, May 17, 2017 at 02:14:28PM +0100, Ard Biesheuvel wrote: > > On 17 May 2017 at 09:23, Alexander Graf <ag...@suse.de> wrote: > > > > > > > > > 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/kas= > lr- > > >>>> seed > > >>>> > > >>>> On Sat, May 13, 2017 at 1:07 AM, Ruchika Gupta <ruchika.gu...@nxp.co= > m> > > >>>> 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 devic= > es? > > >>> > > >>> 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 pass= > ed > > >>> 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 surp= > rised > > > 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. > > > > >=20 > > /chosen/kaslr-seed is used by the EFI stub to communicate a KASLR > > specific random seed to the early boot code, which is difficult to do > > any other way. It is internal ABI, but given that the contents of > > /chosen are unregulated, there is nothing preventing you from putting > > a KASLR seed there if you are not booting via EFI. > >=20 > > However, /chosen/kaslr-seed is *not* the only random seed the EFI stub > > retrieves from the platform via the EFI_RNG_PROTOCOL. There is also: > > - the physical randomization seed, which affects where the EFI stub > > relocates the kernel in physical memory, > > - the LINUX_RNG EFI configuration table, which passes a seed to the > > /dev/random routines so we have some entropy before devices are > > probed, > > - randomization of the virtual placement of the UEFI runtime services > > code/data regions. > >=20 > > IOW, EFI_RNG_PROTOCOL is used in four different ways, and populating > > /chosen/kaslr-seed directly only gives you one of those. If you are > > not booting via EFI, there is no difference given that these other > > three applications are not active anyway, but for EFI(-compatible) > > boot, we should implement the EFI_RNG_PROTOCOL instead. > > So it would be best, long term, to implement EFI_RNG_PROTOCOL so that > anyone using bootefi (Linux, GRUB, OpenBSD, etc) can get what randomness > they like, but it's not a problem for now to ad-hoc populate > /chosen/kaslr-seed as possible. Yes? Thanks!
Right; Perfect is the enemy of good enough ;) Having driver code in the tree will help implementing EFI_RNG_PROTOCOL support. Since this is someting that is important to us, I actually might actually work on in the near future. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
