| 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
| ||
|
Date: Fri, 3 Nov 2017 20:23:20 +0000
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: Mark Rutland <mark.rutland@....com>
Cc: Nick Desaulniers <ndesaulniers@...gle.com>,
Sami Tolvanen <samitolvanen@...gle.com>,
Kees Cook <keescook@...omium.org>,
LKML <linux-kernel@...r.kernel.org>,
Greg Hackmann <ghackmann@...gle.com>,
Matthias Kaehlcke <mka@...omium.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Marc Zyngier <marc.zyngier@....com>,
Christoffer Dall <cdall@...aro.org>
Subject: Re: [PATCH 00/15] Add support for clang LTO
On 3 November 2017 at 19:26, Mark Rutland <mark.rutland@....com> wrote:
> On Fri, Nov 03, 2017 at 11:11:45AM -0700, Nick Desaulniers wrote:
>> On Fri, Nov 3, 2017 at 11:09 AM, Mark Rutland <mark.rutland@....com> wrote:
>> ently compile
>> > What's the minimum set of patches necessary to work with clang (ignoring
>> > LTO)?
>>
>> If you have a build of clang-5, then just patch 7 in this series to
>> work around the last compiler bug. If you build clang from source
>> from master, ToT, for arm64, then none. :)
>
> Thanks for the pointers.
>
> With patch 7 I can build a defconfig from the arm64 for-next/core
> branch, but it panics (in hyp) on my Juno R1 when initialising hyp.
>
> If I build that branch with the Linaro 17.05 GCC 6.3.1 toolchain, I get
> all the way to userspace.
>
> The same is true (for both compilers) with v4.14-rc7.
>
> I guess that in Google you haven't tested on a platform with EL2
> available?
>
> [ 1.301280] kvm [1]: 8-bit VMID
> [ 1.304416] kvm [1]: IDMAP page: 809e2000
> [ 1.308406] kvm [1]: HYP VA range: 800000000000:ffffffffffff
> [ 1.315077] kvm [1]: Hyp mode initialized successfully
> [ 1.320211] Kernel panic - not syncing: HYP panic:
> [ 1.320211] PS:800003c9 PC:ffff0000089e6fd8 ESR:86000004
> [ 1.320211] FAR:ffff0000089e6fd8 HPFAR:0000000009825000 PAR:0000000000000000
> [ 1.320211] VCPU:000804fc20001221
> [ 1.320211]
> [ 1.341947] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc7-dirty #3
> [ 1.348675] Hardware name: ARM Juno development board (r1) (DT)
> [ 1.354543] Call trace:
> [ 1.356977] [<ffff000008088ea4>] dump_backtrace+0x0/0x34c
> [ 1.362333] [<ffff000008089208>] show_stack+0x18/0x20
> [ 1.367345] [<ffff0000089c73ec>] dump_stack+0xc4/0xfc
> [ 1.372357] [<ffff0000080c8e1c>] panic+0x138/0x2b4
> [ 1.377109] [<ffff0000080c8ce4>] panic+0x0/0x2b4
> [ 1.381692] SMP: stopping secondary CPUs
> [ 2.571295] SMP: failed to stop secondary CPUs 0-3,5
> [ 2.576214] Kernel Offset: disabled
> [ 2.579670] CPU features: 0x002086
> [ 2.583039] Memory Limit: none
> [ 2.586073] ---[ end Kernel panic - not syncing: HYP panic:
> [ 2.586073] PS:800003c9 PC:ffff0000089e6fd8 ESR:86000004
> [ 2.586073] FAR:ffff0000089e6fd8 HPFAR:0000000009825000 PAR:0000000000000000
> [ 2.586073] VCPU:000804fc20001221
>
> The PC in question is:
>
> [mark@...rids:~/src/linux]% uselinaro 17.05 aarch64-linux-gnu-addr2line -ife vmlinux ffff0000089e6fd8
> __init_stage2_translation
> /home/mark/src/linux/arch/arm64/kvm/hyp/s2-setup.c:38
>
> AFAICT, the generated assembly is only using PC-relative branches, and
> no absolute relocations:
>
> 0000000000000000 <__init_stage2_translation>:
> 0: d5380709 mrs x9, id_aa64mmfr0_el1
> 4: 12000928 and w8, w9, #0x7
> 8: 7100111f cmp w8, #0x4
> c: d3700928 ubfiz x8, x9, #16, #3
> 10: 54000188 b.hi 40 <__init_stage2_translation+0x40>
> 14: 9000000a adrp x10, 0 <__init_stage2_translation>
> 18: 92400929 and x9, x9, #0x7
> 1c: 9100014a add x10, x10, #0x0
> 20: f869794b ldr x11, [x10,x9,lsl #3]
> 24: 52800509 mov w9, #0x28 // #40
> 28: 321b03e0 orr w0, wzr, #0x20
> 2c: 321b03ea orr w10, wzr, #0x20
> 30: d61f0160 br x11
> 34: 52800480 mov w0, #0x24 // #36
> 38: 321e0bea orr w10, wzr, #0x1c
> 3c: 14000008 b 5c <__init_stage2_translation+0x5c>
> 40: 321c07e9 orr w9, wzr, #0x30
> 44: 14000004 b 54 <__init_stage2_translation+0x54>
> 48: 52800549 mov w9, #0x2a // #42
> 4c: 14000002 b 54 <__init_stage2_translation+0x54>
> 50: 52800589 mov w9, #0x2c // #44
> 54: 321d07ea orr w10, wzr, #0x18
> 58: 2a0903e0 mov w0, w9
> 5c: aa080148 orr x8, x10, x8
> 60: 929957ea mov x10, #0xffffffffffff3540 // #-51904
> 64: d5380729 mrs x9, id_aa64mmfr1_el1
> 68: f2b0000a movk x10, #0x8000, lsl #16
> 6c: d538072b mrs x11, id_aa64mmfr1_el1
> 70: 9148014c add x12, x10, #0x200, lsl #12
> 74: f2400d3f tst x9, #0xf
> 78: 927c0d69 and x9, x11, #0xf0
> 7c: 9a8c014a csel x10, x10, x12, eq
> 80: f100813f cmp x9, #0x20
> 84: aa0a0108 orr x8, x8, x10
> 88: 1a9f17e9 cset w9, eq
> 8c: aa094d08 orr x8, x8, x9, lsl #19
> 90: d51c2148 msr vtcr_el2, x8
> 94: d65f03c0 ret
>
> ... so I guess something is going wrong around kvm_call_hyp() where this
> is called from EL1.
>
Given that PC == FAR here, it seems kvm_call_hyp() is calling this
function at its EL1 virtual address, so I suspect the VHE alternatives
patching is miscompiled here.
Powered by blists - more mailing lists