[illumos-Developer] webrev: removal of closed kcfd

[Garrett D'Amore]

On Sun, 2010-09-05 at 00:15 +0200, Joerg Schilling wrote:
> "Garrett D'Amore" <garrett at nexenta.com> wrote:
> 
> > This is a first pass at removing the closed kcfd.  It removes the
> > daemon, and also does away with all fips and module verification, and
> > runs the kernel threads for crypto using lwps in the kernel rather than
> > relying on a daemon.  (Thanks to richlowe for the suggestion.)
> >
> > http://mexico.purplecow.org/gdamore/webrev/nokcfd/
> 
> Why did you remove fips?

Because you can't have fips without module verification.  And you can't
have module verification without the closed code or reimplementing the
closed code.

Furthermore, FIPS is *very* difficult to get right, and requires quite a
bit beyond just writing the code.  So there's no way we could continue
to have a FIPS solution without massive investment.

As far as leaving the stale code around -- there are multiple approaches
that can be taken with FIPS depending on where you draw the
cryptographic boundary, and what level you aim for.  The design
decisions made in the previous implementation were specific to Sun
certification goals.  Other certification attempts could reasonably
choose differently.  So leaving a bunch of stale code behind, without a
clear notion that it would be used someday, seems foolish to me.

> 
> If you could tell us a bit more about the general background ideas for the 
> changes, I could have a look the the webrev. Otherwise, I am not sure how to
> do a sufficient revire.

The general background is to provide the required functionality for
cryptographic services without relying on closed code.  FIPS support was
explicitly *not* a goal.  Module verification is *not* a goal, because
its not clear that this is required for US Export control anymore --
certainly not for an open source software product.

Furthermore, the previous module verification code was "just enough" to
pass certification, and not truly secure, so spending time to make that
work with open code seems foolish without a compelling business case.

If someone wants "real" security, they should try to involve the early
boot flow and TPM logic.  This is a non-trivial effort, and not part of
this initial effort.

This initial effort is focused on the quickest path to open code.

	-- Garrett