Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 May 2006 21:54:39 +0200
From:      Pawel Jakub Dawidek <pjd@FreeBSD.org>
To:        freebsd-current@FreeBSD.org
Cc:        gnn@FreeBSD.org, bz@FreeBSD.org
Subject:   Opencrypto changes. Review request.
Message-ID:  <20060516195439.GA94621@garage.freebsd.pl>

next in thread | raw e-mail | index | archive | help

--ZPt4rx8FFjLCG7dd
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi.

I'd like to ask for a review of the patches below:

	http://people.freebsd.org/~pjd/patches/netipsec.patch
	http://people.freebsd.org/~pjd/patches/opencrypto.patch
	http://people.freebsd.org/~pjd/patches/cryptodevs.patch

There are comments inside the patches, so I don't want to repeat them,
just some random comments what they gave us:

- Proper HMAC/SHA384 and HMAC/SHA512 handling. Currently the block size
  used for those functions is wrong, which makes caculation of the HMAC
  wrong. The block size for those functions should be 128, not 64
  bytes. The same bug exists in NetBSD, OpenBSD and some other
  independed implementations I looked at.

- De-IPsecing of HMACs. Currently crypto(9) framework calculates only 96
  bits long HMACs, which are only usable for IPsec.
  This will allow to use crypto(9) for other interesting things, like
  data authentication in geli(8), which is waiting in perforce.

- Allows to use HMAC/{SHA256,SHA384,SHA512} with any key length.
  Currently the hash function is choosen based on the key length, which
  is not right, as any key can be used with any function.

- Removes Giant-like lock the from most important code path in the
  crypto(9) framework and actually makes the path lockless.
  I haven't saw much improvement in running many IPsec tunnels in
  parallel. The lock contention is entirely removed for the lock, but
  there are other bottlenecks.
  On the other hang, on a 4 way amd64 machine I see more than 300%
  speed-up in geli(8) encryption/decryption.

I did some extensive testing of fast_ipsec(4) and geli(8) with those
changes and I see no problems [1]. I tested software crypto, hifn(4),
ubsec(4). safe(4) was only compile-tested, as I don't have access to the
hardware. padlock(4) is not affected by the changes, as it doesn't
handle HMACs yet.

[1] Actually there was one problem, but not related to the change.
    It was causing SAD entries disappearing. This patch fixes the
    problem:

	http://people.freebsd.org/~pjd/patches/key.c.2.patch

Thank you in advance!

PS. I'd like to thank Mike Tancsa and Sentex from giving me access to
    the test hardware (machines and crypto cards) and all the help.
    I'd also like to thank all netperf cluster sponsors. The netperf
    cluster is very, very useful. There is more interesting work comming
    from me, which was possible to do, because of its existence.
    Thank you!:)

--=20
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!

--ZPt4rx8FFjLCG7dd
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFEai3/ForvXbEpPzQRAgiDAJ9M8WtnKsF5ONJlo+WJZAnEaMq9IACfd+Kt
zUwsGtA20vq07GTRhEXxknY=
=GhyI
-----END PGP SIGNATURE-----

--ZPt4rx8FFjLCG7dd--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060516195439.GA94621>