Excellent news for ram-wipe!
dracut-ng will properly close a full disk encrypted root disk. This should allow ram-wipe to wipe the full disk encryption key from RAM during it’s first pass using sd-mem at shutdown and not only during its second pass during after kexec.
opened 03:46PM - 19 Apr 24 UTC
closed 09:24PM - 25 May 24 UTC
bug
add a shutdown hook to close encrypted devices and wipe their encryption keys fr… om kernel memory.
Related work
- dracutdevs/dracut/issues/997
- dracutdevs/dracut#1888
- dracut-ng/dracut-ng/pull/94
CC @DanWin @adrelanos
dracut-ng:main ← kszczek:cryptsetup-close
opened 04:40PM - 19 May 24 UTC
This is an alternative implementation of https://github.com/dracutdevs/dracut/pu… ll/2471. Instead of using a separate module, let's do this in the `90dm` module, which already has a shutdown script used to remove device mappers. Using deferred removal seems a little hacky to me and I'm worried about race conditions that may arise between the deferring mechanism and the `90dm` module. Imagine this: you have a dm-crypt device and on top of that you have an LVM. If we schedule deferred removal of the dm-crypt device, it won't happen right away, because the LVM is still holding it. So we walk through all the shutdown scripts until we get to `90dm`. We use `dmsetup remove` to deactivate the LVM and now the dm-crypt no longer has any holders, so it's free to be removed. But there is a problem - the shutdown script will also attempt to remove the dm-crypt device using `dmsetup remove`, so that is where the race is, what will happen first? Will the deferred deactivation be performed first or will the shutdown script be able to reach `dmsetup remove` in time before that? I'm not an expert in the Linux kernel so I can't say how that works, but that's just a concern I have, which this PR resolves.
CC @DanWin @adrelanos
## Changes
- Add special case handling for dm-crypt mappers. When one is encountered, try to use `systemd-cryptsetup detach`, if not available try `cryptsetup close`, and finally fallback to `dmsetup remove` if neither is available.
- Add final attempt handling. If detaching a volume using `systemd-cryptsetup` or `cryptsetup` keeps failing, try detaching it using plain `dmsetup remove` on the final attempt.
## Checklist
- [x] I have tested it locally
- [ ] I have reviewed and updated any documentation if relevant
- [ ] I am providing new code and test(s) for it
Fixes #204
This fix will likely be available once Debian trixie has been released and Kicksecure ported to it.
2 Likes