1. 03 Nov, 2017 6 commits
    • Dave Martin's avatar
      arm64: signal: Verify extra data is user-readable in sys_rt_sigreturn · abf73988
      Dave Martin authored
      Currently sys_rt_sigreturn() verifies that the base sigframe is
      readable, but no similar check is performed on the extra data to
      which an extra_context record points.
      
      This matters because the extra data will be read with the
      unprotected user accessors.  However, this is not a problem at
      present because the extra data base address is required to be
      exactly at the end of the base sigframe.  So, there would need to
      be a non-user-readable kernel address within about 59K
      (SIGFRAME_MAXSZ - sizeof(struct rt_sigframe)) of some address for
      which access_ok(VERIFY_READ) returns true, in order for sigreturn
      to be able to read kernel memory that should be inaccessible to the
      user task.  This is currently impossible due to the untranslatable
      address hole between the TTBR0 and TTBR1 address ranges.
      
      Disappearance of the hole between the TTBR0 and TTBR1 mapping
      ranges would require the VA size for TTBR0 and TTBR1 to grow to at
      least 55 bits, and either the disabling of tagged pointers for
      userspace or enabling of tagged pointers for kernel space; none of
      which is currently envisaged.
      
      Even so, it is wrong to use the unprotected user accessors without
      an accompanying access_ok() check.
      
      To avoid the potential for future surprises, this patch does an
      explicit access_ok() check on the extra data space when parsing an
      extra_context record.
      
      Fixes: 33f08261 ("arm64: signal: Allow expansion of the signal frame")
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      abf73988
    • Dave Martin's avatar
      arm64: fpsimd: Correctly annotate exception helpers called from asm · 94ef7ecb
      Dave Martin authored
      A couple of FPSIMD exception handling functions that are called
      from entry.S are currently not annotated as such.
      
      This is not a big deal since asmlinkage does nothing on arm/arm64,
      but fixing the annotations is more consistent and may help avoid
      future surprises.
      
      This patch adds appropriate asmlinkage annotations for
      do_fpsimd_acc() and do_fpsimd_exc().
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      94ef7ecb
    • Dave Martin's avatar
      regset: Add support for dynamically sized regsets · 27e64b4b
      Dave Martin authored
      Currently the regset API doesn't allow for the possibility that
      regsets (or at least, the amount of meaningful data in a regset)
      may change in size.
      
      In particular, this results in useless padding being added to
      coredumps if a regset's current size is smaller than its
      theoretical maximum size.
      
      This patch adds a get_size() function to struct user_regset.
      Individual regset implementations can implement this function to
      return the current size of the regset data.  A regset_size()
      function is added to provide callers with an abstract interface for
      determining the size of a regset without needing to know whether
      the regset is dynamically sized or not.
      
      The only affected user of this interface is the ELF coredump code:
      This patch ports ELF coredump to dump regsets with their actual
      size in the coredump.  This has no effect except for new regsets
      that are dynamically sized and provide a get_size() implementation.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
      Cc: H. J. Lu <hjl.tools@gmail.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      27e64b4b
    • Suzuki K Poulose's avatar
      arm-ccn: perf: Prevent module unload while PMU is in use · c7f5828b
      Suzuki K Poulose authored
      When the PMU driver is built as a module, the perf expects the
      pmu->module to be valid, so that the driver is prevented from
      being unloaded while it is in use. Fix the CCN pmu driver to
      fill in this field.
      
      Fixes: a33b0daa ("bus: ARM CCN PMU driver")
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      c7f5828b
    • Suzuki K Poulose's avatar
      perf: arm_spe: Prevent module unload while the PMU is in use · 19b4aff2
      Suzuki K Poulose authored
      When the PMU driver is built as a module, the perf expects the
      pmu->module to be valid, so that the driver is prevented from
      being unloaded while it is in use. Fix the SPE pmu driver to
      fill in this field.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      19b4aff2
    • Julien Thierry's avatar
      arm64: Fix static use of function graph · d125bffc
      Julien Thierry authored
      Function graph does not work currently when CONFIG_DYNAMIC_TRACE is not
      set. This is because ftrace_function_trace is not always set to ftrace_stub
      when function_graph is in use.
      
      Do not skip checking of graph tracer functions when ftrace_function_trace
      is set.
      Signed-off-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Reviewed-by: default avatarAKASHI Takahiro <takahiro.akashi@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      d125bffc
  2. 02 Nov, 2017 11 commits
  3. 31 Oct, 2017 1 commit
  4. 30 Oct, 2017 2 commits
    • Nick Desaulniers's avatar
      arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27 · fd9dde6a
      Nick Desaulniers authored
      Upon upgrading to binutils 2.27, we found that our lz4 and gzip
      compressed kernel images were significantly larger, resulting is 10ms
      boot time regressions.
      
      As noted by Rahul:
      "aarch64 binaries uses RELA relocations, where each relocation entry
      includes an addend value. This is similar to x86_64.  On x86_64, the
      addend values are also stored at the relocation offset for relative
      relocations. This is an optimization: in the case where code does not
      need to be relocated, the loader can simply skip processing relative
      relocations.  In binutils-2.25, both bfd and gold linkers did this for
      x86_64, but only the gold linker did this for aarch64.  The kernel build
      here is using the bfd linker, which stored zeroes at the relocation
      offsets for relative relocations.  Since a set of zeroes compresses
      better than a set of non-zero addend values, this behavior was resulting
      in much better lz4 compression.
      
      The bfd linker in binutils-2.27 is now storing the actual addend values
      at the relocation offsets. The behavior is now consistent with what it
      does for x86_64 and what gold linker does for both architectures.  The
      change happened in this upstream commit:
      https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1f56df9d0d5ad89806c24e71f296576d82344613
      Since a bunch of zeroes got replaced by non-zero addend values, we see
      the side effect of lz4 compressed image being a bit bigger.
      
      To get the old behavior from the bfd linker, "--no-apply-dynamic-relocs"
      flag can be used:
      $ LDFLAGS="--no-apply-dynamic-relocs" make
      With this flag, the compressed image size is back to what it was with
      binutils-2.25.
      
      If the kernel is using ASLR, there aren't additional runtime costs to
      --no-apply-dynamic-relocs, as the relocations will need to be applied
      again anyway after the kernel is relocated to a random address.
      
      If the kernel is not using ASLR, then presumably the current default
      behavior of the linker is better. Since the static linker performed the
      dynamic relocs, and the kernel is not moved to a different address at
      load time, it can skip applying the relocations all over again."
      
      Some measurements:
      
      $ ld -v
      GNU ld (binutils-2.25-f3d35cf6) 2.25.51.20141117
                          ^
      $ ls -l vmlinux
      -rwxr-x--- 1 ndesaulniers eng 300652760 Oct 26 11:57 vmlinux
      $ ls -l Image.lz4-dtb
      -rw-r----- 1 ndesaulniers eng 16932627 Oct 26 11:57 Image.lz4-dtb
      
      $ ld -v
      GNU ld (binutils-2.27-53dd00a1) 2.27.0.20170315
                          ^
      pre patch:
      $ ls -l vmlinux
      -rwxr-x--- 1 ndesaulniers eng 300376208 Oct 26 11:43 vmlinux
      $ ls -l Image.lz4-dtb
      -rw-r----- 1 ndesaulniers eng 18159474 Oct 26 11:43 Image.lz4-dtb
      
      post patch:
      $ ls -l vmlinux
      -rwxr-x--- 1 ndesaulniers eng 300376208 Oct 26 12:06 vmlinux
      $ ls -l Image.lz4-dtb
      -rw-r----- 1 ndesaulniers eng 16932466 Oct 26 12:06 Image.lz4-dtb
      
      By Siqi's measurement w/ gzip:
      binutils 2.27 with this patch (with --no-apply-dynamic-relocs):
      Image 41535488
      Image.gz 13404067
      
      binutils 2.27 without this patch (without --no-apply-dynamic-relocs):
      Image 41535488
      Image.gz 14125516
      
      Any compression scheme should be able to get better results from the
      longer runs of zeros, not just GZIP and LZ4.
      
      10ms boot time savings isn't anything to get excited about, but users of
      arm64+compression+bfd-2.27 should not have to pay a penalty for no
      runtime improvement.
      Reported-by: default avatarGopinath Elanchezhian <gelanchezhian@google.com>
      Reported-by: default avatarSindhuri Pentyala <spentyala@google.com>
      Reported-by: default avatarWei Wang <wvw@google.com>
      Suggested-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Suggested-by: default avatarRahul Chaudhry <rahulchaudhry@google.com>
      Suggested-by: default avatarSiqi Lin <siqilin@google.com>
      Suggested-by: default avatarStephen Hines <srhines@google.com>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      [will: added comment to Makefile]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      fd9dde6a
    • Catalin Marinas's avatar
      arm64: Implement arch-specific pte_access_permitted() · 6218f96c
      Catalin Marinas authored
      The generic pte_access_permitted() implementation only checks for
      pte_present() (together with the write permission where applicable).
      However, for both kernel ptes and PROT_NONE mappings pte_present() also
      returns true on arm64 even though such mappings are not user accessible.
      Additionally, arm64 now supports execute-only user permission
      (PROT_EXEC) which is implemented by clearing the PTE_USER bit.
      
      With this patch the arm64 implementation of pte_access_permitted()
      checks for the PTE_VALID and PTE_USER bits together with writable access
      if applicable.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      6218f96c
  5. 27 Oct, 2017 4 commits
  6. 25 Oct, 2017 3 commits
  7. 24 Oct, 2017 4 commits
  8. 19 Oct, 2017 8 commits
  9. 18 Oct, 2017 1 commit
    • Will Deacon's avatar
      drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension · d5d9696b
      Will Deacon authored
      The ARMv8.2 architecture introduces the optional Statistical Profiling
      Extension (SPE).
      
      SPE can be used to profile a population of operations in the CPU pipeline
      after instruction decode. These are either architected instructions (i.e.
      a dynamic instruction trace) or CPU-specific uops and the choice is fixed
      statically in the hardware and advertised to userspace via caps/. Sampling
      is controlled using a sampling interval, similar to a regular PMU counter,
      but also with an optional random perturbation to avoid falling into patterns
      where you continuously profile the same instruction in a hot loop.
      
      After each operation is decoded, the interval counter is decremented. When
      it hits zero, an operation is chosen for profiling and tracked within the
      pipeline until it retires. Along the way, information such as TLB lookups,
      cache misses, time spent to issue etc is captured in the form of a sample.
      The sample is then filtered according to certain criteria (e.g. load
      latency) that can be specified in the event config (described under
      format/) and, if the sample satisfies the filter, it is written out to
      memory as a record, otherwise it is discarded. Only one operation can
      be sampled at a time.
      
      The in-memory buffer is linear and virtually addressed, raising an
      interrupt when it fills up. The PMU driver handles these interrupts to
      give the appearance of a ring buffer, as expected by the AUX code.
      
      The in-memory trace-like format is self-describing (though not parseable
      in reverse) and written as a series of records, with each record
      corresponding to a sample and consisting of a sequence of packets. These
      packets are defined by the architecture, although some have CPU-specific
      fields for recording information specific to the microarchitecture.
      
      As a simple example, a record generated for a branch instruction may
      consist of the following packets:
      
        0 (Address) : Virtual PC of the branch instruction
        1 (Type)    : Conditional direct branch
        2 (Counter) : Number of cycles taken from Dispatch to Issue
        3 (Address) : Virtual branch target + condition flags
        4 (Counter) : Number of cycles taken from Dispatch to Complete
        5 (Events)  : Mispredicted as not-taken
        6 (END)     : End of record
      
      It is also possible to toggle properties such as timestamp packets in
      each record.
      
      This patch adds support for SPE in the form of a new perf driver.
      
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      d5d9696b