1. 15 Feb, 2018 1 commit
  2. 12 Jan, 2018 2 commits
    • Eric Biggers's avatar
      crypto: hash - annotate algorithms taking optional key · a208fa8f
      Eric Biggers authored
      We need to consistently enforce that keyed hashes cannot be used without
      setting the key.  To do this we need a reliable way to determine whether
      a given hash algorithm is keyed or not.  AF_ALG currently does this by
      checking for the presence of a ->setkey() method.  However, this is
      actually slightly broken because the CRC-32 algorithms implement
      ->setkey() but can also be used without a key.  (The CRC-32 "key" is not
      actually a cryptographic key but rather represents the initial state.
      If not overridden, then a default initial state is used.)
      Prepare to fix this by introducing a flag CRYPTO_ALG_OPTIONAL_KEY which
      indicates that the algorithm has a ->setkey() method, but it is not
      required to be called.  Then set it on all the CRC-32 algorithms.
      The same also applies to the Adler-32 implementation in Lustre.
      Also, the cryptd and mcryptd templates have to pass through the flag
      from their underlying algorithm.
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
    • Eric Biggers's avatar
      crypto: mcryptd - pass through absence of ->setkey() · fa59b92d
      Eric Biggers authored
      When the mcryptd template is used to wrap an unkeyed hash algorithm,
      don't install a ->setkey() method to the mcryptd instance.  This change
      is necessary for mcryptd to keep working with unkeyed hash algorithms
      once we start enforcing that ->setkey() is called when present.
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
  3. 11 Dec, 2017 1 commit
    • Sebastian Andrzej Siewior's avatar
      crypto: mcryptd - protect the per-CPU queue with a lock · 9abffc6f
      Sebastian Andrzej Siewior authored
      mcryptd_enqueue_request() grabs the per-CPU queue struct and protects
      access to it with disabled preemption. Then it schedules a worker on the
      same CPU. The worker in mcryptd_queue_worker() guards access to the same
      per-CPU variable with disabled preemption.
      If we take CPU-hotplug into account then it is possible that between
      queue_work_on() and the actual invocation of the worker the CPU goes
      down and the worker will be scheduled on _another_ CPU. And here the
      preempt_disable() protection does not work anymore. The easiest thing is
      to add a spin_lock() to guard access to the list.
      Another detail: mcryptd_queue_worker() is not processing more than
      MCRYPTD_BATCH invocation in a row. If there are still items left, then
      it will invoke queue_work() to proceed with more later. *I* would
      suggest to simply drop that check because it does not use a system
      workqueue and the workqueue is already marked as "CPU_INTENSIVE". And if
      preemption is required then the scheduler should do it.
      However if queue_work() is used then the work item is marked as CPU
      unbound. That means it will try to run on the local CPU but it may run
      on another CPU as well. Especially with CONFIG_DEBUG_WQ_FORCE_RR_CPU=y.
      Again, the preempt_disable() won't work here but lock which was
      introduced will help.
      In order to keep work-item on the local CPU (and avoid RR) I changed it
      to queue_work_on().
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
  4. 29 Nov, 2017 1 commit
  5. 02 Mar, 2017 1 commit
  6. 07 Dec, 2016 1 commit
  7. 13 Sep, 2016 1 commit
  8. 23 Jun, 2016 1 commit
  9. 30 Jan, 2016 1 commit
  10. 23 Nov, 2015 1 commit
  11. 31 Mar, 2015 1 commit
  12. 26 Nov, 2014 1 commit
  13. 26 Aug, 2014 1 commit
  14. 25 Aug, 2014 1 commit
    • Tim Chen's avatar
      crypto: sha-mb - multibuffer crypto infrastructure · 1e65b81a
      Tim Chen authored
      This patch introduces the multi-buffer crypto daemon which is responsible
      for submitting crypto jobs in a work queue to the responsible multi-buffer
      crypto algorithm.  The idea of the multi-buffer algorihtm is to put
      data streams from multiple jobs in a wide (AVX2) register and then
      take advantage of SIMD instructions to do crypto computation on several
      buffers simultaneously.
      The multi-buffer crypto daemon is also responsbile for flushing the
      remaining buffers to complete the computation if no new buffers arrive
      for a while.
      Signed-off-by: 's avatarTim Chen <tim.c.chen@linux.intel.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>