1. 11 7月, 2018 1 次提交
  2. 06 7月, 2018 3 次提交
    • M
      arm64: use PSR_AA32 definitions · d64567f6
      Mark Rutland 提交于
      Some code cares about the SPSR_ELx format for exceptions taken from
      AArch32 to inspect or manipulate the SPSR_ELx value, which is already in
      the SPSR_ELx format, and not in the AArch32 PSR format.
      
      To separate these from cases where we care about the AArch32 PSR format,
      migrate these cases to use the PSR_AA32_* definitions rather than
      COMPAT_PSR_*.
      
      There should be no functional change as a result of this patch.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      d64567f6
    • M
      arm64: ptrace: map SPSR_ELx<->PSR for compat tasks · 76fc52bd
      Mark Rutland 提交于
      The SPSR_ELx format for exceptions taken from AArch32 is slightly
      different to the AArch32 PSR format.
      
      Map between the two in the compat ptrace code.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Fixes: 7206dc93 ("arm64: Expose Arm v8.4 features")
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Suzuki Poulose <suzuki.poulose@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      76fc52bd
    • M
      arm64: don't zero DIT on signal return · 12651321
      Mark Rutland 提交于
      Currently valid_user_regs() treats SPSR_ELx.DIT as a RES0 bit, causing
      it to be zeroed upon exception return, rather than preserved. Thus, code
      relying on DIT will not function as expected, and may expose an
      unexpected timing sidechannel.
      
      Let's remove DIT from the set of RES0 bits, such that it is preserved.
      At the same time, the related comment is updated to better describe the
      situation, and to take into account the most recent documentation of
      SPSR_ELx, in ARM DDI 0487C.a.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Fixes: 7206dc93 ("arm64: Expose Arm v8.4 features")
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      12651321
  3. 01 6月, 2018 1 次提交
    • D
      arm64/sve: Thin out initialisation sanity-checks for sve_max_vl · 87c021a8
      Dave Martin 提交于
      Now that the kernel SVE support is reasonably mature, it is
      excessive to default sve_max_vl to the invalid value -1 and then
      sprinkle WARN_ON()s around the place to make sure it has been
      initialised before use.  The cpufeatures code already runs pretty
      early, and will ensure sve_max_vl gets initialised.
      
      This patch initialises sve_max_vl to something sane that will be
      supported by every SVE implementation, and removes most of the
      sanity checks.
      
      The checks in find_supported_vector_length() are retained for now.
      If anything goes horribly wrong, we are likely to trip a check here
      sooner or later.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      87c021a8
  4. 25 5月, 2018 1 次提交
  5. 16 5月, 2018 1 次提交
  6. 26 4月, 2018 1 次提交
  7. 25 4月, 2018 1 次提交
  8. 28 3月, 2018 2 次提交
    • D
      arm64: uaccess: Fix omissions from usercopy whitelist · 65896545
      Dave Martin 提交于
      When the hardend usercopy support was added for arm64, it was
      concluded that all cases of usercopy into and out of thread_struct
      were statically sized and so didn't require explicit whitelisting
      of the appropriate fields in thread_struct.
      
      Testing with usercopy hardening enabled has revealed that this is
      not the case for certain ptrace regset manipulation calls on arm64.
      This occurs because the sizes of usercopies associated with the
      regset API are dynamic by construction, and because arm64 does not
      always stage such copies via the stack: indeed the regset API is
      designed to avoid the need for that by adding some bounds checking.
      
      This is currently believed to affect only the fpsimd and TLS
      registers.
      
      Because the whitelisted fields in thread_struct must be contiguous,
      this patch groups them together in a nested struct.  It is also
      necessary to be able to determine the location and size of that
      struct, so rather than making the struct anonymous (which would
      save on edits elsewhere) or adding an anonymous union containing
      named and unnamed instances of the same struct (gross), this patch
      gives the struct a name and makes the necessary edits to code that
      references it (noisy but simple).
      
      Care is needed to ensure that the new struct does not contain
      padding (which the usercopy hardening would fail to protect).
      
      For this reason, the presence of tp2_value is made unconditional,
      since a padding field would be needed there in any case.  This pads
      up to the 16-byte alignment required by struct user_fpsimd_state.
      Acked-by: NKees Cook <keescook@chromium.org>
      Reported-by: NMark Rutland <mark.rutland@arm.com>
      Fixes: 9e8084d3 ("arm64: Implement thread_struct whitelist for hardened usercopy")
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      65896545
    • D
      arm64: fpsimd: Split cpu field out from struct fpsimd_state · 20b85472
      Dave Martin 提交于
      In preparation for using a common representation of the FPSIMD
      state for tasks and KVM vcpus, this patch separates out the "cpu"
      field that is used to track the cpu on which the state was most
      recently loaded.
      
      This will allow common code to operate on task and vcpu contexts
      without requiring the cpu field to be stored at the same offset
      from the FPSIMD register data in both cases.  This should avoid the
      need for messing with the definition of those parts of struct
      vcpu_arch that are exposed in the KVM user ABI.
      
      The resulting change is also convenient for grouping and defining
      the set of thread_struct fields that are supposed to be accessible
      to copy_{to,from}_user(), which includes user_fpsimd_state but
      should exclude the cpu field.  This patch does not amend the
      usercopy whitelist to match: that will be addressed in a subsequent
      patch.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      [will: inline fpsimd_flush_state for now]
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      20b85472
  9. 07 3月, 2018 1 次提交
  10. 22 2月, 2018 1 次提交
    • I
      treewide/trivial: Remove ';;$' typo noise · ed7158ba
      Ingo Molnar 提交于
      On lkml suggestions were made to split up such trivial typo fixes into per subsystem
      patches:
      
        --- a/arch/x86/boot/compressed/eboot.c
        +++ b/arch/x86/boot/compressed/eboot.c
        @@ -439,7 +439,7 @@ setup_uga32(void **uga_handle, unsigned long size, u32 *width, u32 *height)
                struct efi_uga_draw_protocol *uga = NULL, *first_uga;
                efi_guid_t uga_proto = EFI_UGA_PROTOCOL_GUID;
                unsigned long nr_ugas;
        -       u32 *handles = (u32 *)uga_handle;;
        +       u32 *handles = (u32 *)uga_handle;
                efi_status_t status = EFI_INVALID_PARAMETER;
                int i;
      
      This patch is the result of the following script:
      
        $ sed -i 's/;;$/;/g' $(git grep -E ';;$'  | grep "\.[ch]:"  | grep -vwE 'for|ia64' | cut -d: -f1 | sort | uniq)
      
      ... followed by manual review to make sure it's all good.
      
      Splitting this up is just crazy talk, let's get over with this and just do it.
      Reported-by: NPavel Machek <pavel@ucw.cz>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      ed7158ba
  11. 23 1月, 2018 3 次提交
  12. 03 11月, 2017 1 次提交
    • D
      arm64/sve: ptrace and ELF coredump support · 43d4da2c
      Dave Martin 提交于
      This patch defines and implements a new regset NT_ARM_SVE, which
      describes a thread's SVE register state.  This allows a debugger to
      manipulate the SVE state, as well as being included in ELF
      coredumps for post-mortem debugging.
      
      Because the regset size and layout are dependent on the thread's
      current vector length, it is not possible to define a C struct to
      describe the regset contents as is done for existing regsets.
      Instead, and for the same reasons, NT_ARM_SVE is based on the
      freeform variable-layout approach used for the SVE signal frame.
      
      Additionally, to reduce debug overhead when debugging threads that
      might or might not have live SVE register state, NT_ARM_SVE may be
      presented in one of two different formats: the old struct
      user_fpsimd_state format is embedded for describing the state of a
      thread with no live SVE state, whereas a new variable-layout
      structure is embedded for describing live SVE state.  This avoids a
      debugger needing to poll NT_PRFPREG in addition to NT_ARM_SVE, and
      allows existing userspace code to handle the non-SVE case without
      too much modification.
      
      For this to work, NT_ARM_SVE is defined with a fixed-format header
      of type struct user_sve_header, which the recipient can use to
      figure out the content, size and layout of the reset of the regset.
      Accessor macros are defined to allow the vector-length-dependent
      parts of the regset to be manipulated.
      Signed-off-by: NAlan Hayward <alan.hayward@arm.com>
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: Alex Bennée <alex.bennee@linaro.org>
      Cc: Okamoto Takayuki <tokamoto@jp.fujitsu.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      43d4da2c
  13. 16 8月, 2017 1 次提交
    • M
      arm64: clean up irq stack definitions · f60ad4ed
      Mark Rutland 提交于
      Before we add yet another stack to the kernel, it would be nice to
      ensure that we consistently organise stack definitions and related
      helper functions.
      
      This patch moves the basic IRQ stack defintions to <asm/memory.h> to
      live with their task stack counterparts. Helpers used for unwinding are
      moved into <asm/stacktrace.h>, where subsequent patches will add helpers
      for other stacks. Includes are fixed up accordingly.
      
      This patch is a pure refactoring -- there should be no functional
      changes as a result of this patch.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Tested-by: NLaura Abbott <labbott@redhat.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: James Morse <james.morse@arm.com>
      f60ad4ed
  14. 08 8月, 2017 1 次提交
    • M
      arm64: unwind: avoid percpu indirection for irq stack · 09668372
      Mark Rutland 提交于
      Our IRQ_STACK_PTR() and on_irq_stack() helpers both take a cpu argument,
      used to generate a percpu address. In all cases, they are passed
      {raw_,}smp_processor_id(), so this parameter is redundant.
      
      Since {raw_,}smp_processor_id() use a percpu variable internally, this
      approach means we generate a percpu offset to find the current cpu, then
      use this to index an array of percpu offsets, which we then use to find
      the current CPU's IRQ stack pointer. Thus, most of the work is
      redundant.
      
      Instead, we can consistently use raw_cpu_ptr() to generate the CPU's
      irq_stack pointer by simply adding the percpu offset to the irq_stack
      address, which is simpler in both respects.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      09668372
  15. 07 8月, 2017 2 次提交
    • D
      arm64: Abstract syscallno manipulation · 17c28958
      Dave Martin 提交于
      The -1 "no syscall" value is written in various ways, shared with
      the user ABI in some places, and generally obscure.
      
      This patch attempts to make things a little more consistent and
      readable by replacing all these uses with a single #define.  A
      couple of symbolic helpers are provided to clarify the intent
      further.
      
      Because the in-syscall check in do_signal() is changed from >= 0 to
      != NO_SYSCALL by this patch, different behaviour may be observable
      if syscallno is set to values less than -1 by a tracer.  However,
      this is not different from the behaviour that is already observable
      if a tracer sets syscallno to a value >= __NR_(compat_)syscalls.
      
      It appears that this can cause spurious syscall restarting, but
      that is not a new behaviour either, and does not appear harmful.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      17c28958
    • D
      arm64: syscallno is secretly an int, make it official · 35d0e6fb
      Dave Martin 提交于
      The upper 32 bits of the syscallno field in thread_struct are
      handled inconsistently, being sometimes zero extended and sometimes
      sign-extended.  In fact, only the lower 32 bits seem to have any
      real significance for the behaviour of the code: it's been OK to
      handle the upper bits inconsistently because they don't matter.
      
      Currently, the only place I can find where those bits are
      significant is in calling trace_sys_enter(), which may be
      unintentional: for example, if a compat tracer attempts to cancel a
      syscall by passing -1 to (COMPAT_)PTRACE_SET_SYSCALL at the
      syscall-enter-stop, it will be traced as syscall 4294967295
      rather than -1 as might be expected (and as occurs for a native
      tracer doing the same thing).  Elsewhere, reads of syscallno cast
      it to an int or truncate it.
      
      There's also a conspicuous amount of code and casting to bodge
      around the fact that although semantically an int, syscallno is
      stored as a u64.
      
      Let's not pretend any more.
      
      In order to preserve the stp x instruction that stores the syscall
      number in entry.S, this patch special-cases the layout of struct
      pt_regs for big endian so that the newly 32-bit syscallno field
      maps onto the low bits of the stored value.  This is not beautiful,
      but benchmarking of the getpid syscall on Juno suggests indicates a
      minor slowdown if the stp is split into an stp x and stp w.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      35d0e6fb
  16. 30 6月, 2017 3 次提交
  17. 22 6月, 2017 3 次提交
    • D
      arm64: ptrace: Flush user-RW TLS reg to thread_struct before reading · 936eb65c
      Dave Martin 提交于
      When reading current's user-writable TLS register (which occurs
      when dumping core for native tasks), it is possible that userspace
      has modified it since the time the task was last scheduled out.
      The new TLS register value is not guaranteed to have been written
      immediately back to thread_struct in this case.
      
      As a result, a coredump can capture stale data for this register.
      Reading the register for a stopped task via ptrace is unaffected.
      
      For native tasks, this patch explicitly flushes the TPIDR_EL0
      register back to thread_struct before dumping when operating on
      current, thus ensuring that coredump contents are up to date.  For
      compat tasks, the TLS register is not user-writable and so cannot
      be out of sync, so no flush is required in compat_tls_get().
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      936eb65c
    • D
      arm64: ptrace: Flush FPSIMD regs back to thread_struct before reading · e1d5a8fb
      Dave Martin 提交于
      When reading the FPSIMD state of current (which occurs when dumping
      core), it is possible that userspace has modified the FPSIMD
      registers since the time the task was last scheduled out.  Such
      changes are not guaranteed to be reflected immedately in
      thread_struct.
      
      As a result, a coredump can contain stale values for these
      registers.  Reading the registers of a stopped task via ptrace is
      unaffected.
      
      This patch explicitly flushes the CPU state back to thread_struct
      before dumping when operating on current, thus ensuring that
      coredump contents are up to date.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      e1d5a8fb
    • D
      arm64: ptrace: Fix VFP register dumping in compat coredumps · af66b2d8
      Dave Martin 提交于
      Currently, VFP registers are omitted from coredumps for compat
      processes, due to a bug in the REGSET_COMPAT_VFP regset
      implementation.
      
      compat_vfp_get() needs to transfer non-contiguous data from
      thread_struct.fpsimd_state, and uses put_user() to handle the
      offending trailing word (FPSCR).  This fails when copying to a
      kernel address (i.e., kbuf && !ubuf), which is what happens when
      dumping core.  As a result, the ELF coredump core code silently
      omits the NT_ARM_VFP note from the dump.
      
      It would be possible to work around this with additional special
      case code for the put_user(), but since user_regset_copyout() is
      explicitly designed to handle this scenario it is cleaner to port
      the put_user() to a user_regset_copyout() call, which this patch
      does.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      af66b2d8
  18. 02 3月, 2017 2 次提交
  19. 19 1月, 2017 4 次提交
  20. 19 11月, 2016 1 次提交
    • P
      arm64: Allow hw watchpoint at varied offset from base address · b08fb180
      Pratyush Anand 提交于
      ARM64 hardware supports watchpoint at any double word aligned address.
      However, it can select any consecutive bytes from offset 0 to 7 from that
      base address. For example, if base address is programmed as 0x420030 and
      byte select is 0x1C, then access of 0x420032,0x420033 and 0x420034 will
      generate a watchpoint exception.
      
      Currently, we do not have such modularity. We can only program byte,
      halfword, word and double word access exception from any base address.
      
      This patch adds support to overcome above limitations.
      Signed-off-by: NPratyush Anand <panand@redhat.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      b08fb180
  21. 19 7月, 2016 1 次提交
  22. 15 6月, 2016 2 次提交
  23. 02 3月, 2016 1 次提交
    • M
      arm64: Rework valid_user_regs · dbd4d7ca
      Mark Rutland 提交于
      We validate pstate using PSR_MODE32_BIT, which is part of the
      user-provided pstate (and cannot be trusted). Also, we conflate
      validation of AArch32 and AArch64 pstate values, making the code
      difficult to reason about.
      
      Instead, validate the pstate value based on the associated task. The
      task may or may not be current (e.g. when using ptrace), so this must be
      passed explicitly by callers. To avoid circular header dependencies via
      sched.h, is_compat_task is pulled out of asm/ptrace.h.
      
      To make the code possible to reason about, the AArch64 and AArch32
      validation is split into separate functions. Software must respect the
      RES0 policy for SPSR bits, and thus the kernel mirrors the hardware
      policy (RAZ/WI) for bits as-yet unallocated. When these acquire an
      architected meaning writes may be permitted (potentially with additional
      validation).
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Cc: Dave Martin <dave.martin@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      dbd4d7ca
  24. 08 12月, 2015 1 次提交
  25. 27 7月, 2015 1 次提交
    • C
      arm64: Better native ptrace support for compat tasks · 5d220ff9
      Catalin Marinas 提交于
      The compat ptrace interface allows access to the TLS register, hardware
      breakpoints and watchpoints, syscall number. However, a native task
      using the native ptrace interface to debug compat tasks (e.g. multi-arch
      gdb) only has access to the general and VFP register sets. The compat
      ptrace interface cannot be accessed from a native task.
      
      This patch adds a new user_aarch32_ptrace_view which contains the TLS,
      hardware breakpoint/watchpoint and syscall number regsets in addition to
      the existing GPR and VFP regsets. This view is backwards compatible with
      the previous kernels. Core dumping of 32-bit tasks and compat ptrace are
      not affected since the original user_aarch32_view is preserved.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reported-by: NYao Qi <yao.qi@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      5d220ff9