[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160103145008.GA1642@svinekod>
Date: Sun, 3 Jan 2016 14:50:10 +0000
From: Mark Rutland <mark.rutland@....com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Ard Biesheuvel <ard.biesheuvel@...aro.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
kernel-hardening@...ts.openwall.com,
Will Deacon <will.deacon@....com>,
Catalin Marinas <catalin.marinas@....com>,
Leif Lindholm <leif.lindholm@...aro.org>,
Kees Cook <keescook@...omium.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Sharma Bhupesh <bhupesh.sharma@...escale.com>,
Stuart Yoder <stuart.yoder@...escale.com>
Subject: Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual
base of the kernel region
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@...db.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.
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.
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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
