Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cryptsetup 2.1 switches to LUKS2 by default #1099

Open
philmmanjaro opened this issue Feb 24, 2019 · 16 comments

Comments

Projects
None yet
5 participants
@philmmanjaro
Copy link
Member

commented Feb 24, 2019

Describe the bug
Currently you will hit issues when cryptsetup 2.1 is not set to use luks1 still as default. grub and other bootloaders still relay on luks1 for now.

To Reproduce
Steps to reproduce the behavior:

  1. Use an install media like Manjaro 18.0.3 and try to install with encryption
  2. You will land in a rescue shell as grub don't support luks2 for /boot

Expected behavior
When cryptsetup 2.1 is detected, we have to use --type luks1 to explicitly use luks1 for /boot encryption until grub might adopt luks2 support.

Screenshots and Logs

fd74a7a1c8174229b3758e9f2b72ed1f3b59d294_2_690x335

Additional context
See also release notes from cryptsetup.

@kkofler

This comment has been minimized.

Copy link
Contributor

commented Feb 24, 2019

@kkofler

This comment has been minimized.

Copy link
Contributor

commented Feb 24, 2019

I think Calamares should implement your proposed workaround for now.

@abucodonosor

This comment has been minimized.

Copy link
Contributor

commented Feb 24, 2019

@kkofler I don't think so :-)

If you don't have grub2 with luks2 support in your Distribution then you should
build luks in your distribution with:

--with-default-luks-format=LUKS1

@philmmanjaro

This comment has been minimized.

Copy link
Member Author

commented Feb 24, 2019

@abucodonosor: well, that is the wrong approach. We should make it possible to support luks2 for sure, however none of the key parts support that format yet. Especially grub. So CAL might be configurable and should default to luks1 for now. We can make this adjustable via config file. Just compiling cryptsetup for defaulting to luks1 might make sense, but if a distro is defaulting to luks2 we still have a problem when grub is chosen as the bootloader.

@abucodonosor

This comment has been minimized.

Copy link
Contributor

commented Feb 24, 2019

@philmmanjaro

Yes but your bug is in packaging logic.

If you push luks with luks2 default but grub2 with luks1 default
you break on distro level already and nothing in calamares will fix that
except to workaround your installation problem.

If any of your user decide to do some kind luks setup after that all will break down
on these disks.

Quoting luks folks:

The legacy LUKS (referenced as LUKS1) will be fully supported forever
as well as a traditional and fully backward compatible format.

When upgrading a stable distribution, please use configure option
--with-default-luks-format=LUKS1 to maintain backward compatibility.

So CAL might be configurable and should default to luks1 for now. We can make this adjustable via config file.

I agree with that part we can add a luksX option in some config file until grub2
and other parts fully support luks2 key formats.

Beacuse is not only about grub2 here , but about systend generators , initramfs hooks of any sort,
dracut and probably some more.

but if a distro is defaulting to luks2 we still have a problem when grub is chosen as the bootloader.

You mean with patched grub2 for luks2 key formats() ? ..

Well we need , if we add luks2 key format(s) support to make it clear is:

  1. Experimental until official support for these gets added
  2. May break bc we cannot guess what Distributions may or may not patch.

and emit a 'big warning' when used.

@philmmanjaro

This comment has been minimized.

Copy link
Member Author

commented Feb 24, 2019

@abucodonosor: grub doesn't support luks2 yet. Other software might either. However, on Arch they use cryptsetup with luks2 as default. I compiled now a version defaulting to luks1 on Manjaro. I only want to have CAL configurable and default to luks1 to avoid issues until upstream managed to get all compatible. That's all.

@kkofler

This comment has been minimized.

Copy link
Contributor

commented Feb 24, 2019

Fedora 30 will default to LUKS 2 in cryptsetup: https://fedoraproject.org/wiki/Changes/SwitchCryptsetupDefaultToLUKS2
GRUB support for LUKS 2 will almost certainly not be there. Fedora does not care about GRUB support for LUKS because Anaconda does not use it, it sets up an unencrypted /boot instead.

@abucodonosor

This comment has been minimized.

Copy link
Contributor

commented Feb 25, 2019

Uff and the point of having luks being then ?:) 'put your initrd into unencrypted /boot while you store your key there ' ? hmm ?

@kkofler

This comment has been minimized.

Copy link
Contributor

commented Feb 25, 2019

Anaconda doesn't use keyfiles, you get prompted for the passphrase by Dracut rather than GRUB. (As I explained on IRC, this is what Calamares should also do if you do manual partitioning with unencrypted /boot and encrypted /. Currently, luksbootkeyfile runs in that case too, which is very broken and insecure.)

@tsimonq2

This comment has been minimized.

Copy link
Contributor

commented Apr 8, 2019

Actually, this can easily be solved by cherry-picking the first part of this patch. It isn't in a non-beta tagged version yet, which explains why everyone's having the issue.

As it turns out, Calamares doesn't actually define LUKS2-specific partitions. It creates a partition with the Filesystem::LUKS type, which is LUKS, not LUKS2. If we wanted to do LUKS2 by default, we could certainly do that, but I would very strongly urge the maintainers to wait until both GRUB is fixed and kpmcore is tagged. The current kpmcore version, when it creates a partition with the Filesystem::LUKS type, just uses the cryptsetup default. Cherry-pick the patch, and voila.

@kkofler @philmmanjaro

@tsimonq2

This comment has been minimized.

Copy link
Contributor

commented Apr 8, 2019

To clarify, @abucodonosor, the workaround that you ruled out has already been implemented for two years now. ;)

@abucodonosor

This comment has been minimized.

Copy link
Contributor

commented Apr 8, 2019

@tsimonq2

please avoid to highlight or CC'ing me.

But lets clarify..

  1. I don't talk about workarounds.
  2. Yes this switch exists a while but you are missing the point.
  3. No you cannot just cherry-pick that commit , we have to force LUKS1 like
    suggested for now.
  4. LUKS2 need much more code , probably an new module
    with support for the grub* , all iniramfs/rd modules etc and at
    the same time these modules need keep
    backwards compatibility with LUKS1.
    So no it cannot be easy solved like you think it may.

Thx

@tsimonq2

This comment has been minimized.

Copy link
Contributor

commented Apr 8, 2019

I did just cherry-pick the commit (well, pulled it downstream from Debian, thanks @highvoltage!)

You're misunderstanding what I have stated; in Calamares, when kpmcore is called, it creates filesystems with the type Filesystem::Luks and not Filesystem::Luks2. The only reason why cryptsetup updating in the first place broke this is because without the patch, which has now been cherry-picked, Filesystem::Luks is basically equivalent to Filesystem::Luks2. It's a kpmcore problem, not a Calamares one.

Easily solved. Just don't switch the kpmcore calls to LUKS2 until we have everything sorted.

Issue closed.

@highvoltage

This comment has been minimized.

Copy link
Contributor

commented Apr 9, 2019

In debian I patched kpmcore to specify --luks1 when configuring the encryption containers. I believe the correct place to fix this is in kpmcore, not calamares. kpmcore should have an option to specify whether you want to configure luks1 or luks2, then you can have that as an option in calamares.

@abucodonosor

This comment has been minimized.

Copy link
Contributor

commented Apr 9, 2019

@highvoltage

no , In both not only kpmcore or calamares.

While is fine kpmcore to have a API for both , calamares need implement
LUKS1 && LUKS2 in his modules and options for the Distros.

Is not only about force LUKS1 or LUKS2 because that won't work with the code
exists now in calamares. ( OK LUKS1 ofc does but LUKS2 ).

Also kpmcore is not the right place to force what calamares may need.
Calamares itself need be in control based on configuration options.

@highvoltage

This comment has been minimized.

Copy link
Contributor

commented Apr 9, 2019

@highvoltage

no , In both not only kpmcore or calamares.

While is fine kpmcore to have a API for both , calamares need implement
LUKS1 && LUKS2 in his modules and options for the Distros.

Is not only about force LUKS1 or LUKS2 because that won't work with the code
exists now in calamares. ( OK LUKS1 ofc does but LUKS2 ).

Also kpmcore is not the right place to force what calamares may need.
Calamares itself need be in control based on configuration options.

@abucodonosor I think you may have misunderstood me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.