1. 14 12月, 2013 1 次提交
    • R
      ARM: fix asm/memory.h build error · b713aa0b
      Russell King 提交于
      Jason Gunthorpe reports a build failure when ARM_PATCH_PHYS_VIRT is
      not defined:
      
      In file included from arch/arm/include/asm/page.h:163:0,
                       from include/linux/mm_types.h:16,
                       from include/linux/sched.h:24,
                       from arch/arm/kernel/asm-offsets.c:13:
      arch/arm/include/asm/memory.h: In function '__virt_to_phys':
      arch/arm/include/asm/memory.h:244:40: error: 'PHYS_OFFSET' undeclared (first use in this function)
      arch/arm/include/asm/memory.h:244:40: note: each undeclared identifier is reported only once for each function it appears in
      arch/arm/include/asm/memory.h: In function '__phys_to_virt':
      arch/arm/include/asm/memory.h:249:13: error: 'PHYS_OFFSET' undeclared (first use in this function)
      
      Fixes: ca5a45c0 ("ARM: mm: use phys_addr_t appropriately in p2v and v2p conversions")
      Tested-By: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b713aa0b
  2. 13 12月, 2013 3 次提交
    • G
      KVM: x86: fix guest-initiated crash with x2apic (CVE-2013-6376) · 17d68b76
      Gleb Natapov 提交于
      A guest can cause a BUG_ON() leading to a host kernel crash.
      When the guest writes to the ICR to request an IPI, while in x2apic
      mode the following things happen, the destination is read from
      ICR2, which is a register that the guest can control.
      
      kvm_irq_delivery_to_apic_fast uses the high 16 bits of ICR2 as the
      cluster id.  A BUG_ON is triggered, which is a protection against
      accessing map->logical_map with an out-of-bounds access and manages
      to avoid that anything really unsafe occurs.
      
      The logic in the code is correct from real HW point of view. The problem
      is that KVM supports only one cluster with ID 0 in clustered mode, but
      the code that has the bug does not take this into account.
      Reported-by: NLars Bull <larsbull@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NGleb Natapov <gleb@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      17d68b76
    • A
      KVM: x86: Convert vapic synchronization to _cached functions (CVE-2013-6368) · fda4e2e8
      Andy Honig 提交于
      In kvm_lapic_sync_from_vapic and kvm_lapic_sync_to_vapic there is the
      potential to corrupt kernel memory if userspace provides an address that
      is at the end of a page.  This patches concerts those functions to use
      kvm_write_guest_cached and kvm_read_guest_cached.  It also checks the
      vapic_address specified by userspace during ioctl processing and returns
      an error to userspace if the address is not a valid GPA.
      
      This is generally not guest triggerable, because the required write is
      done by firmware that runs before the guest.  Also, it only affects AMD
      processors and oldish Intel that do not have the FlexPriority feature
      (unless you disable FlexPriority, of course; then newer processors are
      also affected).
      
      Fixes: b93463aa ('KVM: Accelerated apic support')
      Reported-by: NAndrew Honig <ahonig@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NAndrew Honig <ahonig@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      fda4e2e8
    • A
      KVM: x86: Fix potential divide by 0 in lapic (CVE-2013-6367) · b963a22e
      Andy Honig 提交于
      Under guest controllable circumstances apic_get_tmcct will execute a
      divide by zero and cause a crash.  If the guest cpuid support
      tsc deadline timers and performs the following sequence of requests
      the host will crash.
      - Set the mode to periodic
      - Set the TMICT to 0
      - Set the mode bits to 11 (neither periodic, nor one shot, nor tsc deadline)
      - Set the TMICT to non-zero.
      Then the lapic_timer.period will be 0, but the TMICT will not be.  If the
      guest then reads from the TMCCT then the host will perform a divide by 0.
      
      This patch ensures that if the lapic_timer.period is 0, then the division
      does not occur.
      Reported-by: NAndrew Honig <ahonig@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NAndrew Honig <ahonig@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      b963a22e
  3. 12 12月, 2013 5 次提交
  4. 11 12月, 2013 2 次提交
  5. 10 12月, 2013 22 次提交
  6. 09 12月, 2013 1 次提交
  7. 07 12月, 2013 6 次提交
    • G
      powerpc/512x: dts: remove misplaced IRQ spec from 'soc' node · c65ec135
      Gerhard Sittig 提交于
      the 'soc' node in the common .dtsi for MPC5121 has an '#interrupt-cells'
      property although this node is not an interrupt controller
      
      remove this erroneously placed property because starting with v3.13-rc1
      lookup and resolution of 'interrupts' specs for peripherals gets misled,
      emits 'no irq domain found' WARN() messages and breaks the boot process
      
        irq: no irq domain found for /soc@80000000 !
        ------------[ cut here ]------------
        WARNING: at drivers/of/platform.c:171
        Modules linked in:
        CPU: 0 PID: 1 Comm: swapper Tainted: G        W    3.13.0-rc1-00001-g8a66234 #8
        task: df823bb0 ti: df834000 task.ti: df834000
        NIP: c02b5190 LR: c02b5180 CTR: c01cf4e0
        REGS: df835c50 TRAP: 0700   Tainted: G        W     (3.13.0-rc1-00001-g8a66234)
        MSR: 00029032 <EE,ME,IR,DR,RI>  CR: 229a9d42  XER: 20000000
      
        GPR00: c02b5180 df835d00 df823bb0 00000000 00000000 df835b18 ffffffff 00000308
        GPR08: c0479cc0 c0480000 c0479cc0 00000308 00000308 00000000 c00040fc 00000000
        GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 df850880
        GPR24: df84d670 00000000 00000001 df8561a0 dffffccc df85089c 00000020 00000001
        NIP [c02b5190] of_device_alloc+0xf4/0x1a0
        LR [c02b5180] of_device_alloc+0xe4/0x1a0
        Call Trace:
        [df835d00] [c02b5180] of_device_alloc+0xe4/0x1a0 (unreliable)
        [df835d50] [c02b5278] of_platform_device_create_pdata+0x3c/0xc8
        [df835d70] [c02b53fc] of_platform_bus_create+0xf8/0x170
        [df835dc0] [c02b5448] of_platform_bus_create+0x144/0x170
        [df835e10] [c02b55a8] of_platform_bus_probe+0x98/0xe8
        [df835e30] [c0437508] mpc512x_init+0x28/0x1c4
        [df835e70] [c0435de8] ppc_init+0x4c/0x60
        [df835e80] [c0003b28] do_one_initcall+0x150/0x1a4
        [df835ef0] [c0432048] kernel_init_freeable+0x114/0x1c0
        [df835f30] [c0004114] kernel_init+0x18/0x124
        [df835f40] [c000e910] ret_from_kernel_thread+0x5c/0x64
        Instruction dump:
        409effd4 57c9103a 57de2834 7c89f050 7f83e378 7c972214 7f45d378 48001f55
        7c63d278 7c630034 5463d97e 687a0001 <0f1a0000> 2f990000 387b0010 939b0098
        ---[ end trace 2257f10e5a20cbdd ]---
      
        ...
        irq: no irq domain found for /soc@80000000 !
        fsl-diu-fb 80002100.display: could not get DIU IRQ
        fsl-diu-fb: probe of 80002100.display failed with error -22
        irq: no irq domain found for /soc@80000000 !
        mpc512x_dma 80014000.dma: Error mapping IRQ!
        mpc512x_dma: probe of 80014000.dma failed with error -22
        ...
        irq: no irq domain found for /soc@80000000 !
        fs_enet: probe of 80002800.ethernet failed with error -22
        ...
        irq: no irq domain found for /soc@80000000 !
        mpc5121-rtc 80000a00.rtc: mpc5121_rtc_probe: could not request irq: 0
        mpc5121-rtc: probe of 80000a00.rtc failed with error -22
        ...
      
      Cc: Anatolij Gustschin <agust@denx.de>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: devicetree@vger.kernel.org
      Signed-off-by: NGerhard Sittig <gsi@denx.de>
      Signed-off-by: NAnatolij Gustschin <agust@denx.de>
      c65ec135
    • T
      ARM: dts: Fix booting for secure omaps · f2e2c9d9
      Tony Lindgren 提交于
      Commit 7ce93f31 (ARM: OMAP2+: Fix more missing data for omap3.dtsi file)
      fixed missing device tree data for omaps, but did not account for some of the
      hardware modules being inaccessible for secure omaps. This causes the
      following error on secure omaps:
      
      Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0c5048
      SMP ARM
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W    3.13.0-rc2+ #446
      task: ce057b40 ti: ce058000 task.ti: ce058000
      PC is at omap_aes_dma_stop+0x24/0x3c
      LR is at omap_aes_probe+0x1cc/0x584
         psr: 60000113
      sp : ce059e20  ip : ce0b4ee0  fp : 00000000
      r10: c0573ae8  r9 : c0749508  r8 : 00000000
      r7 : ce0b4e00  r6 : 00000000  r5 : ce0b4e10  r4 : ce274890
      r3 : fa0c5048  r2 : 00000048  r1 : 0000002c  r0 : ce274890
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      Control: 10c5387d  Table: 80004019  DAC: 00000015
      Process swapper/0 (pid: 1, stack limit = 0xce058248)
      Stack: (0xce059e20 to 0xce05a000)
      9e20: c0749508 0000a1ff 00000000 c016cd8c c06b5a06 ce2a45f0 ce2a4570 ce0b5fb0
      9e40: 00000000 480c5000 480c504f c0abe4e4 00000200 00000000 00000000 00000000
      9e60: ce0b4e10 ce0b4e10 c082da3c c082da3c c02b8c70 c077c610 c0749508 00000000
      9e80: 00000000 c02b9e7c c02b9e64 ce0b4e10 00000000 c02b8b20 ce0b4e10 ce0b4e44
      9ea0: c082da3c c02b8cd8 00000000 ce059eb8 c082da3c c02b7408 ce079edc ce0b1a34
      9ec0: c082da3c c082da3c ce2a0280 00000000 c08158d8 c02b8358 c0663405 c0663405
      9ee0: 00000073 c082da3c c079e4e8 c07ab3bc c0844340 c02b9334 00000000 00000006
      9f00: c079e4e8 c0008920 c067f6bf c0ac7c6b 00000000 c0712e28 00000000 00000000
      9f20: c0712e38 ce059f38 00000093 c0ac7c82 00000000 c0058994 00000000 c07130e8
      9f40: c07127b8 00000093 00000006 00000006 00000001 00000006 00000006 c079e4e8
      9f60: c07ab3bc c0844340 00000093 c0749508 c079e4f4 c0749c64 00000006 00000006
      9f80: c0749508 00000000 00000000 c0517e2c 00000000 00000000 00000000 00000000
      9fa0: 00000000 c0517e34 00000000 c000dfb8 00000000 00000000 00000000 00000000
      9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff
      (omap_aes_probe+0x1cc/0x584)
      (platform_drv_probe+0x18/0x48)
      (driver_probe_device+0xb0/0x200)
      (__driver_attach+0x68/0x8c)
      (bus_for_each_dev+0x50/0x88)
      (bus_add_driver+0xcc/0x1c8)
      (driver_register+0x9c/0xe0)
      (do_one_initcall+0x98/0x140)
      (kernel_init_freeable+0x16c/0x23c)
      (kernel_init+0x8/0x100)
      (ret_from_fork+0x14/0x3c)
      Code: e1811002 e5932020 e590300c e0833002 (e593c000)
      
      Let's fix the issue by adding omap34xx-hs.dtsi and omap36xx-hs.dtsi and make
      n900, n9 and n950 to use them. This way we have the aes, sham and timer12
      disabled for secure devices the same way legacy booting does based on the
      omap34xx_gp_hwmod_ocp_ifs and omap36xx_gp_hwmod_ocp_ifs arrays in
      omap_hwmod_3xxx_data.c.
      Reported-by: NSebastian Reichel <sre@debian.org>
      Acked-By: NSebastian Reichel <sre@debian.org>
      Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      f2e2c9d9
    • N
      ARM: OMAP2+: Fix the machine entry for am3517 · caef4ee8
      Nishanth Menon 提交于
      The am3517 is wrongly booting as omap3 which means that the am3517
      specific devices like Ethernet won't work when booted with device
      tree. Now with the new devices defined in am3517.dtsi, let's use
      that instead of the omap3.dtsi, and add a separate machine entry
      for am3517 so am3517-evm can use it.
      Signed-off-by: NNishanth Menon <nm@ti.com>
      [tony@atomide.com: updated comments and fixed build without omap3]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      caef4ee8
    • T
      ARM: dts: Fix missing entries for am3517 · a0158185
      Tony Lindgren 提交于
      On am3517 there are some extra devices compared to omap3.dtsi that
      we currently have not defined. Let's fix that by adding am3517.dtsi
      file.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      a0158185
    • T
      ARM: OMAP2+: Fix overwriting hwmod data with data from device tree · 5e863c56
      Tony Lindgren 提交于
      We have some device tree properties where the ti,hwmod have multiple
      values:
      
      am33xx.dtsi:	ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
      am4372.dtsi:	ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
      dra7.dtsi:	ti,hwmods = "l3_main_1", "l3_main_2";
      omap3.dtsi:	ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
      omap3.dtsi:	ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
      omap4.dtsi:	ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
      omap5.dtsi:	ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
      
      That's not correct way of doing things in this case because these are
      separate devices with their own address space, interrupts, SYSCONFIG
      registers and can set their PM states independently.
      
      So they should all be fixed up to be separate devices in the .dts files.
      
      We also have the related data removed for at least omap4 in commit
      3b9b1015 (ARM: OMAP4: hwmod data: Clean up the data file), so
      that data is wrongly initialized as null data.
      
      So we need to fix two bugs:
      
      1. We are only checking the first entry of the ti,hwmods property
      
         This means that we're only initializing the first hwmods entry
         instead of the ones listed in the ti,hwmods property.
      
      2. We are only checking the child nodes, not the nodes themselves
      
         This means that anything listed at OCP level is currently just
         ignored and unitialized and at least the omap4 case, with the
         legacy data missing from the hwmod.
      
      Fix both of the issues by using an index to the ti,hwmods property
      and changing the hwmod lookup function to also check the current node
      for ti,hwmods property instead of just the children.
      
      While at it, let's also add some warnings for the bad data so it's
      easier to fix.
      
      Cc: "Benoît Cousson" <bcousson@baylibre.com>
      Acked-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      5e863c56
    • S
      arm64: mm: Fix PMD_SECT_PROT_NONE definition · db4ed53c
      Steve Capper 提交于
      Modify the value of PMD_SECT_PROT_NONE to match that of PTE_NONE. This
      should have been in commit 3676f9ef (Move PTE_PROT_NONE higher up).
      Signed-off-by: NSteve Capper <steve.capper@linaro.org>
      Cc: <stable@vger.kernel.org> # 3.11+: 3676f9ef: arm64: Move PTE_PROT_NONE higher up
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      db4ed53c