From: "Schneider, Robert" <robert.schneider03@sap.com>
To: Ondrej Kozina <okozina@redhat.com>,
"dm-crypt@saout.de" <dm-crypt@saout.de>
Cc: Milan Broz <gmazyland@gmail.com>
Subject: [dm-crypt] Re: Transactional updates for LUKS2 metadata?
Date: Thu, 22 Apr 2021 07:00:17 +0000 [thread overview]
Message-ID: <AM0PR02MB5585C40B28002DACC33801488F469@AM0PR02MB5585.eurprd02.prod.outlook.com> (raw)
In-Reply-To: <8b72fbe2-1197-149e-b59d-7f10e2b6b8e3@redhat.com>
> Did I understand your use case correctly?
Yes! Thank you very much for this proposal :)
It's much better than the two-token system I'm currently using.
Still, I wonder if it's possible to get this entirely inside libcryptsetup: It can do multiple changes to metadata internally, but doesn't expose this in the API.
There might be a relatively simple way to expose transactions: It should be possible to implement an atomic header restore if enough space is available in the keyslots binary area of the target of the restore.
1. Lock the target.
2. Iterate over the metadata in the backup/source header. For each allocation in the keyslots binary area in the backup header, perform an equally-sized allocation in the target header. This can fail if not enough space is available in the target header (for both its current allocations and the allocations from the backup header).
3. Adjust the backup header json metadata in memory to refer to the new allocations in the target header.
4. Copy the contents of the backup header keyslots binary area to the new allocations in the target header. Assuming some form of atomic writes (e.g. sector-size writes), this should be safe since we don't modify the content of the existing allocations in the target header keyslots binary area. At most, we're overwriting them with the same content.
5. Sync.
6. Overwrite primary header + json in the target.
7. Sync.
8. Optional: wipe the old allocations in the target binary keyslots area.
9. Optional: Sync.
10. Overwrite secondary header + json in the target.
11. Sync
What worries me a bit is that you can fail between 7 and 11 and leave some of the old binary keyslots unwiped. This wouldn't be a concern if a repair operation that restores the second header from the first wipes the unused binary keyslots.
There is potential for optimization of 2 and 3: diff the binary areas and only work on the difference. Additionally, if you create the backup header by doing all the keyslot additions first, and then remove other keyslots, the diff between backup and target will be disjunct, and restore won't fail due to size constraints.
What do you think?
Thanks again,
Robert
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de
prev parent reply other threads:[~2021-04-22 7:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-09 18:46 [dm-crypt] Transactional updates for LUKS2 metadata? Schneider, Robert
2021-04-10 19:27 ` [dm-crypt] " Milan Broz
2021-04-11 12:09 ` Schneider, Robert
2021-04-20 8:43 ` Ondrej Kozina
2021-04-22 7:00 ` Schneider, Robert [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AM0PR02MB5585C40B28002DACC33801488F469@AM0PR02MB5585.eurprd02.prod.outlook.com \
--to=robert.schneider03@sap.com \
--cc=dm-crypt@saout.de \
--cc=gmazyland@gmail.com \
--cc=okozina@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).