1. 23 12月, 2017 8 次提交
  2. 11 12月, 2017 19 次提交
  3. 09 12月, 2017 1 次提交
  4. 07 12月, 2017 5 次提交
    • D
      arm64/sve: Avoid dereference of dead task_struct in KVM guest entry · cb968afc
      Dave Martin 提交于
      When deciding whether to invalidate FPSIMD state cached in the cpu,
      the backend function sve_flush_cpu_state() attempts to dereference
      __this_cpu_read(fpsimd_last_state).  However, this is not safe:
      there is no guarantee that this task_struct pointer is still valid,
      because the task could have exited in the meantime.
      
      This means that we need another means to get the appropriate value
      of TIF_SVE for the associated task.
      
      This patch solves this issue by adding a cached copy of the TIF_SVE
      flag in fpsimd_last_state, which we can check without dereferencing
      the task pointer.
      
      In particular, although this patch is not a KVM fix per se, this
      means that this check is now done safely in the KVM world switch
      path (which is currently the only user of this code).
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Christoffer Dall <christoffer.dall@linaro.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      cb968afc
    • W
      arm64: SW PAN: Update saved ttbr0 value on enter_lazy_tlb · d96cc49b
      Will Deacon 提交于
      enter_lazy_tlb is called when a kernel thread rides on the back of
      another mm, due to a context switch or an explicit call to unuse_mm
      where a call to switch_mm is elided.
      
      In these cases, it's important to keep the saved ttbr value up to date
      with the active mm, otherwise we can end up with a stale value which
      points to a potentially freed page table.
      
      This patch implements enter_lazy_tlb for arm64, so that the saved ttbr0
      is kept up-to-date with the active mm for kernel threads.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Vinayak Menon <vinmenon@codeaurora.org>
      Cc: <stable@vger.kernel.org>
      Fixes: 39bc88e5 ("arm64: Disable TTBR0_EL1 during normal kernel execution")
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NMark Rutland <mark.rutland@arm.com>
      Reported-by: NVinayak Menon <vinmenon@codeaurora.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      d96cc49b
    • W
      arm64: SW PAN: Point saved ttbr0 at the zero page when switching to init_mm · 0adbdfde
      Will Deacon 提交于
      update_saved_ttbr0 mandates that mm->pgd is not swapper, since swapper
      contains kernel mappings and should never be installed into ttbr0. However,
      this means that callers must avoid passing the init_mm to update_saved_ttbr0
      which in turn can cause the saved ttbr0 value to be out-of-date in the context
      of the idle thread. For example, EFI runtime services may leave the saved ttbr0
      pointing at the EFI page table, and kernel threads may end up with stale
      references to freed page tables.
      
      This patch changes update_saved_ttbr0 so that the init_mm points the saved
      ttbr0 value to the empty zero page, which always exists and never contains
      valid translations. EFI and switch can then call into update_saved_ttbr0
      unconditionally.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Vinayak Menon <vinmenon@codeaurora.org>
      Cc: <stable@vger.kernel.org>
      Fixes: 39bc88e5 ("arm64: Disable TTBR0_EL1 during normal kernel execution")
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NMark Rutland <mark.rutland@arm.com>
      Reported-by: NVinayak Menon <vinmenon@codeaurora.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      0adbdfde
    • D
      arm64: fpsimd: Abstract out binding of task's fpsimd context to the cpu. · 8884b7bd
      Dave Martin 提交于
      There is currently some duplicate logic to associate current's
      FPSIMD context with the cpu when loading FPSIMD state into the cpu
      regs.
      
      Subsequent patches will update that logic, so in order to ensure it
      only needs to be done in one place, this patch factors the relevant
      code out into a new function fpsimd_bind_to_cpu().
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      8884b7bd
    • D
      arm64: fpsimd: Prevent registers leaking from dead tasks · 071b6d4a
      Dave Martin 提交于
      Currently, loading of a task's fpsimd state into the CPU registers
      is skipped if that task's state is already present in the registers
      of that CPU.
      
      However, the code relies on the struct fpsimd_state * (and by
      extension struct task_struct *) to unambiguously identify a task.
      
      There is a particular case in which this doesn't work reliably:
      when a task exits, its task_struct may be recycled to describe a
      new task.
      
      Consider the following scenario:
      
       1) Task P loads its fpsimd state onto cpu C.
              per_cpu(fpsimd_last_state, C) := P;
              P->thread.fpsimd_state.cpu := C;
      
       2) Task X is scheduled onto C and loads its fpsimd state on C.
              per_cpu(fpsimd_last_state, C) := X;
              X->thread.fpsimd_state.cpu := C;
      
       3) X exits, causing X's task_struct to be freed.
      
       4) P forks a new child T, which obtains X's recycled task_struct.
      	T == X.
      	T->thread.fpsimd_state.cpu == C (inherited from P).
      
       5) T is scheduled on C.
      	T's fpsimd state is not loaded, because
      	per_cpu(fpsimd_last_state, C) == T (== X) &&
      	T->thread.fpsimd_state.cpu == C.
      
              (This is the check performed by fpsimd_thread_switch().)
      
      So, T gets X's registers because the last registers loaded onto C
      were those of X, in (2).
      
      This patch fixes the problem by ensuring that the sched-in check
      fails in (5): fpsimd_flush_task_state(T) is called when T is
      forked, so that T->thread.fpsimd_state.cpu == C cannot be true.
      This relies on the fact that T is not schedulable until after
      copy_thread() completes.
      
      Once T's fpsimd state has been loaded on some CPU C there may still
      be other cpus D for which per_cpu(fpsimd_last_state, D) ==
      &X->thread.fpsimd_state.  But D is necessarily != C in this case,
      and the check in (5) must fail.
      
      An alternative fix would be to do refcounting on task_struct.  This
      would result in each CPU holding a reference to the last task whose
      fpsimd state was loaded there.  It's not clear whether this is
      preferable, and it involves higher overhead than the fix proposed
      in this patch.  It would also move all the task_struct freeing
      work into the context switch critical section, or otherwise some
      deferred cleanup mechanism would need to be introduced, neither of
      which seems obviously justified.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 005f78cd ("arm64: defer reloading a task's FPSIMD state to userland resume")
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      [will: word-smithed the comment so it makes more sense]
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      071b6d4a
  5. 05 12月, 2017 1 次提交
  6. 03 12月, 2017 1 次提交
  7. 01 12月, 2017 5 次提交