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

[Ard Biesheuvel]

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.