1. 26 Mar, 2018 23 commits
    • Suzuki K Poulose's avatar
      arm64: Add work around for Arm Cortex-A55 Erratum 1024718 · ece1397c
      Suzuki K Poulose authored
      Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer
      from an erratum 1024718, which causes incorrect updates when DBM/AP
      bits in a page table entry is modified without a break-before-make
      sequence. The work around is to skip enabling the hardware DBM feature
      on the affected cores. The hardware Access Flag management features
      is not affected. There are some other cores suffering from this
      errata, which could be added to the midr_list to trigger the work
      around.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: ckadabi@codeaurora.org
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      ece1397c
    • Suzuki K Poulose's avatar
      arm64: Delay enabling hardware DBM feature · 05abb595
      Suzuki K Poulose authored
      We enable hardware DBM bit in a capable CPU, very early in the
      boot via __cpu_setup. This doesn't give us a flexibility of
      optionally disable the feature, as the clearing the bit
      is a bit costly as the TLB can cache the settings. Instead,
      we delay enabling the feature until the CPU is brought up
      into the kernel. We use the feature capability mechanism
      to handle it.
      
      The hardware DBM is a non-conflicting feature. i.e, the kernel
      can safely run with a mix of CPUs with some using the feature
      and the others don't. So, it is safe for a late CPU to have
      this capability and enable it, even if the active CPUs don't.
      
      To get this handled properly by the infrastructure, we
      unconditionally set the capability and only enable it
      on CPUs which really have the feature. Also, we print the
      feature detection from the "matches" call back to make sure
      we don't mislead the user when none of the CPUs could use the
      feature.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      05abb595
    • Suzuki K Poulose's avatar
      arm64: Add MIDR encoding for Arm Cortex-A55 and Cortex-A35 · 6e616864
      Suzuki K Poulose authored
      Update the MIDR encodings for the Cortex-A55 and Cortex-A35
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      6e616864
    • Suzuki K Poulose's avatar
      arm64: capabilities: Handle shared entries · ba7d9233
      Suzuki K Poulose authored
      Some capabilities have different criteria for detection and associated
      actions based on the matching criteria, even though they all share the
      same capability bit. So far we have used multiple entries with the same
      capability bit to handle this. This is prone to errors, as the
      cpu_enable is invoked for each entry, irrespective of whether the
      detection rule applies to the CPU or not. And also this complicates
      other helpers, e.g, __this_cpu_has_cap.
      
      This patch adds a wrapper entry to cover all the possible variations
      of a capability by maintaining list of matches + cpu_enable callbacks.
      To avoid complicating the prototypes for the "matches()", we use
      arm64_cpu_capabilities maintain the list and we ignore all the other
      fields except the matches & cpu_enable.
      
      This ensures :
      
       1) The capabilitiy is set when at least one of the entry detects
       2) Action is only taken for the entries that "matches".
      
      This avoids explicit checks in the cpu_enable() take some action.
      The only constraint here is that, all the entries should have the
      same "type" (i.e, scope and conflict rules).
      
      If a cpu_enable() method is associated with multiple matches for a
      single capability, care should be taken that either the match criteria
      are mutually exclusive, or that the method is robust against being
      called multiple times.
      
      This also reverts the changes introduced by commit 67948af4
      ("arm64: capabilities: Handle duplicate entries for a capability").
      
      Cc: Robin Murphy <robin.murphy@arm.com>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      ba7d9233
    • Suzuki K Poulose's avatar
      arm64: capabilities: Add support for checks based on a list of MIDRs · be5b2998
      Suzuki K Poulose authored
      Add helpers for detecting an errata on list of midr ranges
      of affected CPUs, with the same work around.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      be5b2998
    • Suzuki K Poulose's avatar
      arm64: Add helpers for checking CPU MIDR against a range · 1df31050
      Suzuki K Poulose authored
      Add helpers for checking if the given CPU midr falls in a range
      of variants/revisions for a given model.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      1df31050
    • Suzuki K Poulose's avatar
      arm64: capabilities: Clean up midr range helpers · 5e7951ce
      Suzuki K Poulose authored
      We are about to introduce generic MIDR range helpers. Clean
      up the existing helpers in erratum handling, preparing them
      to use generic version.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      5e7951ce
    • Suzuki K Poulose's avatar
      arm64: capabilities: Change scope of VHE to Boot CPU feature · 830dcc9f
      Suzuki K Poulose authored
      We expect all CPUs to be running at the same EL inside the kernel
      with or without VHE enabled and we have strict checks to ensure
      that any mismatch triggers a kernel panic. If VHE is enabled,
      we use the feature based on the boot CPU and all other CPUs
      should follow. This makes it a perfect candidate for a capability
      based on the boot CPU,  which should be matched by all the CPUs
      (both when is ON and OFF). This saves us some not-so-pretty
      hooks and special code, just for verifying the conflict.
      
      The patch also makes the VHE capability entry depend on
      CONFIG_ARM64_VHE.
      
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      830dcc9f
    • Suzuki K Poulose's avatar
      arm64: capabilities: Add support for features enabled early · fd9d63da
      Suzuki K Poulose authored
      The kernel detects and uses some of the features based on the boot
      CPU and expects that all the following CPUs conform to it. e.g,
      with VHE and the boot CPU running at EL2, the kernel decides to
      keep the kernel running at EL2. If another CPU is brought up without
      this capability, we use custom hooks (via check_early_cpu_features())
      to handle it. To handle such capabilities add support for detecting
      and enabling capabilities based on the boot CPU.
      
      A bit is added to indicate if the capability should be detected
      early on the boot CPU. The infrastructure then ensures that such
      capabilities are probed and "enabled" early on in the boot CPU
      and, enabled on the subsequent CPUs.
      
      Cc: Julien Thierry <julien.thierry@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      fd9d63da
    • Suzuki K Poulose's avatar
      arm64: capabilities: Restrict KPTI detection to boot-time CPUs · d3aec8a2
      Suzuki K Poulose authored
      KPTI is treated as a system wide feature and is only detected if all
      the CPUs in the sysetm needs the defense, unless it is forced via kernel
      command line. This leaves a system with a mix of CPUs with and without
      the defense vulnerable. Also, if a late CPU needs KPTI but KPTI was not
      activated at boot time, the CPU is currently allowed to boot, which is a
      potential security vulnerability.
      This patch ensures that the KPTI is turned on if at least one CPU detects
      the capability (i.e, change scope to SCOPE_LOCAL_CPU). Also rejetcs a late
      CPU, if it requires the defense, when the system hasn't enabled it,
      
      Cc: Will Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      d3aec8a2
    • Suzuki K Poulose's avatar
      arm64: capabilities: Introduce weak features based on local CPU · 5c137714
      Suzuki K Poulose authored
      Now that we have the flexibility of defining system features based
      on individual CPUs, introduce CPU feature type that can be detected
      on a local SCOPE and ignores the conflict on late CPUs. This is
      applicable for ARM64_HAS_NO_HW_PREFETCH, where it is fine for
      the system to have CPUs without hardware prefetch turning up
      later. We only suffer a performance penalty, nothing fatal.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      5c137714
    • Suzuki K Poulose's avatar
      arm64: capabilities: Group handling of features and errata workarounds · ed478b3f
      Suzuki K Poulose authored
      Now that the features and errata workarounds have the same
      rules and flow, group the handling of the tables.
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      ed478b3f
    • Suzuki K Poulose's avatar
      arm64: capabilities: Allow features based on local CPU scope · fbd890b9
      Suzuki K Poulose authored
      So far we have treated the feature capabilities as system wide
      and this wouldn't help with features that could be detected locally
      on one or more CPUs (e.g, KPTI, Software prefetch). This patch
      splits the feature detection to two phases :
      
       1) Local CPU features are checked on all boot time active CPUs.
       2) System wide features are checked only once after all CPUs are
          active.
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      fbd890b9
    • Suzuki K Poulose's avatar
      arm64: capabilities: Split the processing of errata work arounds · d69fe9a7
      Suzuki K Poulose authored
      Right now we run through the errata workarounds check on all boot
      active CPUs, with SCOPE_ALL. This wouldn't help for detecting erratum
      workarounds with a SYSTEM_SCOPE. There are none yet, but we plan to
      introduce some: let us clean this up so that such workarounds can be
      detected and enabled correctly.
      
      So, we run the checks with SCOPE_LOCAL_CPU on all CPUs and SCOPE_SYSTEM
      checks are run only once after all the boot time CPUs are active.
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      d69fe9a7
    • Suzuki K Poulose's avatar
      arm64: capabilities: Prepare for grouping features and errata work arounds · 600b9c91
      Suzuki K Poulose authored
      We are about to group the handling of all capabilities (features
      and errata workarounds). This patch open codes the wrapper routines
      to make it easier to merge the handling.
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      600b9c91
    • Suzuki K Poulose's avatar
      arm64: capabilities: Filter the entries based on a given mask · cce360b5
      Suzuki K Poulose authored
      While processing the list of capabilities, it is useful to
      filter out some of the entries based on the given mask for the
      scope of the capabilities to allow better control. This can be
      used later for handling LOCAL vs SYSTEM wide capabilities and more.
      All capabilities should have their scope set to either LOCAL_CPU or
      SYSTEM. No functional/flow change.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      cce360b5
    • Suzuki K Poulose's avatar
      arm64: capabilities: Unify the verification · eaac4d83
      Suzuki K Poulose authored
      Now that each capability describes how to treat the conflicts
      of CPU cap state vs System wide cap state, we can unify the
      verification logic to a single place.
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      eaac4d83
    • Suzuki K Poulose's avatar
      arm64: capabilities: Add flags to handle the conflicts on late CPU · 5b4747c5
      Suzuki K Poulose authored
      When a CPU is brought up, it is checked against the caps that are
      known to be enabled on the system (via verify_local_cpu_capabilities()).
      Based on the state of the capability on the CPU vs. that of System we
      could have the following combinations of conflict.
      
      	x-----------------------------x
      	| Type  | System   | Late CPU |
      	|-----------------------------|
      	|  a    |   y      |    n     |
      	|-----------------------------|
      	|  b    |   n      |    y     |
      	x-----------------------------x
      
      Case (a) is not permitted for caps which are system features, which the
      system expects all the CPUs to have (e.g VHE). While (a) is ignored for
      all errata work arounds. However, there could be exceptions to the plain
      filtering approach. e.g, KPTI is an optional feature for a late CPU as
      long as the system already enables it.
      
      Case (b) is not permitted for errata work arounds that cannot be activated
      after the kernel has finished booting.And we ignore (b) for features. Here,
      yet again, KPTI is an exception, where if a late CPU needs KPTI we are too
      late to enable it (because we change the allocation of ASIDs etc).
      
      Add two different flags to indicate how the conflict should be handled.
      
       ARM64_CPUCAP_PERMITTED_FOR_LATE_CPU - CPUs may have the capability
       ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU - CPUs may not have the cappability.
      
      Now that we have the flags to describe the behavior of the errata and
      the features, as we treat them, define types for ERRATUM and FEATURE.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      5b4747c5
    • Suzuki K Poulose's avatar
      arm64: capabilities: Prepare for fine grained capabilities · 143ba05d
      Suzuki K Poulose authored
      We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
      to the userspace and the CPU hwcaps used by the kernel, which
      include cpu features and CPU errata work arounds. Capabilities
      have some properties that decide how they should be treated :
      
       1) Detection, i.e scope : A cap could be "detected" either :
          - if it is present on at least one CPU (SCOPE_LOCAL_CPU)
      	Or
          - if it is present on all the CPUs (SCOPE_SYSTEM)
      
       2) When is it enabled ? - A cap is treated as "enabled" when the
        system takes some action based on whether the capability is detected or
        not. e.g, setting some control register, patching the kernel code.
        Right now, we treat all caps are enabled at boot-time, after all
        the CPUs are brought up by the kernel. But there are certain caps,
        which are enabled early during the boot (e.g, VHE, GIC_CPUIF for NMI)
        and kernel starts using them, even before the secondary CPUs are brought
        up. We would need a way to describe this for each capability.
      
       3) Conflict on a late CPU - When a CPU is brought up, it is checked
        against the caps that are known to be enabled on the system (via
        verify_local_cpu_capabilities()). Based on the state of the capability
        on the CPU vs. that of System we could have the following combinations
        of conflict.
      
      	x-----------------------------x
      	| Type	| System   | Late CPU |
      	------------------------------|
      	|  a    |   y      |    n     |
      	------------------------------|
      	|  b    |   n      |    y     |
      	x-----------------------------x
      
        Case (a) is not permitted for caps which are system features, which the
        system expects all the CPUs to have (e.g VHE). While (a) is ignored for
        all errata work arounds. However, there could be exceptions to the plain
        filtering approach. e.g, KPTI is an optional feature for a late CPU as
        long as the system already enables it.
      
        Case (b) is not permitted for errata work arounds which requires some
        work around, which cannot be delayed. And we ignore (b) for features.
        Here, yet again, KPTI is an exception, where if a late CPU needs KPTI we
        are too late to enable it (because we change the allocation of ASIDs
        etc).
      
      So this calls for a lot more fine grained behavior for each capability.
      And if we define all the attributes to control their behavior properly,
      we may be able to use a single table for the CPU hwcaps (which cover
      errata and features, not the ELF HWCAPs). This is a prepartory step
      to get there. More bits would be added for the properties listed above.
      
      We are going to use a bit-mask to encode all the properties of a
      capabilities. This patch encodes the "SCOPE" of the capability.
      
      As such there is no change in how the capabilities are treated.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      143ba05d
    • Suzuki K Poulose's avatar
      arm64: capabilities: Move errata processing code · 1e89baed
      Suzuki K Poulose authored
      We have errata work around processing code in cpu_errata.c,
      which calls back into helpers defined in cpufeature.c. Now
      that we are going to make the handling of capabilities
      generic, by adding the information to each capability,
      move the errata work around specific processing code.
      No functional changes.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Andre Przywara <andre.przywara@arm.com>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      1e89baed
    • Suzuki K Poulose's avatar
      arm64: capabilities: Move errata work around check on boot CPU · 5e91107b
      Suzuki K Poulose authored
      We trigger CPU errata work around check on the boot CPU from
      smp_prepare_boot_cpu() to make sure that we run the checks only
      after the CPU feature infrastructure is initialised. While this
      is correct, we can also do this from init_cpu_features() which
      initilises the infrastructure, and is called only on the
      Boot CPU. This helps to consolidate the CPU capability handling
      to cpufeature.c. No functional changes.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarDave Martin <dave.martin@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      5e91107b
    • 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 4 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