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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <11016384.rorhLcDd8i@wuerfel>
Date:	Mon, 28 Dec 2015 15:11:25 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:	"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>,
	Mark Rutland <mark.rutland@....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 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.

- 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/