[dm-crypt] ing rootfs without initramfs

[dm-crypt] ing rootfs without initramfs

[ebelcrom ebelcrom]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

Hello folks,

I played around with dm-crypt without using initramfs for en-/decryption of
my root file system. The rootfs is encrypted plain with cryptsetup and the
key is stored at the disk containing the rootfs between MBR and the
partition. The kernel parameter given to it from the bootloader is
configured as it should be (cryptdevice, cryptkey, root mapper). The disk
driver (loaded before) is built-in as well as dm-crypt (loaded after). The
message I got at boot time is this (cr_rootfs is the encrypted rootfs):

VFS: Cannot open root device "mapper/cr_rootfs" or unknown-block(0,0)

According to some hints in the web there is no need to have an initramfs.
Is that true? If yes what are the steps to get there and what should I keep
into account?

Any suggestions are welcome!

[-- Attachment #2: Type: text/html, Size: 895 bytes --]

Re: [dm-crypt] ing rootfs without initramfs

[Milan Broz]

On 07/20/2013 09:36 PM, ebelcrom ebelcrom wrote:

> I played around with dm-crypt without using initramfs for
> en-/decryption of my root file system. The rootfs is encrypted plain
> with cryptsetup and the key is stored at the disk containing the
> rootfs between MBR and the partition. The kernel parameter given to
> it from the bootloader is configured as it should be (cryptdevice,
> cryptkey, root mapper). The disk driver (loaded before) is built-in
> as well as dm-crypt (loaded after). The message I got at boot time is
> this (cr_rootfs is the encrypted rootfs):
> 
> VFS: Cannot open root device "mapper/cr_rootfs" or
> unknown-block(0,0)
> 
> According to some hints in the web there is no need to have an
> initramfs. Is that true? If yes what are the steps to get there and
> what should I keep into account?

I think the only possibility is to use GRUB2 which should understand
LUKS directly and boot from it. (Not sure about plain dmcrypt device).

I do not think you can create device-mapper block device without
initramfs (there were some patches to add some kernel options
but IIRC it never reached upstream).

Milan

Re: [dm-crypt] ing rootfs without initramfs

[Bryan Kadzban]

Milan Broz wrote:
> On 07/20/2013 09:36 PM, ebelcrom ebelcrom wrote:
> 
>> I played around with dm-crypt without using initramfs for 
>> en-/decryption of my root file system. The rootfs is encrypted
>> plain with cryptsetup and the key is stored at the disk containing
>> the rootfs between MBR and the partition. The kernel parameter
>> given to it from the bootloader is configured as it should be
>> (cryptdevice, cryptkey, root mapper). The disk driver (loaded
>> before) is built-in as well as dm-crypt (loaded after). The message
>> I got at boot time is this (cr_rootfs is the encrypted rootfs):
>> 
>> VFS: Cannot open root device "mapper/cr_rootfs" or 
>> unknown-block(0,0)
>> 
>> According to some hints in the web there is no need to have an 
>> initramfs. Is that true? If yes what are the steps to get there and
>> what should I keep into account?
> 
> I think the only possibility is to use GRUB2 which should understand 
> LUKS directly and boot from it. (Not sure about plain dmcrypt
> device).

So I've never tried it myself (I'm using a pretty simple initramfs I
wrote in shell for my luks-rootfs setup), but I'm not sure how this can
work.

Because no bootloader mounts the rootfs.  They only find the kernel code
(and, if configured, the initramfs image), load it (or them) into
memory, and jump to the kernel's init code, transferring control of the
machine to the kernel.  (There's a protocol to tell the kernel about the
initramfs if one is present.)

The kernel either runs the initramfs's /init program, or mounts the
rootfs itself and runs /sbin/init.  (Or whatever you set init= to on the
kernel command line.)

(Plus there's the fact that the kernel can't automount luks.)

Re: [dm-crypt] ing rootfs without initramfs

[Milan Broz]

On 21.7.2013 7:40, Bryan Kadzban wrote:
> Milan Broz wrote:
>> On 07/20/2013 09:36 PM, ebelcrom ebelcrom wrote:
>>
>>> I played around with dm-crypt without using initramfs for
>>> en-/decryption of my root file system. The rootfs is encrypted
>>> plain with cryptsetup and the key is stored at the disk containing
>>> the rootfs between MBR and the partition. The kernel parameter
>>> given to it from the bootloader is configured as it should be
>>> (cryptdevice, cryptkey, root mapper). The disk driver (loaded
>>> before) is built-in as well as dm-crypt (loaded after). The message
>>> I got at boot time is this (cr_rootfs is the encrypted rootfs):
>>>
>>> VFS: Cannot open root device "mapper/cr_rootfs" or
>>> unknown-block(0,0)
>>>
>>> According to some hints in the web there is no need to have an
>>> initramfs. Is that true? If yes what are the steps to get there and
>>> what should I keep into account?
>>
>> I think the only possibility is to use GRUB2 which should understand
>> LUKS directly and boot from it. (Not sure about plain dmcrypt
>> device).
>
> So I've never tried it myself (I'm using a pretty simple initramfs I
> wrote in shell for my luks-rootfs setup), but I'm not sure how this can
> work.
>
> Because no bootloader mounts the rootfs.  They only find the kernel code
> (and, if configured, the initramfs image), load it (or them) into
> memory, and jump to the kernel's init code, transferring control of the
> machine to the kernel.  (There's a protocol to tell the kernel about the
> initramfs if one is present.)
>
> The kernel either runs the initramfs's /init program, or mounts the
> rootfs itself and runs /sbin/init.  (Or whatever you set init= to on the
> kernel command line.)
>
> (Plus there's the fact that the kernel can't automount luks.)

Yes, GRUB2 solve just initial kernel boot load, you cannot map any device-mapper
device (that's include crypt but also LVM etc) without userspace tools...

Seems I anwered different question, sorry :)

Anyway, there were tries to add kernel boot parameters for DM
e.g. http://article.gmane.org/gmane.linux.kernel/988034

But this wil not work for LUKS either without in-kernel LUKS implementation.
And for plain crypt you have to provide key on kernel line (quite insecure).

I think using some initramfs is the only solution now for mapping
encrypted root fs (for now).

Milan

Re: [dm-crypt] ing rootfs without initramfs

[Thomas Bächler]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

Am 21.07.2013 10:47, schrieb Milan Broz:
> I think using some initramfs is the only solution now for mapping
> encrypted root fs (for now).

I would remove "for now" from your statement. Unlocking the volume from
kernel code itself requires that the kernel learns how to ask for
passphrases and/or find key files, do LUKS header processing and accept
device-mapper parameters in some way.

This is very complicated to do in kernel code and adds tons of kernel
code for tasks that do not belong into the kernel. Such patches will
never be accepted upstream, since there is a more flexible and less
error-prone mechanism to solve the problem (it's called "initramfs", if
you didn't guess it already).



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [dm-crypt] ing rootfs without initramfs

[Milan Broz]

On 07/21/2013 11:01 AM, Thomas Bächler wrote:
> Am 21.07.2013 10:47, schrieb Milan Broz:
>> I think using some initramfs is the only solution now for mapping
>> encrypted root fs (for now).
> 
> I would remove "for now" from your statement. Unlocking the volume from
> kernel code itself requires that the kernel learns how to ask for
> passphrases and/or find key files, do LUKS header processing and accept
> device-mapper parameters in some way.
> 
> This is very complicated to do in kernel code and adds tons of kernel
> code for tasks that do not belong into the kernel. Such patches will
> never be accepted upstream, since there is a more flexible and less
> error-prone mechanism to solve the problem (it's called "initramfs", if
> you didn't guess it already).

Never say never :)

Imagine you have system which stores keys in something like TPM and
you have "trusted" boot path. I can see that dm-crypt
itself receives key from such hw through kernel keyring directly and
we do not need much userspace interaction.
Basically it needs just some keyid on kernel command line (plus
more metadata info similar to patch I referenced).

That said I almost completely agree with your statement. And LUKS
parsing is completely userspace thing.

Milan

Re: [dm-crypt] ing rootfs without initramfs

[Will Drewry]

On Sun, Jul 21, 2013 at 3:47 AM, Milan Broz <gmazyland@gmail.com> wrote:
> On 21.7.2013 7:40, Bryan Kadzban wrote:
>>
>> Milan Broz wrote:
>>>
>>> On 07/20/2013 09:36 PM, ebelcrom ebelcrom wrote:
>>>
>>>> I played around with dm-crypt without using initramfs for
>>>> en-/decryption of my root file system. The rootfs is encrypted
>>>> plain with cryptsetup and the key is stored at the disk containing
>>>> the rootfs between MBR and the partition. The kernel parameter
>>>> given to it from the bootloader is configured as it should be
>>>> (cryptdevice, cryptkey, root mapper). The disk driver (loaded
>>>> before) is built-in as well as dm-crypt (loaded after). The message
>>>> I got at boot time is this (cr_rootfs is the encrypted rootfs):
>>>>
>>>> VFS: Cannot open root device "mapper/cr_rootfs" or
>>>> unknown-block(0,0)
>>>>
>>>> According to some hints in the web there is no need to have an
>>>> initramfs. Is that true? If yes what are the steps to get there and
>>>> what should I keep into account?
>>>
>>>
>>> I think the only possibility is to use GRUB2 which should understand
>>> LUKS directly and boot from it. (Not sure about plain dmcrypt
>>> device).
>>
>>
>> So I've never tried it myself (I'm using a pretty simple initramfs I
>> wrote in shell for my luks-rootfs setup), but I'm not sure how this can
>> work.
>>
>> Because no bootloader mounts the rootfs.  They only find the kernel code
>> (and, if configured, the initramfs image), load it (or them) into
>> memory, and jump to the kernel's init code, transferring control of the
>> machine to the kernel.  (There's a protocol to tell the kernel about the
>> initramfs if one is present.)
>>
>> The kernel either runs the initramfs's /init program, or mounts the
>> rootfs itself and runs /sbin/init.  (Or whatever you set init= to on the
>> kernel command line.)
>>
>> (Plus there's the fact that the kernel can't automount luks.)
>
>
> Yes, GRUB2 solve just initial kernel boot load, you cannot map any
> device-mapper
> device (that's include crypt but also LVM etc) without userspace tools...
>
> Seems I anwered different question, sorry :)
>
> Anyway, there were tries to add kernel boot parameters for DM
> e.g. http://article.gmane.org/gmane.linux.kernel/988034

FWIW, I'll try to add these again soon and see how it goes!  They
weren't outright rejected :)