On Tue, Apr 20, 2021 at 05:23:49PM +0800, Kairui Song wrote:
Thanks a lot, these info are very helpful.
Better to keep it for debugging for now, and ask users to use it very carefully.
On Tue, Apr 20, 2021 at 3:54 PM Milan Broz <gmazyland(a)gmail.com> wrote:
> TL;DR what you are trying to do is to actually reverse many security measures
> we added. It is perhaps acceptable for debugging but hardly for real generic system.
> - using memory-hard function increases cost of dictionary and brute-force
> You can always decrease amount of memory needed, but you should do it only
> if you know that security margin is ok (like password is randomly generated
> with enough entropy).
> - key is in keyring to remove possibility for normal userspace to receive
> the key from kernel. Moreover, there is no need to retain kernel in keyring once
> dm-crypt device is activated. (It is still in kernel memory but only in crypto
> functions context). (Systemd also uses keyring to cache passphrase but that's
> different thing.)
> You can still use old way for activation with --disable-keyring activation,
> but then you disable this possibility.
> More comments below.
How about plan 3 and 4?
Have you got any reply from Milan about his input on plan 3 and 4? If
so, can you forward his email(s) to me? Thanks!
> 3. Let kdump use some custom helper/service to load all needed
> resources in the early initrd boot stage, prior to
> systemd-cryptsetup(a)%s.service. It will ask the password / parse the
> keyfile and load kdump, then provide info for systemd-cryptsetup or
> just do the setup. Or maybe let systemd-cryptsetup support some kind
> of "plugins" so other tools can use it.
Some details could be changed/improved, but
systemd-cryptsetup(a)%s.service will prompt for a password or use a
So I think at this point, loading kdump with the volume key should be
safe? At least long as the kdump kernel/environment itself isn't
compromised. Loaded kdump resources can be restricted to be only
accessible from the kernel side.
After panic, kernel kexec jumps to kdump kernel, and that's an
minimized emergency environment that only lives for a very short
> 4. A better and safer solution seems to keep a consistent key ring
> between kexec boots but also more complex and difficult as different
> arch implements kexec differently.
Maybe plan 4 will be a good idea if doable? Since that keeps the key
consistent in the kernel between kexec boots, and cryptsetup can just