RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1030288 - Trying to read keyslot 7 from external header file fails with error device too small
Summary: Trying to read keyslot 7 from external header file fails with error device to...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: cryptsetup
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Ondrej Kozina
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks: 1029406
TreeView+ depends on / blocked
 
Reported: 2013-11-14 09:54 UTC by Ondrej Kozina
Modified: 2023-03-08 07:26 UTC (History)
6 users (show)

Fixed In Version: cryptsetup-1.6.3-1.el7
Doc Type: Known Issue
Doc Text:
The cryptsetup library does not align the backup header stored in the regular file to the system page size (4KiB). When trying to load the last (7) keyslot from the backup header, the internal check in the library for the correct header fails. As a consequence, if keyslot 7 is active, running the following command fails: cryptsetup luksOpen --header /path/to/hdr_file -S 7 /dev/device To work around this problem, disabling keyslot 7 is the simplest solution. If disabling keyslot 7 is not a viable option, create a loop device over such a header file by running the following command: losetup -f /path/to/hdr_file. Then, pass the newly created loop device to the --header option in the cryptsetup luksOpen command. In addition, running the following command fails: cryptsetup-reencrypt /dev/device To work around this problem, disable keyslot 7. Note: Before you disable keyslot 7, make sure that there is at least one remaining active keyslot that you know password for. Otherwise, the LUKS device becomes unusable.
Clone Of:
Environment:
Last Closed: 2014-06-13 10:44:10 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Ondrej Kozina 2013-11-14 09:54:57 UTC 
Description of problem:

Cryptsetup-reencrypt utility can't reencrypt device with last keyslot being active.


Version-Release number of selected component (if applicable):
cryptsetup-1.6.2-2.el7 (even upstream 1.6.2)


How reproducible: always


Steps to Reproduce: 
1. fallocate -l $[8*1024*1024] /tmp/test_file
2. losetup -f /tmp/test_file
3. echo aaa | cryptsetup --force-password luksFormat -S 7 /dev/loop0
4. cryptsetup-reencrypt /dev/loop0

Actual results:

reencrypt fails with retval 1 and message about /dev/loopX (temporary helper device) being too small.


Expected results:

device is reencrypted
Comment 2 Ondrej Kozina 2013-11-14 14:07:47 UTC 
backtrace:

#0  LUKS_endec_template (src=0x6108e8 "", srcLength=128000, cipher=0x60f518 "aes", cipher_mode=0x60f538 "xts-plain64", vk=0x610510, 
    sector=1800, func=0x7ffff7bbdd88 <read_blockwise>, mode=0, ctx=0x60f4d0) at keyencryption.c:81
#1  0x00007ffff7bcac11 in LUKS_decrypt_from_storage (dst=0x6108e8 "", dstLength=128000, cipher=0x60f518 "aes", 
    cipher_mode=0x60f538 "xts-plain64", vk=0x610510, sector=1800, ctx=0x60f4d0) at keyencryption.c:139
#2  0x00007ffff7bc9e5b in LUKS_open_key (keyIndex=7, password=0x6106c8 "aaa", passwordLen=3, hdr=0x60f510, vk=0x60f460, ctx=0x60f4d0)
    at keymanage.c:923
#3  0x00007ffff7bc9fd8 in LUKS_open_key_with_hdr (keyIndex=-1, password=0x6106c8 "aaa", passwordLen=3, hdr=0x60f510, 
    vk=0x7fffffff9060, ctx=0x60f4d0) at keymanage.c:963
#4  0x00007ffff7bbb982 in crypt_activate_by_passphrase (cd=0x60f4d0, 
    name=0x7fffffff9108 "LUKS-a98c8ec3-9d98-4b1b-97db-b9a267da2a8f.org", keyslot=-1, passphrase=0x6106c8 "aaa", passphrase_size=3, 
    flags=17) at setup.c:1933
#5  0x0000000000404cb9 in activate_luks_headers (rc=0x7fffffff90d0) at cryptsetup_reencrypt.c:394
#6  0x00000000004070d9 in run_reencrypt (device=0x7fffffffe5f4 "/dev/loop1") at cryptsetup_reencrypt.c:1083
#7  0x00000000004077b6 in main (argc=2, argv=0x7fffffffe328) at cryptsetup_reencrypt.c:1237

failing function is:

lib/luk1/keyencryption.c:79 r = device_block_adjust(ctx, dmd.data_device, DEV_OK,
                                dmd.u.crypt.offset, &dmd.size, &dmd.flags);
Comment 3 Ondrej Kozina 2013-11-14 15:51:32 UTC 
Seems to me like a rounding or alignment issue:

1) in LUKS_hdr_backup() I get necessary header size 2050 sectors (512 B)

2) in LUKS_endec_template() I get necessary header size 2056 sectors (512 B)

In 1) we get alignment from block device (512B sectors)
In 2) we get alignment from regular file, alignement is page_size
Comment 4 Ondrej Kozina 2013-11-18 18:18:16 UTC 
just for the record (it's obvious): it also affects cryptsetup (and library) when trying to load key from external header file. But the bug doesn't trigger when you try to use the backup header from another block device. (even when I dd-ed header from file to block device of same size).

So the header is fine, keyslot materials are fine, it's just failing alignment expectation:

creating header backup from block device with sector size = 512B and trying to read header from file where sector size is replaced implicitly by page size (4K).
Comment 5 Ondrej Kozina 2013-11-22 09:22:43 UTC 
Got fix in upstream. Next build will include the fix:

http://code.google.com/p/cryptsetup/source/detail?r=f30bbbffe75b8d561c202839d26fe40be06d09b6
Comment 8 Ludek Smid 2014-06-13 10:44:10 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.
Note You need to log in before you can comment on or make changes to this bug.