From owner-freebsd-stable@freebsd.org Sat Nov 7 10:06:44 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A3D2D2EACB4 for ; Sat, 7 Nov 2020 10:06:44 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CStFv5j7nz4cY2 for ; Sat, 7 Nov 2020 10:06:43 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 0A7A6aFP090673 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 7 Nov 2020 02:06:36 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 0A7A6ZnC090672; Sat, 7 Nov 2020 02:06:35 -0800 (PST) (envelope-from jmg) Date: Sat, 7 Nov 2020 02:06:35 -0800 From: John-Mark Gurney To: Dewayne Geraghty Cc: FreeBSD Stable Mailing List Subject: Re: Has geli broken when using authentication (hmac/sha256)? Message-ID: <20201107100635.GF31099@funkthat.com> Mail-Followup-To: Dewayne Geraghty , FreeBSD Stable Mailing List References: <22acef0d-910a-2dae-53ac-7c4de5d0e4e3@heuristicsystems.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22acef0d-910a-2dae-53ac-7c4de5d0e4e3@heuristicsystems.com.au> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sat, 07 Nov 2020 02:06:36 -0800 (PST) X-Rspamd-Queue-Id: 4CStFv5j7nz4cY2 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [1.20 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MAILMAN_DEST(0.00)[freebsd-stable] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2020 10:06:44 -0000 Dewayne Geraghty wrote this message on Fri, Nov 06, 2020 at 16:46 +1100: > 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: What happens if you zero out the device first: dd if=/dev/zero of=${D}s1a.eli bs=1m If it's large, you likely only need to set the count to 1 or 2... newfs is likely trying to read make sure there aren't any old file systems there, but geli init doesn't write new data, so any reads will fail... Note that the geli man page says: It is recommended to write to the whole provider before first use, in order to make sure that all sectors and their corresponding checksums are properly initialized into a consistent state. One can safely ignore data authentication errors that occur immediately after the first time a provider is attached and before it is initialized in this way. Also, are you sure this worked BEFORE the changes? Because those changes shouldn't have caused this failure... > 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 I don't see a write here... > 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 This is likely trying to read a UFS v2 super block, failing, and not trying other locations... > 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. *** > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."