From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
Date: Mon, 28 Dec 2015 15:11:25 +0100 [thread overview]
Message-ID: <11016384.rorhLcDd8i@wuerfel> (raw)
In-Reply-To: <CAKv+Gu9nFaPES8u6fc7SQ0WFJVgV3O4uM2wNNoVWz8iaajyqTQ@mail.gmail.com>
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.
- 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.
- For machines that don't have strong hardware RNG, or where we don't
trust that hardware enough, we may want to have a way to feed back a
random seed into the bootloader during shutdown, the equivalent of
/etc/random-seed. On real Open Firmware, we'd do this through a
nvram variable that gets copied into a /chosen DT property, but we don't
have a generic way to do the same with u-boot. On UEFI we could probably
do it through efivars, but I'm not sure if that's accessible early
enough in the kernel, so we might need help from grub again.
Arnd
next prev parent reply other threads:[~2015-12-28 14:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-28 11:20 [RFC PATCH 00/10] arm64: implement support for KASLR Ard Biesheuvel
2015-12-28 11:20 ` [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region Ard Biesheuvel
2015-12-28 11:50 ` Arnd Bergmann
2015-12-28 12:07 ` Ard Biesheuvel
2015-12-28 14:11 ` Arnd Bergmann [this message]
2016-01-03 14:50 ` Mark Rutland
2016-01-03 15:23 ` Ard Biesheuvel
2016-01-04 12:21 ` Arnd Bergmann
2016-01-04 12:31 ` Mark Rutland
2015-12-28 11:20 ` [RFC PATCH 02/10] arm64: use more granular reservations for static page table allocations Ard Biesheuvel
2015-12-28 11:20 ` [RFC PATCH 03/10] arm64: decouple early fixmap init from linear mapping Ard Biesheuvel
2015-12-28 11:20 ` [RFC PATCH 04/10] arm64: move kernel image to base of vmalloc area Ard Biesheuvel
2015-12-28 11:20 ` [RFC PATCH 05/10] arm64: add support for module PLTs Ard Biesheuvel
2015-12-28 11:20 ` [RFC PATCH 06/10] arm64: use relative references in exception tables Ard Biesheuvel
2015-12-28 11:20 ` [RFC PATCH 07/10] arm64: use assembly time constants for Image header fields Ard Biesheuvel
2015-12-28 11:20 ` [RFC PATCH 08/10] arm64: avoid dynamic relocations in early boot code Ard Biesheuvel
2015-12-28 11:20 ` [RFC PATCH 09/10] arm64: add support for relocatable kernel Ard Biesheuvel
2015-12-28 11:20 ` [RFC PATCH 10/10] arm64: efi: invoke EFI_RNG_PROTOCOL to supply KASLR randomness Ard Biesheuvel
2015-12-28 11:28 ` [RFC PATCH 00/10] arm64: implement support for KASLR Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=11016384.rorhLcDd8i@wuerfel \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox