Bug 1729768 - Anaconda can not make use of AEAD prepared LUKS partitions
Summary: Anaconda can not make use of AEAD prepared LUKS partitions
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: python-blivet
Version: 30
Hardware: All
OS: All
unspecified
low
Target Milestone: ---
Assignee: Vojtech Trefny
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1729888
TreeView+ depends on / blocked
 
Reported: 2019-07-14 11:57 UTC by Waffshappen
Modified: 2019-08-15 09:30 UTC (History)
11 users (show)

Fixed In Version: python-blivet-3.1.5-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1729888 (view as bug list)
Environment:
Last Closed: 2019-08-15 09:30:08 UTC


Attachments (Terms of Use)

Description Waffshappen 2019-07-14 11:57:31 UTC
Description of problem:
The anaconda storage selection offers to unlock AEAD luks partitions, but after that step just fails to do anything with them and just shows them as not editable or manageable. Even blivet-gui fails to make use of them.

This also affects rawhide.


Version-Release number of selected component (if applicable):


How reproducible:
Always.

Steps to Reproduce:
1. Prepare a drive for installation with /boot partition, and another you manually setup as whatever.
2. The second partition should be formatted with:
cryptsetup luksFormat --type luks2 --key-size 256 --sector-size 4096 --cipher chacha20-random --integrity poly1305 --pbkdf argon2id --hash sha512 --pbkdf-memory 16384 --pbkdf-parallel 4 --verify-passphrase --iter-time 5000 /dev/sdX
OR
cryptsetup luksFormat --type luks2 --key-size 256 --sector-size 4096 --cipher xchacha20,aes-adiantum-plain64 --integrity hmac-sha512 --pbkdf argon2id --hash sha512 --pbkdf-memory 16384 --pbkdf-parallel 4 --verify-passphrase --iter-time 5000 /dev/sdX
3. Unlock the luks container in anaconda trying to use it as / for the install. Observe it fail do to so.

Actual results:
Anaconda should be able to handle dm-integrity using luks2 containers.

Expected results:
Anaconda cannot make use of the container.

Additional info:

Comment 1 Vojtech Trefny 2019-07-24 13:37:24 UTC
upstream PR: https://github.com/storaged-project/blivet/pull/786

Comment 2 Waffshappen 2019-08-01 09:56:06 UTC
(In reply to Vojtech Trefny from comment #1)
> upstream PR: https://github.com/storaged-project/blivet/pull/786

Just as a forewarning, this will propably also affect integritysetup-created partitions:
https://gitlab.com/cryptsetup/cryptsetup/wikis/DMIntegrity#configuration-using-integritysetup
(Just the integrity, sans the crypto)
Once released, i dont know if they'll use the same identifier.


Also, is the bug still active for anaconda? Not sure if this also needs changes on any other layers of storaged to work with the non-blivet manual partitioning or other software relying on it like cockpit.

Comment 3 Vojtech Trefny 2019-08-01 10:46:12 UTC
> Just as a forewarning, this will propably also affect integritysetup-created partitions

This should be ok, the problem here was with the "extra layer" added by the integrity DM device (we were expecting the unlocked device to be child of the partition). But I'll test this.

> Also, is the bug still active for anaconda?

No, the fix for blivet fixes the issue for anaconda custom partitioning too, no changes in the UI were needed -- both blivet-gui and anaconda custom partitioning use blivet for storage management.


Note You need to log in before you can comment on or make changes to this bug.