On 3 January 2016 at 15:50, Mark Rutland <mark.rutl...@arm.com> wrote: > On Mon, Dec 28, 2015 at 03:11:25PM +0100, Arnd Bergmann wrote: >> On Monday 28 December 2015 13:07:44 Ard Biesheuvel wrote: >> > On 28 December 2015 at 12:50, Arnd Bergmann <a...@arndb.de> wrote: >> > > On Monday 28 December 2015 12:20:45 Ard Biesheuvel wrote: >> > > How about a different approach that keeps the relocatable kernel, but >> > > moves it in >> > > physical memory with the same random offset as the virtual address? That >> > > way, both >> > > would be random, and you can keep the simple virt_to_phys() function. >> > > >> > > I suppose the downside of that is that the number of random bits is then >> > > limited >> > > by the size of the first memblock, which is smaller than the vmalloc >> > > area. >> > > >> > >> > I don't see a reason to use the same virtual and physical offset >> > (other than the conditional). On arm64, it would be up to the >> > bootloader to decide where to put the Image in physical memory, and it >> > would be up to the kernel to decide whether or not to virtually remap >> > itself. >> >> I see. If we pull in the bootloader to the discussion, there are a couple >> of related points that are not directly required for your series but that >> we should keep in mind anyway: >> >> - We need to implement the randomization for each boot loader separately. >> This is probably easy enough for grub, as it can tap the same random >> number source that you use here, but a little harder for u-boot (requiring >> to implement access to hardware rng separately on each platform) and >> much harder to get done consistently in UEFI for direct kernel loading >> since there is no common upstream. > > In the GRUB case the kernel is loaded as an EFI application -- as far as I am > aware, GRUB for arm64 doesn't know anything about the Linux kernel Image > binary. >
No, it doesn't. Alexander Graf is even proposing a EFI compatible runtime in U-boot so it can run EFI-GRUB as well, so it is unlikely that something like that will get added soon. If he includes a EFI_RNG_PROTOCOL implementation, we can run these patches on U-Boot as well. > When loaded as an EFI application the EFI stub can perform the relocation, > which it already does if the kernel was laoded at an address it cannot execute > from. It looks like Ard's implemented that for v2. > Indeed. > Being (cold) booted from EFI is likely to be the most consistent case as we > have complete control over where the kernel is placed, bar some limitations > imposed by prior EFI applications or EFI itself. > >> - once we have a random number in the bootloader, we should also pass that >> through a DT property. This has been discussed multiple times in the past >> and I think we had reached consensus already but don't know if we had >> agreed on a specific DT property that contains the random number seed. > > Any links for this? I don't recall spotting this discussion. > > Thanks, > Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
