[Bug 218597] [CRYPTODEV] spurious wakeup and synchronisation problem

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218597

            Bug ID: 218597
           Summary: [CRYPTODEV] spurious wakeup and synchronisation
                    problem
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: alexandre.martins at stormshield.eu

Created attachment 181725
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=181725&action=edit
proposed patch

I using a dual core ARMADA 38X platform that contains a CESA module to
accelerate cryptography operations.

I have some crashes when using the cryptodev through OpenSSL.

The crash only happen when the following conditions are met:
 - Multi-core system is used
 - Hardware acceleration is used
 - Hardware acceleration perform an interruption to signal the operations
completion

That are the scenario, first:
 - A process ask a cryptographic operation
 - The crypto operation is send to the CESA
 - msleep is called, but the process seems to be migrated on another CPU, and
msleep return immediately (spurious wakeup)
   (I puted a KASSERT that check if the CRYPTO_F_DONE is present and it rise)
 - The operation looks like complete and memory is freed
 - The CESA performs the cryptographic operation on the freed memory that may
cause corruption in some other parts of the kernel.

Second:
 - The call to crypto_dispatch is done, but the scheduler prempt the process
before the lock on ces->lock is done
 - The CESA perform the operation and crypto_done is called by the ithread
 - The flag CRYPTO_F_DONE is put and scheduler preempt the ithread
 - The user process continue, take the lock and check the flag, that is
present, and doesn't call msleep.
 - It free the memory, and return to the userland
 - The ithread is resumed and calls the callbacks that crash by accessing the
freed memory.

I attach my proposed patch to fix that issue

-- 
You are receiving this mail because:
You are the assignee for the bug.