1. 30 Nov, 2016 1 commit
  2. 29 Nov, 2016 3 commits
    • Michael Ellerman's avatar
      powerpc/boot: Fix rebuild when changing kernel endian · f0f7fe1a
      Michael Ellerman authored
      Now that we don't set ARCH incorrectly when calling the boot Makefile,
      we can use the generic cpp_lds_S rule for converting our zImage.lds.S
      into zImage.lds.
      
      The main advantage of using the generic rule is that it correctly uses
      if_changed, which means we correctly regenerate the linker script when
      switching endian. Fixing that means we are finally able to build one
      endian and then rebuild the other endian without requiring to clean
      between builds.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      f0f7fe1a
    • Michael Ellerman's avatar
      powerpc/boot: All uses of if_changed should depend on FORCE · 42d0c932
      Michael Ellerman authored
      If we're using if_changed then we must depend on FORCE, so that
      if_changed gets a chance to check if something changed.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      42d0c932
    • Michael Ellerman's avatar
      powerpc: Stop passing ARCH=ppc64 to boot Makefile · 1196d7aa
      Michael Ellerman authored
      Back in 2005 when the ppc/ppc64 merge started, we used to build the
      kernel code in arch/powerpc but use the boot code from arch/ppc or
      arch/ppc64 depending on whether we were building for 32 or 64-bit.
      
      Originally we called the boot Makefile passing ARCH=$(OLDARCH), where
      OLDARCH was ppc or ppc64.
      
      In commit 20f62954 ("powerpc: Make building the boot image work for
      both 32-bit and 64-bit") (2005-10-11) we split the call for 32/64-bit
      using an ifeq check, because the two Makefiles took different targets,
      and explicitly passed ARCH=ppc64 for the 64-bit case and ARCH=ppc for
      the 32-bit case.
      
      Then in commit 94b212c2 ("powerpc: Move ppc64 boot wrapper code over
      to arch/powerpc") (2005-11-16) we moved the boot code into arch/powerpc
      and dropped the ppc case, but kept passing ARCH=ppc64 to
      arch/powerpc/boot/Makefile.
      
      Since then there have been several more boot targets added, all of which
      have copied the ARCH=ppc64 setting, such that now we have four targets
      using it.
      
      Currently it seems that nothing actually uses the ARCH value, but that's
      basically just luck, and in particular it prevents us from using the
      generic cpp_lds_S rule. It's also clearly wrong, ARCH=ppc64 is dead,
      buried and cremated.
      
      Fix it by dropping the setting of ARCH completely, the correct value is
      exported by the top level Makefile.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      1196d7aa
  3. 28 Nov, 2016 9 commits
  4. 26 Nov, 2016 1 commit
    • Balbir Singh's avatar
      powerpc/mm/radix: Prevent kernel execution of user space · 3b10d009
      Balbir Singh authored
      ISA 3 defines new encoded access authority that allows instruction
      access prevention in privileged mode and allows normal access
      to problem state. This patch just enables IAMR (Instruction Authority
      Mask Register), enabling AMR would require more work.
      
      I've tested this with a buggy driver and a simple payload. The payload
      is specific to the build I've tested.
      
      mpe: Also tested with LKDTM:
      
        # echo EXEC_USERSPACE > /sys/kernel/debug/provoke-crash/DIRECT
        lkdtm: Performing direct entry EXEC_USERSPACE
        lkdtm: attempting ok execution at c0000000005bf560
        lkdtm: attempting bad execution at 00003fff8d940000
        Unable to handle kernel paging request for instruction fetch
        Faulting instruction address: 0x3fff8d940000
        Oops: Kernel access of bad area, sig: 11 [#1]
        NIP: 00003fff8d940000 LR: c0000000005bfa58 CTR: 00003fff8d940000
        REGS: c0000000f1fcf900 TRAP: 0400   Not tainted  (4.9.0-rc5-compiler_gcc-6.2.0-00109-g956dbc06232a)
        MSR: 9000000010009033 <SF,HV,EE,ME,IR,DR,RI,LE>  CR: 48002222  XER: 00000000
        ...
        Call Trace:
          lkdtm_EXEC_USERSPACE+0x104/0x120 (unreliable)
          lkdtm_do_action+0x3c/0x80
          direct_entry+0x100/0x1b0
          full_proxy_write+0x94/0x100
          __vfs_write+0x3c/0x1b0
          vfs_write+0xcc/0x230
          SyS_write+0x60/0x110
          system_call+0x38/0xfc
      Signed-off-by: default avatarBalbir Singh <bsingharora@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      3b10d009
  5. 25 Nov, 2016 7 commits
  6. 24 Nov, 2016 1 commit
  7. 23 Nov, 2016 8 commits
  8. 22 Nov, 2016 8 commits
  9. 21 Nov, 2016 1 commit
  10. 18 Nov, 2016 1 commit
    • Michael Ellerman's avatar
      powerpc/64: Used named initialisers for ibm_pa_features · e9eb0278
      Michael Ellerman authored
      The ibm_pa_features array consists of structures that describe which bit
      and byte in the ibm,pa-features property toggles one or more flags in
      either the CPU, MMU, or user visible feature flags.
      
      Each one consists of 7 values, which are all unsigned long, int or char,
      meaning the compiler gives us no warning if we assign the wrong values
      to the wrong elements. In fact we have had a bug here in the past, where
      we were setting incorrect bits, see commit 6997e57d ("powerpc:
      scan_features() updates incorrect bits for REAL_LE").
      
      So switch to using named initialisers for the structure elements, to
      reduce the likelihood of future bugs, and hopefully improve readability
      also.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: default avatarBalbir Singh <bsingharora@gmail.com>
      e9eb0278