[U-Boot] [PATCH] ARMv8/sec_firmware : Update chosen/kaslr-seed

[Mark Kettenis]

> Date: Wed, 17 May 2017 17:57:04 -0400
> From: Tom Rini <trini at konsulko.com>
> 
> On Wed, May 17, 2017 at 02:14:28PM +0100, Ard Biesheuvel wrote:
> > On 17 May 2017 at 09:23, Alexander Graf <agraf at suse.de> wrote:
> > >
> > >
> > > On 17.05.17 10:17, Peter Robinson wrote:
> > >>>>
> > >>>> -----Original Message-----
> > >>>> From: Peter Robinson [mailto:pbrobinson at gmail.com]
> > >>>> Sent: Monday, May 15, 2017 6:18 PM
> > >>>> To: Ruchika Gupta <ruchika.gupta at nxp.com>
> > >>>> Cc: u-boot at lists.denx.de; sun.york at nxp.com; Prabhakar Kushwaha
> > >>>> <prabhakar.kushwaha at 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.gupta at 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.