- User Since
- May 15 2018, 3:36 AM (30 w, 6 d)
Thu, Dec 13
Re-implemented per cem's feedback. Tested with cryptocheck.
Wed, Dec 12
Tue, Dec 11
mmacy, there should be changes for cryptocheck as well.
Thu, Dec 6
Fix the larger-than-80-columns I got from using the wrong window for my editing.
Tue, Dec 4
Thu, Nov 29
Nov 14 2018
Nov 9 2018
Oct 11 2018
Oct 1 2018
Sep 29 2018
Sep 26 2018
Sep 25 2018
I have been unable to reproduce that panic, even on the same machine.
On a system with GELI swap, moving the lock until after the call to crypto_done() resulted in a panic (page fault while lock held). That doesn't make any sense to me. Changing it back to what I had initially resulted in a successful boot. So I'm going to be investigating this a bit more.
Turn a blank line into a real blank line.
But without the cryptocheck changes.
Upload the _right_ diff file.
Per feedback from mav and cem, move the unlock to before the callback..
I didn't profile it too much; I just walked through the code and saw that, with Reinit, the key schedule would get changed, and without locking, that could cause some problems.
Sep 24 2018
Ran the diff in the correct directory this time. Sorry.
Sep 20 2018
The ZFS side seems fine to me (I defer to stronger backgrounds on the VFS interactions).
Sep 7 2018
Feedback from mav -- removed some zfs crypto changes in sys/conf/files, and change the constants for the crypto algorithms.
Sep 6 2018
Jul 18 2018
Jul 10 2018
Jul 5 2018
Jun 18 2018
Incorporate feedback from delphij.
Is it possible to provide a switch to disable the SETQUOTA RPC?
Jun 16 2018
Jun 8 2018
Alexander pointed out that what I'd undone a change (range_tree_create()) because I'd ported from our 11-base system. Fixed that, and scrubbed a system a few times.
Jun 3 2018
Jun 2 2018
Then why wasn't the RFC noted in the comments then? There is the NIST version as well, which is what I was looking at originally.
Yes, we have done this before. When I did the GCM work under contract for the FreeBSD Foundation, they paid for a third party reviewer to go over the code and make sure it was correct. So, yes, we have done this before.
May 31 2018
Rewrote the AESNI decryption function to not leak the data. Added a link to the RFC I used as the specification. Cleaned up some code a bit. Became the first consumer of the aesencdec.h inline function.
May 28 2018
I was unable to review that the code matches an implementation, as the code does not state what implementation it implements. Even if I review it, a professional cryptographer needs to be paid to review the code before it is committed/enabled for general use.
May 26 2018
A late sequential-scan-related patch was mentioned when I created the PR for OpenZFS, it's at https://github.com/zfsonlinux/zfs/commit/a8b2e30685c9214c
May 25 2018
Somehow my copy of tcpdump's README got tweaked and in the diff. I've removed it.
Even though it exits, I should have a va_end() because otherwise someone will use it as an example.
May 24 2018
May 21 2018
Fix the fixable parts of mav's feedback. (cryptocheck.c remains the same, per my response to him.)
I wrote AESNI code for AES-CCM+CBC-MAC.
May 15 2018
Per Alexander, I created a different, more-contextful, diff.