Re: [gentoo-user] cryptsetup wont use aes-xts:plain64

[Ralf <ralf+gentoo@ramses-pyramidenbau.de>]

Hi,

@Marko
tl;dr: it's going a bit offtopic.
Marko, try to hardcompile those modules into your kernel.
This should be the simplest fix of your problem.

On 04/18/2015 02:44 PM, Heiko Baums wrote:
> Am 18.04.2015 um 14:12 schrieb Ralf:
>
>> No. Could you please explain why you think so?
>> Even if your root partition is encrypted, your ramdisk could load the
>> modules.
> Are you sure about that? Are you sure that the necessary modules are
> definitely put into the initrd and that the kernel will be able to load
> them soon enough at boot time?
I double checked it and now I am sure:

For reasons of comfortability I inspected a standard Arch-Linux
installation.
It supports rootfs encryption and xts is loaded in the initrd as module.
So it is possible to treat it as a module.

Besides that: Why should your kernel config allow you to compile it as
module if it isn't useable as module?
>
> Compiling those modules into the kernel is definitely more secure (in
> terms of being sure that they are always available) and doesn't do any
> harm, because they need to be loaded anyway.
Yes for a homebrew kernel, i can second that.
>
> Btw., several dm-crypt/LUKS documentation (all that I've read) say that
> those modules have to be compiled into the kernel directly.
>
>> After loading the modules you can see that they are available by cat
>> /proc/crypto.
> You won't be able to run this command when the kernel tries to unlock
> the LUKS container at boot time.
No, but it is accessible when creating your LUKS volume, and that's
Marko problem at the moment.
>
>> The modules can be loaded _after_ bootup as well.
> If you want to unlock the LUKS container at boot time (particularly if
> your root partition is encrypted), loading the modules after bootup is
> too late.
Loading those modules during the early bootup phase in your initrd is
actually not too late.

Ah, and for completeness sake:
Grub2 is able to speak LUKS. So your kernel and initrd maybe inside an
encrypted volume.

>
> So I wouldn't risk it.
Neither do I.

Cheers
  Ralf