1. 26 Mar, 2018 2 commits
    • Dave Martin's avatar
      arm64: capabilities: Update prototype for enable call back · c0cda3b8
      Dave Martin authored
      We issue the enable() call back for all CPU hwcaps capabilities
      available on the system, on all the CPUs. So far we have ignored
      the argument passed to the call back, which had a prototype to
      accept a "void *" for use with on_each_cpu() and later with
      stop_machine(). However, with commit 0a0d111d
      ("arm64: cpufeature: Pass capability structure to ->enable callback"),
      there are some users of the argument who wants the matching capability
      struct pointer where there are multiple matching criteria for a single
      capability. Clean up the declaration of the call back to make it clear.
      
       1) Renamed to cpu_enable(), to imply taking necessary actions on the
          called CPU for the entry.
       2) Pass const pointer to the capability, to allow the call back to
          check the entry. (e.,g to check if any action is needed on the CPU)
       3) We don't care about the result of the call back, turning this to
          a void.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Andre Przywara <andre.przywara@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Acked-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Reviewed-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Signed-off-by: default avatarDave Martin <dave.martin@arm.com>
      [suzuki: convert more users, rename call back and drop results]
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      c0cda3b8
    • Dave Martin's avatar
      arm64/sve: Document firmware support requirements in Kconfig · 5043694e
      Dave Martin authored
      Use of SVE by EL2 and below requires explicit support in the
      firmware.  There is no means to hide the presence of SVE from EL2,
      so a kernel configured with CONFIG_ARM64_SVE=y will typically not
      work correctly on SVE capable hardware unless the firmware does
      include the appropriate support.
      
      This is not expected to pose a problem in the wild, since platform
      integrators are responsible for ensuring that they ship up-to-date
      firmware to support their hardware.  However, developers may hit
      the issue when using mismatched compoments.
      
      In order to draw attention to the issue and how to solve it, this
      patch adds some Kconfig text giving a brief explanation and details
      of compatible firmware versions.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      5043694e
  2. 20 Mar, 2018 2 commits
    • Dave Martin's avatar
      arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE · af4a81b9
      Dave Martin authored
      Currently a SIGFPE delivered in response to a floating-point
      exception trap may have si_code set to 0 on arm64.  As reported by
      Eric, this is a bad idea since this is the value of SI_USER -- yet
      this signal is definitely not the result of kill(2), tgkill(2) etc.
      and si_uid and si_pid make limited sense whereas we do want to
      yield a value for si_addr (which doesn't exist for SI_USER).
      
      It's not entirely clear whether the architecure permits a
      "spurious" fp exception trap where none of the exception flag bits
      in ESR_ELx is set.  (IMHO the architectural intent is to forbid
      this.)  However, it does permit those bits to contain garbage if
      the TFV bit in ESR_ELx is 0.  That case isn't currently handled at
      all and may result in si_code == 0 or si_code containing a FPE_FLT*
      constant corresponding to an exception that did not in fact happen.
      
      There is nothing sensible we can return for si_code in such cases,
      but SI_USER is certainly not appropriate and will lead to violation
      of legitimate userspace assumptions.
      
      This patch allocates a new si_code value FPE_UNKNOWN that at least
      does not conflict with any existing SI_* or FPE_* code, and yields
      this in si_code for undiagnosable cases.  This is probably the best
      simplicity/incorrectness tradeoff achieveable without relying on
      implementation-dependent features or adding a lot of code.  In any
      case, there appears to be no perfect solution possible that would
      justify a lot of effort here.
      
      Yielding FPE_UNKNOWN when some well-defined fp exception caused the
      trap is a violation of POSIX, but this is forced by the
      architecture.  We have no realistic prospect of yielding the
      correct code in such cases.  At present I am not aware of any ARMv8
      implementation that supports trapped floating-point exceptions in
      any case.
      
      The new code may be applicable to other architectures for similar
      reasons.
      
      No attempt is made to provide ESR_ELx to userspace in the signal
      frame, since architectural limitations mean that it is unlikely to
      provide much diagnostic value, doesn't benefit existing software
      and would create ABI with no proven purpose.  The existing
      mechanism for passing it also has problems of its own which may
      result in the wrong value being passed to userspace due to
      interaction with mm faults.  The implied rework does not appear
      justified.
      Acked-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Reported-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      af4a81b9
    • Will Deacon's avatar
      Merge branch 'siginfo-next' of... · 4c0ca49e
      Will Deacon authored
      Merge branch 'siginfo-next' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace into aarch64/for-next/core
      
      Pull in pending siginfo changes from Eric Biederman as we depend on
      the definition of FPE_FLTUNK for cleaning up our floating-point exception
      signal delivery (which is currently broken and using FPE_FIXME).
      4c0ca49e
  3. 19 Mar, 2018 4 commits
  4. 15 Mar, 2018 1 commit
  5. 09 Mar, 2018 6 commits
    • Will Deacon's avatar
      Merge tag 'acpi/iort-for-v4.17' of... · 654c39c7
      Will Deacon authored
      Merge tag 'acpi/iort-for-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux into aarch64/for-next/core
      
      Three ACPI IORT clean-up patches aimed at v4.17 release cycle:
      
      - Removal of IORT linker script entry re-introduced by mistake by clocksource
        drivers refactoring (J.He)
      - Two ACPICA guards removal of previously introduced guards to prevent
        ACPICA<->kernel patches dependencies (L.Pieralisi)
      654c39c7
    • Dave Martin's avatar
      arm64: signal: Ensure si_code is valid for all fault signals · af40ff68
      Dave Martin authored
      Currently, as reported by Eric, an invalid si_code value 0 is
      passed in many signals delivered to userspace in response to faults
      and other kernel errors.  Typically 0 is passed when the fault is
      insufficiently diagnosable or when there does not appear to be any
      sensible alternative value to choose.
      
      This appears to violate POSIX, and is intuitively wrong for at
      least two reasons arising from the fact that 0 == SI_USER:
      
       1) si_code is a union selector, and SI_USER (and si_code <= 0 in
          general) implies the existence of a different set of fields
          (siginfo._kill) from that which exists for a fault signal
          (siginfo._sigfault).  However, the code raising the signal
          typically writes only the _sigfault fields, and the _kill
          fields make no sense in this case.
      
          Thus when userspace sees si_code == 0 (SI_USER) it may
          legitimately inspect fields in the inactive union member _kill
          and obtain garbage as a result.
      
          There appears to be software in the wild relying on this,
          albeit generally only for printing diagnostic messages.
      
       2) Software that wants to be robust against spurious signals may
          discard signals where si_code == SI_USER (or <= 0), or may
          filter such signals based on the si_uid and si_pid fields of
          siginfo._sigkill.  In the case of fault signals, this means
          that important (and usually fatal) error conditions may be
          silently ignored.
      
      In practice, many of the faults for which arm64 passes si_code == 0
      are undiagnosable conditions such as exceptions with syndrome
      values in ESR_ELx to which the architecture does not yet assign any
      meaning, or conditions indicative of a bug or error in the kernel
      or system and thus that are unrecoverable and should never occur in
      normal operation.
      
      The approach taken in this patch is to translate all such
      undiagnosable or "impossible" synchronous fault conditions to
      SIGKILL, since these are at least probably localisable to a single
      process.  Some of these conditions should really result in a kernel
      panic, but due to the lack of diagnostic information it is
      difficult to be certain: this patch does not add any calls to
      panic(), but this could change later if justified.
      
      Although si_code will not reach userspace in the case of SIGKILL,
      it is still desirable to pass a nonzero value so that the common
      siginfo handling code can detect incorrect use of si_code == 0
      without false positives.  In this case the si_code dependent
      siginfo fields will not be correctly initialised, but since they
      are not passed to userspace I deem this not to matter.
      
      A few faults can reasonably occur in realistic userspace scenarios,
      and _should_ raise a regular, handleable (but perhaps not
      ignorable/blockable) signal: for these, this patch attempts to
      choose a suitable standard si_code value for the raised signal in
      each case instead of 0.
      
      arm64 was the only arch to define a BUS_FIXME code, so after this
      patch nobody defines it.  This patch therefore also removes the
      relevant code from siginfo_layout().
      
      Cc: James Morse <james.morse@arm.com>
      Reported-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      af40ff68
    • Shanker Donthineni's avatar
      arm64: Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC · 6ae4b6e0
      Shanker Donthineni authored
      The DCache clean & ICache invalidation requirements for instructions
      to be data coherence are discoverable through new fields in CTR_EL0.
      The following two control bits DIC and IDC were defined for this
      purpose. No need to perform point of unification cache maintenance
      operations from software on systems where CPU caches are transparent.
      
      This patch optimize the three functions __flush_cache_user_range(),
      clean_dcache_area_pou() and invalidate_icache_range() if the hardware
      reports CTR_EL0.IDC and/or CTR_EL0.IDC. Basically it skips the two
      instructions 'DC CVAU' and 'IC IVAU', and the associated loop logic
      in order to avoid the unnecessary overhead.
      
      CTR_EL0.DIC: Instruction cache invalidation requirements for
       instruction to data coherence. The meaning of this bit[29].
        0: Instruction cache invalidation to the point of unification
           is required for instruction to data coherence.
        1: Instruction cache cleaning to the point of unification is
            not required for instruction to data coherence.
      
      CTR_EL0.IDC: Data cache clean requirements for instruction to data
       coherence. The meaning of this bit[28].
        0: Data cache clean to the point of unification is required for
           instruction to data coherence, unless CLIDR_EL1.LoC == 0b000
           or (CLIDR_EL1.LoUIS == 0b000 && CLIDR_EL1.LoUU == 0b000).
        1: Data cache clean to the point of unification is not required
           for instruction to data coherence.
      Co-authored-by: default avatarPhilip Elcan <pelcan@codeaurora.org>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarShanker Donthineni <shankerd@codeaurora.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      6ae4b6e0
    • Ard Biesheuvel's avatar
      arm64/kernel: enable A53 erratum #8434319 handling at runtime · ca79acca
      Ard Biesheuvel authored
      Omit patching of ADRP instruction at module load time if the current
      CPUs are not susceptible to the erratum.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      [will: Drop duplicate initialisation of .def_scope field]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      ca79acca
    • Ard Biesheuvel's avatar
      arm64/errata: add REVIDR handling to framework · e8002e02
      Ard Biesheuvel authored
      In some cases, core variants that are affected by a certain erratum
      also exist in versions that have the erratum fixed, and this fact is
      recorded in a dedicated bit in system register REVIDR_EL1.
      
      Since the architecture does not require that a certain bit retains
      its meaning across different variants of the same model, each such
      REVIDR bit is tightly coupled to a certain revision/variant value,
      and so we need a list of revidr_mask/midr pairs to carry this
      information.
      
      So add the struct member and the associated macros and handling to
      allow REVIDR fixes to be taken into account.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      e8002e02
    • Ard Biesheuvel's avatar
      arm64/kernel: don't ban ADRP to work around Cortex-A53 erratum #843419 · a257e025
      Ard Biesheuvel authored
      Working around Cortex-A53 erratum #843419 involves special handling of
      ADRP instructions that end up in the last two instruction slots of a
      4k page, or whose output register gets overwritten without having been
      read. (Note that the latter instruction sequence is never emitted by
      a properly functioning compiler, which is why it is disregarded by the
      handling of the same erratum in the bfd.ld linker which we rely on for
      the core kernel)
      
      Normally, this gets taken care of by the linker, which can spot such
      sequences at final link time, and insert a veneer if the ADRP ends up
      at a vulnerable offset. However, linux kernel modules are partially
      linked ELF objects, and so there is no 'final link time' other than the
      runtime loading of the module, at which time all the static relocations
      are resolved.
      
      For this reason, we have implemented the #843419 workaround for modules
      by avoiding ADRP instructions altogether, by using the large C model,
      and by passing -mpc-relative-literal-loads to recent versions of GCC
      that may emit adrp/ldr pairs to perform literal loads. However, this
      workaround forces us to keep literal data mixed with the instructions
      in the executable .text segment, and literal data may inadvertently
      turn into an exploitable speculative gadget depending on the relative
      offsets of arbitrary symbols.
      
      So let's reimplement this workaround in a way that allows us to switch
      back to the small C model, and to drop the -mpc-relative-literal-loads
      GCC switch, by patching affected ADRP instructions at runtime:
      - ADRP instructions that do not appear at 4k relative offset 0xff8 or
        0xffc are ignored
      - ADRP instructions that are within 1 MB of their target symbol are
        converted into ADR instructions
      - remaining ADRP instructions are redirected via a veneer that performs
        the load using an unaffected movn/movk sequence.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      [will: tidied up ADRP -> ADR instruction patching.]
      [will: use ULL suffix for 64-bit immediate]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      a257e025
  6. 08 Mar, 2018 5 commits
    • Ard Biesheuvel's avatar
      arm64/kernel: kaslr: reduce module randomization range to 4 GB · f2b9ba87
      Ard Biesheuvel authored
      We currently have to rely on the GCC large code model for KASLR for
      two distinct but related reasons:
      - if we enable full randomization, modules will be loaded very far away
        from the core kernel, where they are out of range for ADRP instructions,
      - even without full randomization, the fact that the 128 MB module region
        is now no longer fully reserved for kernel modules means that there is
        a very low likelihood that the normal bottom-up allocation of other
        vmalloc regions may collide, and use up the range for other things.
      
      Large model code is suboptimal, given that each symbol reference involves
      a literal load that goes through the D-cache, reducing cache utilization.
      But more importantly, literals are not instructions but part of .text
      nonetheless, and hence mapped with executable permissions.
      
      So let's get rid of our dependency on the large model for KASLR, by:
      - reducing the full randomization range to 4 GB, thereby ensuring that
        ADRP references between modules and the kernel are always in range,
      - reduce the spillover range to 4 GB as well, so that we fallback to a
        region that is still guaranteed to be in range
      - move the randomization window of the core kernel to the middle of the
        VMALLOC space
      
      Note that KASAN always uses the module region outside of the vmalloc space,
      so keep the kernel close to that if KASAN is enabled.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      f2b9ba87
    • Ard Biesheuvel's avatar
      arm64: module: don't BUG when exceeding preallocated PLT count · 5e8307b9
      Ard Biesheuvel authored
      When PLTs are emitted at relocation time, we really should not exceed
      the number that we counted when parsing the relocation tables, and so
      currently, we BUG() on this condition. However, even though this is a
      clear bug in this particular piece of code, we can easily recover by
      failing to load the module.
      
      So instead, return 0 from module_emit_plt_entry() if this condition
      occurs, which is not a valid kernel address, and can hence serve as
      a flag value that makes the relocation routine bail out.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      5e8307b9
    • Lorenzo Pieralisi's avatar
      ACPI/IORT: Remove obsolete ACPI_IORT_SMMU_V3_CAVIUM_CN99XX define · 8dc12538
      Lorenzo Pieralisi authored
      To defeat ACPICA<->kernel merge order dependencies a preprocessor define
      value was introduced in the IORT compilation unit according to IORT
      revision C, IORT_SMMU_V3_CAVIUM_CN99XX, so that even if the value was
      not defined in ACPICA headers the IORT kernel layer would still be able
      to function and use it.
      
      Since commit 0c2021c0 ("ACPICA: IORT: Update SMMU models for
      revision C") finally added the define in ACPICA headers, as required by
      ACPICA IORT support, the preprocessor definition in the IORT kernel
      compilation unit has become obsolete and can be removed.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Hanjun Guo <hanjun.guo@linaro.org>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      8dc12538
    • Lorenzo Pieralisi's avatar
      ACPI/IORT: Remove temporary iort_get_id_mapping_index() ACPICA guard · 6c475063
      Lorenzo Pieralisi authored
      In IORT issue C SMMUv3 IORT nodes gained an additional field (DeviceID
      mapping index) so that the SMMUv3 can describe its MSI interrupts.
      
      Referring to it in the kernel requires ACPICA changes and in order
      to prevent kernel<->ACPICA dependencies kernel code depending on the
      SMMUv3 DeviceID mapping index field was guarded with an ACPICA version
      conditional.
      
      ACPICA changes introducing DeviceID mapping index in the IORT structs
      were integrated in the kernel with:
      
      commit 4c106aa4 ("ACPICA: iasl: Add SMMUv3 device ID mapping index
      support")
      
      so the temporary ACPICA guard has become stale and can be removed.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Hanjun Guo <hanjun.guo@linaro.org>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      6c475063
    • Jia He's avatar
      ACPI/IORT: Remove linker section for IORT entries again · c38d0852
      Jia He authored
      In commit 316ca880 ("ACPI/IORT: Remove linker section for IORT entries
      probing"), iort entries was removed in vmlinux.lds.h. But in
      commit 2fcc112a ("clocksource/drivers: Rename clksrc table to timer"),
      this line was back incorrectly.
      
      It does no harm except for adding some useless symbols, so fix it.
      Signed-off-by: default avatarJia He <jia.he@hxt-semitech.com>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      c38d0852
  7. 06 Mar, 2018 17 commits
  8. 05 Mar, 2018 3 commits
    • Kees Cook's avatar
      arm64: cpufeature: Remove redundant "feature" in reports · e0f6429d
      Kees Cook authored
      The word "feature" is repeated in the CPU features reporting. This drops it
      for improved readability.
      
      Before (redundant "feature" word):
      
       SMP: Total of 4 processors activated.
       CPU features: detected feature: 32-bit EL0 Support
       CPU features: detected feature: Kernel page table isolation (KPTI)
       CPU features: emulated: Privileged Access Never (PAN) using TTBR0_EL1 switching
       CPU: All CPU(s) started at EL2
      
      After:
      
       SMP: Total of 4 processors activated.
       CPU features: detected: 32-bit EL0 Support
       CPU features: detected: Kernel page table isolation (KPTI)
       CPU features: emulated: Privileged Access Never (PAN) using TTBR0_EL1 switching
       CPU: All CPU(s) started at EL2
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      e0f6429d
    • Kees Cook's avatar
      arm64: cpufeature: Relocate PAN emulation report · 2e6f549f
      Kees Cook authored
      The PAN emulation notification was only happening for non-boot CPUs
      if CPU capabilities had already been configured. This seems to be the
      wrong place, as it's system-wide and isn't attached to capabilities,
      so its reporting didn't normally happen. Instead, report it once from
      the boot CPU.
      
      Before (missing PAN emulation report):
      
       SMP: Total of 4 processors activated.
       CPU features: detected feature: 32-bit EL0 Support
       CPU features: detected feature: Kernel page table isolation (KPTI)
       CPU: All CPU(s) started at EL2
      
      After:
      
       SMP: Total of 4 processors activated.
       CPU features: detected feature: 32-bit EL0 Support
       CPU features: detected feature: Kernel page table isolation (KPTI)
       CPU features: emulated: Privileged Access Never (PAN) using TTBR0_EL1 switching
       CPU: All CPU(s) started at EL2
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      2e6f549f
    • Ard Biesheuvel's avatar
      arm64/kernel: kaslr: drop special Image placement logic · 6141ac1c
      Ard Biesheuvel authored
      Now that the early kernel mapping logic can tolerate placements of
      Image that cross swapper table boundaries, we can remove the logic
      that adjusts the offset if the dice roll produced an offset that
      puts the kernel right on top of one.
      Reviewed-by: default avatarSteve Capper <steve.capper@arm.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      6141ac1c