Re: [PATCH 4.9 00/24] V4.9 backport of 32-bit arm spectre patches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/2/18 4:54 AM, Marc Zyngier wrote:
On 02/11/18 01:18, David Long wrote:
On 10/31/18 9:56 AM, David Long wrote:
From: "David A. Long" <dave.long@xxxxxxxxxx>

V4.9 backport of spectre patches from Russell M. King's spectre branch.
Patches not yet in upstream are excluded.

Marc Zyngier (2):
    ARM: KVM: invalidate BTB on guest exit for Cortex-A12/A17
    ARM: KVM: invalidate icache on guest exit for Cortex-A15

Russell King (22):
    ARM: add more CPU part numbers for Cortex and Brahma B15 CPUs
    ARM: bugs: prepare processor bug infrastructure
    ARM: bugs: hook processor bug checking into SMP and suspend paths
    ARM: bugs: add support for per-processor bug checking
    ARM: spectre: add Kconfig symbol for CPUs vulnerable to Spectre
    ARM: spectre-v2: harden branch predictor on context switches
    ARM: spectre-v2: add Cortex A8 and A15 validation of the IBE bit
    ARM: spectre-v2: harden user aborts in kernel space
    ARM: spectre-v2: add firmware based hardening
    ARM: spectre-v2: warn about incorrect context switching functions
    ARM: spectre-v2: KVM: invalidate icache on guest exit for Brahma B15
    ARM: KVM: Add SMCCC_ARCH_WORKAROUND_1 fast handling
    ARM: KVM: report support for SMCCC_ARCH_WORKAROUND_1
    ARM: spectre-v1: add speculation barrier (csdb) macros
    ARM: spectre-v1: add array_index_mask_nospec() implementation
    ARM: spectre-v1: fix syscall entry
    ARM: signal: copy registers using __copy_from_user()
    ARM: vfp: use __copy_from_user() when restoring VFP state
    ARM: oabi-compat: copy semops using __copy_from_user()
    ARM: use __inttype() in get_user()
    ARM: spectre-v1: use get_user() for __get_user()
    ARM: spectre-v1: mitigate user accesses

   arch/arm/include/asm/assembler.h   |  12 ++
   arch/arm/include/asm/barrier.h     |  32 ++++++
   arch/arm/include/asm/bugs.h        |   6 +-
   arch/arm/include/asm/cp15.h        |   3 +
   arch/arm/include/asm/cputype.h     |   8 ++
   arch/arm/include/asm/kvm_asm.h     |   2 -
   arch/arm/include/asm/kvm_host.h    |  14 ++-
   arch/arm/include/asm/kvm_mmu.h     |  23 +++-
   arch/arm/include/asm/proc-fns.h    |   4 +
   arch/arm/include/asm/system_misc.h |  15 +++
   arch/arm/include/asm/thread_info.h |   4 +-
   arch/arm/include/asm/uaccess.h     |  26 +++--
   arch/arm/kernel/Makefile           |   1 +
   arch/arm/kernel/bugs.c             |  18 +++
   arch/arm/kernel/entry-common.S     |  18 ++-
   arch/arm/kernel/entry-header.S     |  25 +++++
   arch/arm/kernel/signal.c           |  55 ++++-----
   arch/arm/kernel/smp.c              |   4 +
   arch/arm/kernel/suspend.c          |   2 +
   arch/arm/kernel/sys_oabi-compat.c  |   8 +-
   arch/arm/kvm/hyp/hyp-entry.S       | 110 +++++++++++++++++-
   arch/arm/lib/copy_from_user.S      |   9 ++
   arch/arm/mm/Kconfig                |  23 ++++
   arch/arm/mm/Makefile               |   2 +-
   arch/arm/mm/fault.c                |   3 +
   arch/arm/mm/proc-macros.S          |   3 +-
   arch/arm/mm/proc-v7-2level.S       |   6 -
   arch/arm/mm/proc-v7-bugs.c         | 174 +++++++++++++++++++++++++++++
   arch/arm/mm/proc-v7.S              | 154 +++++++++++++++++++------
   arch/arm/vfp/vfpmodule.c           |  17 ++-
   30 files changed, 674 insertions(+), 107 deletions(-)
   create mode 100644 arch/arm/kernel/bugs.c
   create mode 100644 arch/arm/mm/proc-v7-bugs.c


kvm-unit-test'ing of this results in a hypervisor panic that doesn't
happen without the patches. This needs to be figured out before it is
accepted into stable. Looks like a V2 will be needed. Clearly kernelci
testing alone is not sufficient when dealing with kvm changes.

How about posting the panic message, a description of what you were
doing when that happened, and details of the configuration (HW used,
Thumb-2 or not...)? If you cannot perform the analysis yourself, at
least give us enough information to help you.

Thanks,

	M.


The goal of my email was to make sure this didn't end up going out as-is in the next v4.9-stable, not to beg help debugging. But I can see how the mail might have been interpreted differently. The intent was that I was going to do the "figuring out", and ask for help when and if I needed it.

If anyone is interested though: The test is the kvm-unit-tests run on an exynos arndale 5250, built from the default config for that platform plus turning on most of the virtualization config lines I could find, and not trying to turn on any thumb-2. The problem goes away if I remove patches 12/24 and 13/24 (and probably just one of those). The kernel panic messages are below:


[ 1388.419157] Kernel panic - not syncing: [ 1388.419157] HYP panic: UNDEF PC:40000000 CPSR:000001d3
[ 1388.426742] CPU: 0 PID: 1345 Comm: qemu-system-arm Not tainted 4.9.135-00024-g0cf93698e984 #1
[ 1388.435242] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 1388.441324] [<c0222bd4>] (unwind_backtrace) from [<c021f8d8>] (show_stack+0x10/0x14)
[ 1388.449049] [<c021f8d8>] (show_stack) from [<c044a1b0>] (dump_stack+0x78/0x8c)
[ 1388.456254] [<c044a1b0>] (dump_stack) from [<c02b02b4>] (panic+0xdc/0x258)
[ 1388.463104] [<c02b02b4>] (panic) from [<c020fa98>] (kvm_arch_vcpu_ioctl_run+0xa4/0x468)
[ 1388.471096] [<c020fa98>] (kvm_arch_vcpu_ioctl_run) from [<c0208dc4>] (kvm_vcpu_ioctl+0x374/0x6fc)
[ 1388.479950] [<c0208dc4>] (kvm_vcpu_ioctl) from [<c03100ac>] (do_vfs_ioctl+0x9c/0x7e4)
[ 1388.487760] [<c03100ac>] (do_vfs_ioctl) from [<c0310828>] (SyS_ioctl+0x34/0x58)
[ 1388.495052] [<c0310828>] (SyS_ioctl) from [<c021c8c0>] (ret_fast_syscall+0x0/0x40)
[ 1388.502604] CPU1: stopping
[ 1388.505285] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.9.135-00024-g0cf93698e984 #1
[ 1388.513014] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 1388.519091] [<c0222bd4>] (unwind_backtrace) from [<c021f8d8>] (show_stack+0x10/0x14)
[ 1388.526820] [<c021f8d8>] (show_stack) from [<c044a1b0>] (dump_stack+0x78/0x8c)
[ 1388.534025] [<c044a1b0>] (dump_stack) from [<c0221e98>] (handle_IPI+0x198/0x1ac)
[ 1388.541401] [<c0221e98>] (handle_IPI) from [<c0201540>] (gic_handle_irq+0x94/0x98)
[ 1388.548953] [<c0201540>] (gic_handle_irq) from [<c0220378>] (__irq_svc+0x58/0x8c)
[ 1388.556415] Exception stack(0xee89bf50 to 0xee89bf98)
[ 1388.561443] bf40:                                     00000000 c10308b4 00000001 2e193000
[ 1388.569610] bf60: ffffe000 c1003bf4 00000000 00000143 00000000 eeffb148 49344906 c10308b4
[ 1388.577768] bf80: fffffff5 ee89bfa0 c065b03c c065b12c 600d0013 ffffffff
[ 1388.584365] [<c0220378>] (__irq_svc) from [<c065b12c>] (cpuidle_enter_state+0x264/0x320)
[ 1388.592443] [<c065b12c>] (cpuidle_enter_state) from [<c026a1c4>] (cpu_startup_entry+0x168/0x228)
[ 1388.601208] [<c026a1c4>] (cpu_startup_entry) from [<402016ec>] (0x402016ec)
[ 1388.608161] ---[ end Kernel panic - not syncing: [ 1388.608161] HYP panic: UNDEF PC:40000000 CPSR:000001d3
[ 1388.619517] ------------[ cut here ]------------
[ 1388.622669] WARNING: CPU: 0 PID: 1345 at kernel/workqueue.c:857 wq_worker_waking_up+0x78/0x80
[ 1388.631175] Modules linked in: s5p_mfc videobuf2_dma_contig v4l2_common videobuf2_memops videobuf2_v4l2 videobuf2_core vid
eodev media
[ 1388.643146] CPU: 0 PID: 1345 Comm: qemu-system-arm Not tainted 4.9.135-00024-g0cf93698e984 #1
[ 1388.651660] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 1388.657735] [<c0222bd4>] (unwind_backtrace) from [<c021f8d8>] (show_stack+0x10/0x14)
[ 1388.665467] [<c021f8d8>] (show_stack) from [<c044a1b0>] (dump_stack+0x78/0x8c)
[ 1388.672670] [<c044a1b0>] (dump_stack) from [<c0230070>] (__warn+0xe8/0x100)
[ 1388.679608] [<c0230070>] (__warn) from [<c0230138>] (warn_slowpath_null+0x20/0x28)
[ 1388.687164] [<c0230138>] (warn_slowpath_null) from [<c0246b28>] (wq_worker_waking_up+0x78/0x80)
[ 1388.695850] [<c0246b28>] (wq_worker_waking_up) from [<c0251cd0>] (ttwu_do_activate+0x58/0x70)
[ 1388.704354] [<c0251cd0>] (ttwu_do_activate) from [<c0253898>] (try_to_wake_up+0x19c/0x290)
[ 1388.712598] [<c0253898>] (try_to_wake_up) from [<c0269a84>] (autoremove_wake_function+0xc/0x34)
[ 1388.721280] [<c0269a84>] (autoremove_wake_function) from [<c0269494>] (__wake_up_common+0x4c/0x80)
[ 1388.730220] [<c0269494>] (__wake_up_common) from [<c0269500>] (__wake_up+0x38/0x4c)
[ 1388.737858] [<c0269500>] (__wake_up) from [<c06325b0>] (i2c_s3c_irq_nextbyte+0x488/0x4bc)
[ 1388.746016] [<c06325b0>] (i2c_s3c_irq_nextbyte) from [<c063332c>] (s3c24xx_i2c_irq+0x34/0x78)
[ 1388.754523] [<c063332c>] (s3c24xx_i2c_irq) from [<c0278688>] (__handle_irq_event_percpu+0x50/0x11c)
[ 1388.763550] [<c0278688>] (__handle_irq_event_percpu) from [<c0278770>] (handle_irq_event_percpu+0x1c/0x58)
[ 1388.773184] [<c0278770>] (handle_irq_event_percpu) from [<c02787e4>] (handle_irq_event+0x38/0x5c)
[ 1388.782039] [<c02787e4>] (handle_irq_event) from [<c027bb70>] (handle_fasteoi_irq+0xd0/0x1a0)
[ 1388.790544] [<c027bb70>] (handle_fasteoi_irq) from [<c0277984>] (generic_handle_irq+0x24/0x34)
[ 1388.799137] [<c0277984>] (generic_handle_irq) from [<c0277eac>] (__handle_domain_irq+0x7c/0xec)
[ 1388.807816] [<c0277eac>] (__handle_domain_irq) from [<c0201500>] (gic_handle_irq+0x54/0x98)
[ 1388.816149] [<c0201500>] (gic_handle_irq) from [<c0220378>] (__irq_svc+0x58/0x8c)
[ 1388.823611] Exception stack(0xed63be00 to 0xed63be48)
[ 1388.828641] be00: 00002bee 00000007 fac81000 c0680298 c10836d8 00005dbf c26f7ba3 000000c8
[ 1388.836806] be20: c0c04390 00000063 199996c0 00000000 00000007 ed63be50 c0222558 c0447fec
[ 1388.844963] be40: 80000153 ffffffff
[ 1388.848432] [<c0220378>] (__irq_svc) from [<c0447fec>] (__timer_delay+0x44/0x58)
[ 1388.855818] [<c0447fec>] (__timer_delay) from [<c02b0418>] (panic+0x240/0x258)
[ 1388.863022] [<c02b0418>] (panic) from [<c020fa98>] (kvm_arch_vcpu_ioctl_run+0xa4/0x468)
[ 1388.871009] [<c020fa98>] (kvm_arch_vcpu_ioctl_run) from [<c0208dc4>] (kvm_vcpu_ioctl+0x374/0x6fc)
[ 1388.879862] [<c0208dc4>] (kvm_vcpu_ioctl) from [<c03100ac>] (do_vfs_ioctl+0x9c/0x7e4)
[ 1388.887673] [<c03100ac>] (do_vfs_ioctl) from [<c0310828>] (SyS_ioctl+0x34/0x58)
[ 1388.894965] [<c0310828>] (SyS_ioctl) from [<c021c8c0>] (ret_fast_syscall+0x0/0x40)
[ 1388.902512] ---[ end trace 9f81df9f2aa3f954 ]---


Thanks,
-dl



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux