[illumos-Developer] webrev: removal of closed kcfd

[Richard Lowe]

Garrett D'Amore wrote:
> http://mexico.purplecow.org/gdamore/webrev/nokcfd/

general:

  - Is there any worth in leaving FIPS support sufficient to lock out
    non-FIPS algorithms and modes, run the self-tests, and just not do
    module verification?  I appreciate that's not compliant, but is it
    useful?

    You and I had discussed this offline, and mostly thought "No", since
    the value of FIPS is solely the certification.

  - Is the FIPS removal a simple backout of its introduction (and
    subsequent).  Or done some other way?

    (I'm looking for an indication it's suitably complete)

  - Did you test that priocntl, pbind, etc, function on your process?

usr/src/cmd/cmd-crypto/cryptoadm/cryptoadm.c:1211,1212:

      nit: Self evident.

usr/src/cmd/cmd-crypto/cryptoadm/cryptoadm.h:40

      Should no longer be necessary

usr/src/uts/common/crypto/core/kcf.c:95

      Because we can do this at this point, with your changes, rather
      than when kcfd shows us the door as before, right?

usr/src/uts/common/crypto/core/kcf_sched.c:206

      nit: A period is one ., an ellipsis is three.  You can't have
      two.

usr/src/uts/common/crypto/core/kcf_sched.c:1027

      cv_reltimedwait() should never return 0, only -1 on timeout,
      and > 0 when signalled (cv_signal), no?

usr/src/uts/common/crypto/core/kcf_sched.c:1395,1396

      nit: process names don't agree, "kcfpool" v. "kcfpoold"

usr/src/uts/common/sys/crypto/sched_impl.h:379

      "... also protects the three fileds above"

      This is probably not true, as you deleted 5 fields preceding
      this comment, if it is still true, please fix the spelling of
      fields.

usr/src/uts/common/sys/crypto/spi.h:48
usr/src/uts/common/sys/crypto/spi.h:493,500
usr/src/uts/common/sys/crypto/spi.h:536,548
usr/src/uts/common/sys/crypto/spi.h:566

      co_fips140_ops is useless, after your changes.  Can it be safely
      removed, given that the API is versioned?  Or does it make more
      sense to leave CRYPTO_SPI_VERSION_4, so the API versioning
      continues to line up.

      Either way, I think you should remove the implementations of this
      entry point from the VERSION_4 providers, since the code will
      never be called.

-- Rich