Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1300320

Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region

From Ard Biesheuvel <ard.biesheuvel@linaro.org>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
Date 2016-01-03 16:30 +0100
Message-ID <qMSLw-79E-23@gated-at.bofh.it> (permalink)
References <qKED0-1qo-17@gated-at.bofh.it> <qKED0-1qo-15@gated-at.bofh.it> <qKEMI-1Ku-37@gated-at.bofh.it> <qKGOu-3bZ-11@gated-at.bofh.it> <qMSiu-6Jn-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 3 January 2016 at 15:50, Mark Rutland <mark.rutland@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 <arnd@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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region Arnd Bergmann <arnd@arndb.de> - 2015-12-28 13:00 +0100
  Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual  base of the kernel region Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-12-28 13:10 +0100
    Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region Arnd Bergmann <arnd@arndb.de> - 2015-12-28 15:20 +0100
      Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual  base of the kernel region Mark Rutland <mark.rutland@arm.com> - 2016-01-03 16:00 +0100
        Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual  base of the kernel region Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-01-03 16:30 +0100
        Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region Arnd Bergmann <arnd@arndb.de> - 2016-01-04 13:30 +0100
          Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual  base of the kernel region Mark Rutland <mark.rutland@arm.com> - 2016-01-04 13:40 +0100

csiph-web