1. 19 Mar, 2018 4 commits
  2. 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
  3. 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
  4. 06 Mar, 2018 15 commits
  5. 05 Mar, 2018 4 commits
  6. 26 Feb, 2018 6 commits