From owner-freebsd-bugs@FreeBSD.ORG Sun Mar 4 20:50:12 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED2DB1065674 for ; Sun, 4 Mar 2012 20:50:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C60858FC0C for ; Sun, 4 Mar 2012 20:50:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q24KoCrQ003161 for ; Sun, 4 Mar 2012 20:50:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q24KoCG8003160; Sun, 4 Mar 2012 20:50:12 GMT (envelope-from gnats) Resent-Date: Sun, 4 Mar 2012 20:50:12 GMT Resent-Message-Id: <201203042050.q24KoCG8003160@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Robert Simmons Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98D6E1065673 for ; Sun, 4 Mar 2012 20:46:45 +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 797558FC1D for ; Sun, 4 Mar 2012 20:46:45 +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 q24Kkj0r009977 for ; Sun, 4 Mar 2012 20:46:45 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q24KkjpI009976; Sun, 4 Mar 2012 20:46:45 GMT (envelope-from nobody) Message-Id: <201203042046.q24KkjpI009976@red.freebsd.org> Date: Sun, 4 Mar 2012 20:46:45 GMT From: Robert Simmons To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/165695: Make geli errors on first attachment clearer when using data authentication X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 20:50:13 -0000 >Number: 165695 >Category: kern >Synopsis: Make geli errors on first attachment clearer when using data authentication >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Mar 04 20:50:12 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Robert Simmons >Release: 9.0-RELEASE >Organization: >Environment: FreeBSD test 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: Immediately after you attach a geli encrypted provider for the first time you get a series of error messages mentioning corrupted data such as the following if you configured that provider to use data authentication. GEOM_ELI: ada0p4.eli: 4096 bytes corrupted at offset 0. GEOM_ELI: ada0p4.eli: 4096 bytes corrupted at offset 4096. As the man page suggests, one must use dd to write to the entire provider to initialize it before its first use. These errors are because this initialization has not happened yet, and the data is failing authentication. These errors are harmless at this point, and can be safely ignored. I have patched the kernel errors to be more descriptive, and I've patched the man page to include a message about these errors and that they can be safely ignored. >How-To-Repeat: Replace the device node in the following with whatever is appropriate for your system. Also, the -a is imperative because that is what is enabling data authentication in the provider. geli init -b -v -a hmac/sha256 -l 256 -s 4096 /dev/ada0p4 geli attach /dev/ada0p4 After attaching this provider, you get the error messages in question. >Fix: I have included a unified diff to fix both the problem with the error messages and the man page to make sure what is happening is more clear. Patch attached with submission follows: diff -ur src/sbin/geom/class/eli/geli.8 src.new/sbin/geom/class/eli/geli.8 --- src/sbin/geom/class/eli/geli.8 2012-03-04 13:58:18.000000000 -0500 +++ src.new/sbin/geom/class/eli/geli.8 2012-03-04 14:52:36.000000000 -0500 @@ -925,6 +925,9 @@ 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. +Due to this, one can safely ignore data authentication errors that occur +immediately after the first time a provider is attached and when it is +initialized by writing to it to set a consistent state. .Sh SEE ALSO .Xr crypto 4 , .Xr gbde 4 , diff -ur src/sys/geom/eli/g_eli_integrity.c src.new/sys/geom/eli/g_eli_integrity.c --- src/sys/geom/eli/g_eli_integrity.c 2011-05-08 05:17:56.000000000 -0400 +++ src.new/sys/geom/eli/g_eli_integrity.c 2012-03-04 15:12:58.000000000 -0500 @@ -206,7 +206,7 @@ */ if (coroff != -1) { G_ELI_DEBUG(0, "%s: %jd bytes " - "corrupted at offset %jd.", + "not authenticated at offset %jd.", sc->sc_name, (intmax_t)corsize, (intmax_t)coroff); coroff = -1; @@ -221,7 +221,7 @@ } /* Report previous corruption if there was one. */ if (coroff != -1) { - G_ELI_DEBUG(0, "%s: %jd bytes corrupted at offset %jd.", + G_ELI_DEBUG(0, "%s: %jd bytes not authenticated at offset %jd.", sc->sc_name, (intmax_t)corsize, (intmax_t)coroff); } } >Release-Note: >Audit-Trail: >Unformatted: