Re: [PATCH 12/12] ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region

From: Catalin Marinas <catalin.marinas@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	matt@codeblueprint.co.uk, Mark Rutland <mark.rutland@arm.com>,
	roy.franz@cavium.com, rruigrok@codeaurora.org,
	Leif Lindholm <leif.lindholm@linaro.org>,
	jhugo@codeaurora.org, evgeny.kalugin@intel.com, eugene@hp.com,
	Borislav Petkov <bp@alien8.de>,
	bhsharma@redhat.com, bhe@redhat.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	james.morse@arm.com
Subject: Re: [PATCH 12/12] ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region
Date: Fri, 7 Apr 2017 16:58:09 +0100	[thread overview]
Message-ID: <CAHkRjk6E-R=7cZMnjwkjOfCdsXqpcUagn7m9cTOS8ArvrxorTQ@mail.gmail.com> (raw)
In-Reply-To: <20170404160910.28115-3-ard.biesheuvel@linaro.org>

Hi Ard,

On 4 April 2017 at 17:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> Update the allocation logic for the virtual mapping of the UEFI runtime
> services to start from a randomized base address if KASLR is in effect,
> and if the UEFI firmware exposes an implementation of EFI_RNG_PROTOCOL.
>
> This makes it more difficult to predict the location of exploitable
> data structures in the runtime UEFI firmware, which increases robustness
> against attacks. Note that these regions are only mapped during the
> time a runtime service call is in progress, and only on a single CPU
> at a time, bit give the lack of a downside, let's enable it nonetheless.
>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Matt Fleming <matt@codeblueprint.co.uk>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>  drivers/firmware/efi/libstub/arm-stub.c | 49 ++++++++++++++++++++++++---------
>  1 file changed, 36 insertions(+), 13 deletions(-)

This patch causes a boot regression on Juno and Seattle (reported by
James Morse) with defconfig. On Juno I get a Synchronous Exception
(translation fault, second level). If I build the kernel with 64K
pages, it boots ok.

See below, though likely wrapped by gmail:

EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table

Synchronous Exception at 0x00000000F82A045C

 X0 0x0000000000000000 X1 0x00000000FDF01614 X2 0x7BF580F1AD8AE581 X3
0x0000000000000000
 X4 0x0000000000000000 X5 0x00000000FDFBFC60 X6 0x42F27CEB1CE1E5BC X7
0x7BF580F1AD8AE581
 X8 0x0000000000000000 X9 0x0000000700000000 X10 0x00000000FB5C0000
X11 0x00000000FB5C5FFF
 X12 0x0000000000000000 X13 0x000000000000000E X14 0x8000000000000001
X15 0x0000000000000000
 X16 0x00000000FEFFF5E0 X17 0x0000000000000000 X18 0x0000000000000000
X19 0x00000000FDFB0018
 X20 0x00000000F8390000 X21 0x00000000FB5BDA18 X22 0x00000000FEFFF5D0
X23 0x00000009FFFF0000
 X24 0x00000000FEFFF598 X25 0x0000000000000000 X26 0x0000000000000000
X27 0x0000000000000000
 X28 0x0000000000000000 FP 0x00000000FEFFF510 LR 0x00000000F82A0454

 V0 0xA4775AF0716632D7 DB7509796C96DACB V1 0xE67211106C932C4D 4F7141B24C78074F
 V2 0x550C7DC3243185BE 12835B01D807AA98 V3 0xC19BF1749BDC06A7 80DEB1FE72BE5D74
 V4 0x240CA1CC0FC19DC6 EFBE4786E49B69C1 V5 0x76F988DA5CB0A9DC 4A7484AA2DE92C6F
 V6 0xBF597FC7B00327C8 A831C66D983E5152 V7 0x1429296706CA6351 D5A79147C6E00BF3
 V8 0x0000000000000000 2E1B213827B70A85 V9 0x0000000000000000 766A0ABB650A7354
 V10 0x0000000000000000 A81A664BA2BFE8A1 V11 0x0000000000000000 D6990624D192E819
 V12 0x0000000000000000 1E376C0819A4C116 V13 0x0000000000000000 4ED8AA4A391C0CB3
 V14 0x0000000000000000 78A5636F748F82EE V15 0x0000000000000000 A4506CEB90BEFFFA
 V16 0x3C83709547545153 BC990E9F897D4FA8 V17 0xBEBEF297C5EC0578 E1D99AE8C2B92607
 V18 0x13242833C5F05BAB 101C24C521387481 V19 0x0A50ABCAD0BDDA12 996865483E880969
 V20 0x6C4ABAA53A9BE1CB 4416D9F479B08221 V21 0x60952147C3A68574 55B8AE51435C1A1A
 V22 0x9FEB2A3B4AB8D3BF 88C1883495C7F76F V23 0xD0C224BC8FB77E09 3DB8D233CF470963
 V24 0x0E72963E02D21C93 C95B757DA62B3A12 V25 0x2A77DBA1E4EE5D5C E08479A1B557DFA8
 V26 0xB593F86668CA8129 927A0019CDEC1A76 V27 0xFF03D7BC13D5FFF6 BBA1EFEF4B817FFA
 V28 0xE3FEE1F77F5FF733 5FBC3CE8E54BBB53 V29 0x4E8582114F72CE7E EED3F6BF4B0F5BDC
 V30 0xFFFA7FFBF72FF9F7 F8F06FDB9FF5EDEA V31 0xDE3785D1AEB3DAB7 12E08FF9AD0F87FF

 SP 0x00000000FEFFF500 ELR 0x00000000F82A045C SPSR 0x60000209 FPSR 0x00000000
 ESR 0x96000006 FAR 0x0000000000000000

 ESR : EC 0x25 IL 0x1 ISS 0x00000006

Data abort: Translation fault, second level

Stack dump:
 00000FEFFF400: 996865483E880969 0A50ABCAD0BDDA12 4416D9F479B08221
6C4ABAA53A9BE1CB
 00000FEFFF420: 55B8AE51435C1A1A 60952147C3A68574 88C1883495C7F76F
9FEB2A3B4AB8D3BF
 00000FEFFF440: 3DB8D233CF470963 D0C224BC8FB77E09 C95B757DA62B3A12
0E72963E02D21C93
 00000FEFFF460: E08479A1B557DFA8 2A77DBA1E4EE5D5C 927A0019CDEC1A76
B593F86668CA8129
 00000FEFFF480: BBA1EFEF4B817FFA FF03D7BC13D5FFF6 5FBC3CE8E54BBB53
E3FEE1F77F5FF733
 00000FEFFF4A0: EED3F6BF4B0F5BDC 4E8582114F72CE7E F8F06FDB9FF5EDEA
FFFA7FFBF72FF9F7
 00000FEFFF4C0: 12E08FF9AD0F87FF DE3785D1AEB3DAB7 00000000F82A045C
0000000060000209
 00000FEFFF4E0: 0000000000000000 0000000096000006 0000000000000000
7BF580F1AD8AE581
> 00000FEFFF500: 00000000FEFFF520 00000000FDFE1658 00000000FEFFF5C0 00000000F829D4CC
 00000FEFFF520: 00000000FB5C6040 00000000FCA74698 0000000000000000
0000000000000000
 00000FEFFF540: 0000000000000000 0000000000000000 00000000000000B0
000000F2F865A8B0
 00000FEFFF560: 00000000FB5C6040 0000000000000000 0000000000000000
00000000F86C0000
 00000FEFFF580: 000000000000503F 0000000080080000 0000000000F20000
0000000000000000
 00000FEFFF5A0: 11D295625B1B31A1 3B7269C9A0003F8E 4A3823DC9042A9DE
6A5180D0DE7AFB96
 00000FEFFF5C0: 00000000FEFFF5E0 00000000FDFD3AA8 0000000080080000
00000000FB5D6C18
 00000FEFFF5E0: 00000000FEFFF660 00000000F859C830 00000000F865A8B0
0000000000000000

Thanks,

Catalin