Date: Fri, 6 Nov 2020 16:46:29 +1100 From: Dewayne Geraghty <dewayne@heuristicsystems.com.au> To: FreeBSD Stable Mailing List <freebsd-stable@freebsd.org> Subject: Has geli broken when using authentication (hmac/sha256)? Message-ID: <22acef0d-910a-2dae-53ac-7c4de5d0e4e3@heuristicsystems.com.au>
next in thread | raw e-mail | index | archive | help
Using FreeBSD 12.2S r367125M, to
# geli init -a HMAC/SHA256 -e aes-cbc -l 128 -P -s 4096 -K /tmp/key ${D}s1a
fails during newfs,
# newfs -O2 -U ${D}s1a.eli
newfs: can't read old UFS1 superblock: read error from block device:
Invalid argument
Using geli with encryption only, works as usual. But using hmac/sha256
fails when used with "-e null" or in combination with a cipher.
Using encryption only, everything is normal, ie newfs ok, the filesystem
mounts and is accessible.
Could someone verify if something is broken? I've included my test case
below:
--
Reproducible with:
D=/dev/md0
# Cleanup previous runs
umount /mnt/A
geli detach ${D}s1a || true
mdconfig -du 0 || TRUE
rm /tmp/test || true
truncate -s 64m /tmp/test
mdconfig -t vnode -f /tmp/test
gpart create -s MBR ${D}
gpart add -a 4k -s 14m -t freebsd $D
gpart add -a 4k -s 10m -t freebsd $D
gpart add -a 4k -s 10m -t freebsd $D
gpart create -s bsd ${D}s1
gpart create -s bsd ${D}s2
gpart add -a 4k -s 10m -t freebsd-ufs ${D}s1
openssl rand -hex -out /tmp/key 32
geli init -a HMAC/SHA256 -e aes-cbc -l 128 -P -s 4096 -K /tmp/key ${D}s1a
geli attach -p -k /tmp/key ${D}s1a
newfs -O2 -U ${D}s1a.eli
/dev/md0s1a.eli: 8.9MB (18200 sectors) block size 32768, fragment size 4096
using 4 cylinder groups of 2.25MB, 72 blks, 384 inodes.
with soft updates
newfs: can't read old UFS1 superblock: read error from block device:
Invalid argument
However using UFS1, newfs succeeds but the mount fails.
newfs -O1 -U ${D}s1a.eli
/dev/md0s1a.eli: 8.9MB (18200 sectors) block size 32768, fragment size 4096
using 4 cylinder groups of 2.25MB, 72 blks, 512 inodes.
with soft updates
super-block backups (for fsck_ffs -b #) at:
64, 4672, 9280, 13888
# mount -v /dev/md0s1a.eli /mnt/A
mount: /dev/md0s1a.eli: Invalid argument
The only change that may be related is:
# svnlite log -l 4 /usr/src/tests/sys/geom/class/eli
------------------------------------------------------------------------
r363486 | asomers | 2020-07-25 04:19:25 +1000 (Sat, 25 Jul 2020) | 13 lines
MFC r363014:
geli: enable direct dispatch
geli does all of its crypto operations in a separate thread pool, so
g_eli_start, g_eli_read_done, and g_eli_write_done don't actually do very
much work. Enabling direct dispatch eliminates the g_up/g_down bottlenecks,
doubling IOPs on my system. This change does not affect the thread pool.
Reviewed by: markj
Sponsored by: Axcient
Differential Revision: https://reviews.freebsd.org/D25587
Cheers, Dewayne
--
*** NOTICE This email and any attachments may contain legally privileged
or confidential information and may be protected by copyright. You must
not use or disclose them other than for the purposes for which they were
supplied. The privilege or confidentiality attached to this message and
attachments is not waived by reason of mistaken delivery to you. If you
are not the intended recipient, you must not use, disclose, retain,
forward or reproduce this message or any attachments. If you receive
this message in error please notify the sender by return email or
telephone and destroy and delete all copies. ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22acef0d-910a-2dae-53ac-7c4de5d0e4e3>