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

[Tom Rini]

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/kaslr-
> >>>> seed
> >>>>
> >>>> On Sat, May 13, 2017 at 1:07 AM, Ruchika Gupta <ruchika.gupta at 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.
> >
> 
> /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.
> 
> 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.
> 
> 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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170517/e0861198/attachment.sig>