From nobody@FreeBSD.org  Sun Sep 25 16:27:40 2011
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 61E2D106564A
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 25 Sep 2011 16:27:40 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id 4852F8FC08
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 25 Sep 2011 16:27:40 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p8PGReL5000616
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 25 Sep 2011 16:27:40 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id p8PGRejr000615;
	Sun, 25 Sep 2011 16:27:40 GMT
	(envelope-from nobody)
Message-Id: <201109251627.p8PGRejr000615@red.freebsd.org>
Date: Sun, 25 Sep 2011 16:27:40 GMT
From: Boris Pasko <pasko.boris@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: geli with HMAC/MD5 authentication fails during init/attach/use
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         161013
>Category:       kern
>Synopsis:       [geli] geli with HMAC/MD5 authentication fails during init/attach/use
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    pjd
>State:          feedback
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Sep 25 16:30:14 UTC 2011
>Closed-Date:    
>Last-Modified:  Mon Oct 10 19:43:32 UTC 2011
>Originator:     Boris Pasko
>Release:        9.0-BETA2
>Organization:
N/A
>Environment:
FreeBSD 9.0-BETA2 FreeBSD 9.0-BETA2 #0: Web Aug 31 18:07:44 UTC root@farrell.cse.buffalo.edu:/usr/obj/src/sys/GENERIC amd64
>Description:
When using GELI with any data authentication algorithm (I tried HMAC/MD5 and HMAC/SHA256), geli fails even on first attach with messages like:

GEOM_ELI: da0s1.eli: 512 bytes corrupted at offset 8192

Even if you dd the attached encrypted partition with random bytes or zeroes (forcing geli to "fix" the disk), the disk appear to work until you try to install Freebsd on it. The install will fail with kernel panic.


Production release (RELENG-8.2) does not output any errors.
>How-To-Repeat:
1. Create VMWare virtual machine with one harddisk

2. Boot the 9.0 installation disk

3. When prompted for partition allocation, choose <<SHELL>>

4. create small partition on disk:

# gpart create -s MBR da0
da0 created
# gpart add -t freebsd -s 10M da0
da0s1 added

5. initialize geli on a partition using HMAC/MD5 authentication

# geli init -v -b -e AES -l 256 -a HMAC/MD5 /dev/da0s1
Enter new passphrase:
Reenter new passphrase:
[skipping some output]
Done.

6. Now try to attach

# geli attach /dev/da0s1
Enter passphrase:
GEOM_ELI: Device da0s1.eli created
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI:  Integrity: HMAC/MD5
GEOM_ELI:     Crypto: software
GEOM_ELI: da0s1.eli: 512 bytes corrupted at offset 512.
GEOM_ELI: da0s1.eli: 512 bytes corrupted at offset 0.
GEOM_ELI: da0s1.eli: 512 bytes corrupted at offset 5240832.
GEOM_ELI: da0s1.eli: 512 bytes corrupted at offset 65536.
GEOM_ELI: da0s1.eli: 512 bytes corrupted at offset 8192.
GEOM_ELI: da0s1.eli: 512 bytes corrupted at offset 0.
GEOM_ELI: da0s1.eli: 512 bytes corrupted at offset 262144.
GEOM_ELI: da0s1.eli: 512 bytes corrupted at offset 65536.
GEOM_ELI: da0s1.eli: 512 bytes corrupted at offset 8192.
GEOM_ELI: da0s1.eli: 512 bytes corrupted at offset 0.
GEOM_ELI: da0s1.eli: 512 bytes corrupted at offset 262144.
GEOM_ELI: da0s1.eli: 512 bytes corrupted at offset 32768.
GEOM_ELI: da0s1.eli: 512 bytes corrupted at offset 0.
GEOM_ELI: da0s1.eli: 512 bytes corrupted at offset 1024.
GEOM_ELI: da0s1.eli: 512 bytes corrupted at offset 8192.
GEOM_ELI: da0s1.eli: 512 bytes corrupted at offset 65536.
GEOM_ELI: da0s1.eli: 512 bytes corrupted at offset 0.

7. Some additional investigation.
7.1. Try to dd the "bad" disk in order to "fix" problems

# dd if=/dev/random of=/dev/da0s1.eli
[Skipping dd output]
# geli detach /dev/da0s1.eli
GEOM_ELI: Device da0s1.eli destroyed.
# geli attach /dev/da0s1
Enter passphrase:
GEOM_ELI: Device da0s1.eli created
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI:  Integrity: HMAC/MD5
GEOM_ELI:     Crypto: software

no errors here, but if you try to install freebsd on the encrypted partition, it will fail with kernel panic (you need larger partition to try this, of course)

7.2. HMAC/SHA256 fails also
7.3. The same process with RELENG-8.2 works flawlessly

>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-geom 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Mon Oct 10 04:42:49 UTC 2011 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=161013 
State-Changed-From-To: open->feedback 
State-Changed-By: pjd 
State-Changed-When: pon 10 paź 2011 19:39:24 UTC 
State-Changed-Why:  
Hash mismatch warnings on GELI provider that is not initialized (filled with, 
eg. random data) after configuring GELI authentication are expected and this 
is not a bug. 

FreeBSD panicing during install sounds like a real problem, but has nothing to 
do with the warnings you saw. 

Please provide at least backtrace for the panic for starters. 


Responsible-Changed-From-To: freebsd-geom->pjd 
Responsible-Changed-By: pjd 
Responsible-Changed-When: pon 10 paź 2011 19:39:24 UTC 
Responsible-Changed-Why:  
I'll take this one. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=161013 
>Unformatted:
