On Mon, 31 Mar 2014 17:54:58 +1100
NeilBrown <neilb@xxxxxxx> wrote:
> On Thu, 27 Mar 2014 13:11:32 -0700 Jeff Layton <jlayton@xxxxxxxxxx> wrote:
>
> > On Thu, 27 Mar 2014 10:30:24 -0400
> > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote:
> >
> > > On Thu, Mar 27, 2014 at 08:52:39PM +1100, NeilBrown wrote:
> > > >
> > > > [I sent this 2 days ago but haven't seen it come back on the nfs
> > > > list and don't see it in the archives. Maybe someone we cannot
> > > > name filtered it because it contains the word 'crypto' ??]
> > >
> > > Huh.
>
> And my email still didn't get to the list, but at least it got to Bruce.
> And you replies only got to be directly, not through the list!
> Very weird ... I wonder if I care....
>
That is odd. Might be worth talking to DaveM and company and seeing why
they're getting dropped...
> > >
> > > > Apparently there is a thing called "FIPS" which lists some approved
> > > > crypto algorithms. And some sites need to only use those. So they
> > > > boot their kernel with
> > > > fips=1
> > > > and anything non-fips-approved stops working.
> > > >
> >
> > Yes. As best I can tell, the primary purpose of FIPS is to render the
> > machine unusable for any non-trivial purpose. ;)
>
> I'd notice this wasn't the only thing that broke. However it appear to be a
> thing that we want to support :-(
>
> >
> > The story I have heard is that FIPS carves out an exemption for the use
> > of unapproved crypto as long as it stays "within the
> > implementation" (whatever that means).
>
> So it is probably ok to use md5 as long as we don't pretend that we are doing
> crypto (which we aren't)
>
Probably, yes... The other problem with FIPS is that it's apparently
filled with a lot of weasel-words so getting definitive answers for
this sort of thing is pretty tough.
> >
> > > > "md5" is not fips-approved.
> > > >
> > > > So
> > > >
> > > > desc.tfm = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
> > > >
> > > > in
> > > >
> > > > nfs4_make_rec_clidname(char *dname, const struct xdr_netobj *clname)
> > > >
> > > >
> > > > always fails when fips=1. This interferes with efficient NFS
> > > > service (every 'open' hangs).
> > > >
> > > > s/md5/sha1/
> > > >
> > > > makes this problem go away, because sha1 is fips-approved.
> > > >
> > > > My question is: is this safe, or is the hash value used in some
> > > > external way (in /var/lib/nfs/v4recovery ??).
> > >
> >
> > The hashes aren't used outside the machine and they're not even
> > cryptographically significant. The kernel only uses it as a way to
> > squash the long-form clientid into something that it can use as a
> > directory name.
> >
> > In hindsight, the decision to use md5 for that purpose was
> > unfortunate...
>
> Isn't there a book about that .. "A series of unfortunate decisions" ...
>
>
> >
> > > Right, it's used in v4recovery, so you'd lose client state when you
> > > rebooted the server to the new (SHA1-using) server.
> > >
> > > Our intention was to migrate people that care about FIPS to the umh
> > > upcall. But rhel6 has a hack (a private md5 implementation).
> > >
> > > Cc'ing jlayton (currently traveling) who did that work.
> > >
> >
> > Yep, exactly.
> >
> > For any newer kernels and nfs-utils, just use nfsdcltrack and don't
> > bother with the legacy code. Eventually I can forsee us getting rid of
> > the legacy client tracking.
>
> Where "newer" means .... Linux v3.8 and nfs-utils 1.2.7.
> I'll keep that in mind for future releases then, thanks.
>
>
> >
> > > >
> > > > If changing the hash to sha1 is safe, we should do that and
> > > > probably add select CRYPTO_SHA1
> > > > to Kconfig just to be safe.
> > > >
> > > > If we really need to keep it stable, I guess we need to find a way
> > > > to perform md5 computations that bypasses the fips checks.
> >
> > For RHEL6 I just made a private md5 implementation. I had considered
> > switching it to sha1 instead, but the problem is that you'll lose
> > persistent state if you upgrade the kernel and it switches the hashing
> > implementation.
> >
>
> Sounds like a plan ... thanks for the help.
>
No problem. What I basically did was copy crypto/md5.c to the nfsd
directory and scrape out all of the crypto API goop. md5_transform() is
still available even when fips=1 is enabled. ;)
--
Jeff Layton <jlayton@xxxxxxxxxx>
Attachment:
signature.asc
Description: PGP signature
