From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
kernel-hardening@lists.openwall.com, will.deacon@arm.com,
catalin.marinas@arm.com, mark.rutland@arm.com,
leif.lindholm@linaro.org, keescook@chromium.org,
linux-kernel@vger.kernel.org, bhupesh.sharma@freescale.com,
stuart.yoder@freescale.com
Subject: Re: [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
Date: Mon, 28 Dec 2015 12:50:03 +0100 [thread overview]
Message-ID: <11539877.krH4qBJsp9@wuerfel> (raw)
In-Reply-To: <1451301654-32019-2-git-send-email-ard.biesheuvel@linaro.org>
On Monday 28 December 2015 12:20:45 Ard Biesheuvel wrote:
> @@ -75,8 +76,13 @@
> * private definitions which should NOT be used outside memory.h
> * files. Use virt_to_phys/phys_to_virt/__pa/__va instead.
> */
> -#define __virt_to_phys(x) (((phys_addr_t)(x) - PAGE_OFFSET + PHYS_OFFSET))
> +#define __virt_to_phys(x) ({ \
> + phys_addr_t __x = (phys_addr_t)(x); \
> + __x >= PAGE_OFFSET ? (__x - PAGE_OFFSET + PHYS_OFFSET) : \
> + (__x - KIMAGE_VADDR + PHYS_OFFSET); })
> +
> #define __phys_to_virt(x) ((unsigned long)((x) - PHYS_OFFSET + PAGE_OFFSET))
> +#define __phys_to_kimg(x) ((unsigned long)((x) - PHYS_OFFSET + KIMAGE_VADDR))
Having a conditional here is a bit unfortunate.
IIRC KASLR means something different depending on the architecture, we either randomize
the physical address, or the virtual address, or both, and that addresses different
attack scenarios. You seem to leave the physical address unchanged, which means that
an attacker that has gained access to a DMA master device can potentially still modify
the kernel without knowing the virtual address.
Similarly, you seem to leave the kernel mapped at the original virtual address and
just add a second map (or your __phys_to_virt is wrong), so if someone has the
ability to access a kernel virtual memory address from user space, they also don't
need the relocated address because they can potentially access the kernel .text
and .data through the linear mapping.
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.
Arnd
next parent reply other threads:[~2015-12-28 11:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1451301654-32019-1-git-send-email-ard.biesheuvel@linaro.org>
[not found] ` <1451301654-32019-2-git-send-email-ard.biesheuvel@linaro.org>
2015-12-28 11:50 ` Arnd Bergmann [this message]
2015-12-28 12:07 ` [RFC PATCH 01/10] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region Ard Biesheuvel
2015-12-28 14:11 ` Arnd Bergmann
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
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=11539877.krH4qBJsp9@wuerfel \
--to=arnd@arndb.de \
--cc=ard.biesheuvel@linaro.org \
--cc=bhupesh.sharma@freescale.com \
--cc=catalin.marinas@arm.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=leif.lindholm@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=stuart.yoder@freescale.com \
--cc=will.deacon@arm.com \
/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