[Bug 196834] geli setkey -P doesn't reset md_iterations

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196834

            Bug ID: 196834
           Summary: geli setkey -P doesn't reset md_iterations
           Product: Base System
           Version: 10.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: bin
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: madoka at nyanisore.net

Overview:

When removing passphrase from a geli device with both passphrase and keyfile,
the iteration counter, md_iterations, isn't reset to the default value of -1.

Steps to Reproduce:

# geli init -b -B none -e AES-XTS -K /boot/encryption.key -l 128 -s 4096 ada1
Enter new passphrase:
Reenter new passphrase:
# geli dump ada1 | grep iterations
iterations: 534226
# geli setkey -k /boot/encryption.key -K /boot/encryption.key -P ada1
Enter passphrase:
Note, that the master key encrypted with old keys and/or passphrase may still
exists in a metadata backup file.
# geli dump ada1 | grep iterations
iterations: 534226

Expected Results:

iterations: -1

Additional Information:

The stale md_iterations isn't a problem when manipulating the geli device from
the command line, because it's effectively ignored with -p.  However, some
code, such as g_eli_taste(), checks md_iterations == -1 to determine whether a
passphrase is set or not.  Thus, even after removing the passphrase, it'll
still prompt for one.  I ran into that problem here:
<http://article.gmane.org/gmane.os.freebsd.questions/311256>.

I was able to work around the problem:

# geli setkey -i $(echo '2^32-1' | bc) -k /boot/encryption.key -K
/boot/encryption.key -p -P ada1
Note, that the master key encrypted with old keys and/or passphrase may still
exists in a metadata backup file.
# geli dump ada1 | grep iterations
iterations: 4294967295

Note that "geli setkey -i -1" won't work.  Also note that while md_iterations
is a int32_t, eli_metadata_dump() casts it to a u_int.  There are some other
minor quirks with eli_metadata_dump(); should I file another PR or just tack it
on to this one?

-- 
You are receiving this mail because:
You are the assignee for the bug.