* [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)
@ 2014-09-21 22:50 vaskez
2014-09-22 5:41 ` Heiko Rosemann
2014-09-22 16:10 ` Sven Eschenberg
0 siblings, 2 replies; 10+ messages in thread
From: vaskez @ 2014-09-21 22:50 UTC (permalink / raw)
To: dm-crypt
Several times I have set up virtual machines to test the cryptsetup
software. I can create and remove the encrypted volumes just fine and
mount them, however whenever I am finished setting up my system and
reboot, my kernel panics, ends, then says that it cannot mount root fs
on unknown block (hd0,0). I am sure that it is not a misconfiguration
with the kernel, as I have built kernels for unencrypted systems and
they have booted fine. Some information:
The encrypted volumes are created with:
cryptsetup -y -v -c serpent-xts-plain -s 512 -h sha512 create dmname
device
Previous partition layouts was like such:
/dev/sda1 +b Linux 100M (/boot) (not encrypted)
/dev/sda2 Linux Swap / Solaris 2G (swap)
/dev/sda3 Linux 10G (root)
/dev/sda4 Extended
/dev/sda5 Linux 2G (/var)
/dev/sda6 Linux 6G (/home)
This last time the layout was like such:
/dev/sda1 +b Linux 100M (/boot) (not encrypted)
/dev/sda2 Linux LVM 2G (swap)
/dev/sda3 Linux LVM 10G (root)
/dev/sda4 Extended
/dev/sda5 Linux LVM 2G (/var)
/dev/sda6 Linux LVM 6G (/home)
The distribution I am using is Gentoo with a custom (to test at one
time) and modified i386_defconfig (every other time) kernel patched with
GRSecurity.
This last time installing cryptsetup I made sure to install packages in
a specific order, like installing cryptsetup before grub legacy and
still got the same error. I had set root (hd0,0) in grub command line
and setup (hd0) on the command line. At one time I had tested setup on
(hd0,0), still the same error. When issuing grub-install /dev/sda in
bash, it will say that df cannot read filesystems and that it cannot
read a device map file, so I had to install grub in grub command shell.
I install cryptsetup from portage with USE="-thin" emerge -avtq
cryptsetup. -thin does not install thin provisioning tools and the boost
sys utils which I assume are very big because they take very long to
install.
After installing cryptsetup, I configure /etc/crypttab (which does not
exist) as follows:
swap /dev/mapper/swap /dev/urandom
swap,cipher=serpent-xts-plain,size=512,hash=sha512
root /dev/mapper/swap none
root,cipher=serpent-xts-plain,size=512,hash=sha512
var /dev/mapper/swap none
var,cipher=serpent-xts-plain,size=512,hash=sha512
home /dev/mapper/swap none
home,cipher=serpent-xts-plain,size=512,hash=sha512
/etc/fstab looks like:
/dev/sda1 /boot ext2 noauto,noatime 0 2
/dev/mapper/swap none swap sw 0 0
/dev/mapper/root / ext4 defaults,relatime 0 1
/dev/mapper/var /var ext4 defaults,relatime 0 1
/dev/mapper/home /home ext4 defaults,relatime 0 0
/dev/cdrom /mnt/cdrom auto noauto,user 0 0
I append the output of dmsetup tables to /etc/dmtab as the file says to
do, and then configure /etc/conf.d/dmcrypt to the following lines:
target=swap
source='/dev/sda2'
key='/dev/urandom'
options='-c serpent-xts-plain -s 512 -h sha512'
target=root
source='/dev/sda3'
options='-c serpent-xts-plain -s 512 -h sha512'
target=var
source='/dev/sda5'
options='-c serpent-xts-plain -s 512 -h sha512'
target=home
source='/dev/sda6'
options='-c serpent-xts-plain -s 512 -h sha512'
I also add lvm and dmcrypt to the boot runlevel. Kernel parameters are
set as follows:
kernel /boot/kernel cryptdevice=/dev/sda3:root
crypto=sha512:serpent-xts-plain:512:0 root=/dev/mapper/root quiet
I have shifted and removed parts of these options in various ways
possibly 15 or more different ways and nothing has worked.
After all of this none of it works. I reboot and get a kernel panic, and
then it says: VFS: root fs cannot be mounted on unknown block (hd0,0).
And yes I have set LVM and DM_CRYPT options etc in the kernel.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)
2014-09-21 22:50 [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0) vaskez
@ 2014-09-22 5:41 ` Heiko Rosemann
2014-09-22 10:02 ` Arno Wagner
2014-09-22 16:10 ` Sven Eschenberg
1 sibling, 1 reply; 10+ messages in thread
From: Heiko Rosemann @ 2014-09-22 5:41 UTC (permalink / raw)
To: dm-crypt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/22/2014 12:50 AM, vaskez@airmail.cc wrote:
> Several times I have set up virtual machines to test the cryptsetup
> software. I can create and remove the encrypted volumes just fine
> and mount them, however whenever I am finished setting up my system
> and reboot, my kernel panics, ends, then says that it cannot mount
> root fs on unknown block (hd0,0). I am sure that it is not a
> misconfiguration with the kernel, as I have built kernels for
> unencrypted systems and they have booted fine. Some information:
You will need to setup an initramfs or modify the one provided with
the gentoo install to open your encrypted volumes (at least the root
volume). I do not remember how it is "supposed to be done" in gentoo,
but I do remember it's not as simple as installing software in the
right order.
A good starting point would be
http://wiki.gentoo.org/wiki/DM-Crypt_LUKS#Generating_an_initramfs -
and as this is really distro specific (or maybe systemd takes care of
it - I don't know, I won't be trying) it is really beyond the topic of
this list.
Good luck with your setup,
Heiko
- --
Mein PGP-Key zur Verifizierung: http://pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlQftpAACgkQ/Vb5NagElAWsdgCfZmOaFuUE/DQdEby9jzrBexuX
Bj4AoLuIcwtEKhaAByqGiHVYFI8qLpnY
=vkDn
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)
2014-09-22 5:41 ` Heiko Rosemann
@ 2014-09-22 10:02 ` Arno Wagner
2014-09-22 19:07 ` Sven Eschenberg
0 siblings, 1 reply; 10+ messages in thread
From: Arno Wagner @ 2014-09-22 10:02 UTC (permalink / raw)
To: dm-crypt
On Mon, Sep 22, 2014 at 07:41:39 CEST, Heiko Rosemann wrote:
> On 09/22/2014 12:50 AM, vaskez@airmail.cc wrote:
> > Several times I have set up virtual machines to test the cryptsetup
> > software. I can create and remove the encrypted volumes just fine
> > and mount them, however whenever I am finished setting up my system
> > and reboot, my kernel panics, ends, then says that it cannot mount
> > root fs on unknown block (hd0,0). I am sure that it is not a
> > misconfiguration with the kernel, as I have built kernels for
> > unencrypted systems and they have booted fine. Some information:
>
> You will need to setup an initramfs or modify the one provided with
> the gentoo install to open your encrypted volumes (at least the root
> volume). I do not remember how it is "supposed to be done" in gentoo,
> but I do remember it's not as simple as installing software in the
> right order.
The thing is that the kernel cannot open LUKS encrypted partitions
by itself. It needs user-space tools (cryptsetup) for that. That
means the system must be running and have a working root filesystem.
The initrd mechanism provides a temporary root filesystem for that
use.
As I do not like initrds on my systems (too much hassle changing
anything), I use a different approach: Non-encrypted root and
anything I consider security-critical on encrypted partition(s).
A common criticism of that set-up is that it allows an attacker
to change things on the root partition, but the same applies to
the initrd (and the kernel!) as well and hence the initrd approach
does not really offer better security. If you want to prevent that,
you have to use some variant of secure boot, for example placing
bootloader, kernel and initrd on an encrypted memory-stick with
keypad or the like. And you better verify the BIOS checksum as
well, although that may not be enough if somebody put a blue-pill
in there. Fortunately such attacks are expensive and come with a
high risk of detection, so unless you are a known terrorist or
crimnal master-mind, don't worry about these.
Second thing is that a running system is far easier to attack and
as soon as it is opened, disk-encryption does not offer any
protection anymore....
Arno
> A good starting point would be
> http://wiki.gentoo.org/wiki/DM-Crypt_LUKS#Generating_an_initramfs -
> and as this is really distro specific (or maybe systemd takes care of
> it - I don't know, I won't be trying) it is really beyond the topic of
> this list.
>
> Good luck with your setup,
> Heiko
> --
> Mein PGP-Key zur Verifizierung: http://pgp.mit.edu
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)
2014-09-21 22:50 [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0) vaskez
2014-09-22 5:41 ` Heiko Rosemann
@ 2014-09-22 16:10 ` Sven Eschenberg
2014-09-25 19:25 ` vaskez
1 sibling, 1 reply; 10+ messages in thread
From: Sven Eschenberg @ 2014-09-22 16:10 UTC (permalink / raw)
To: vaskez; +Cc: dm-crypt
First of your problems are very distributzion specific.
The kernel complains that it cannot find the block device that was passed
via root= parameter (without root= it will probably use the first hd block
device it sees as fallback).
On Mon, September 22, 2014 00:50, vaskez@airmail.cc wrote:
> Several times I have set up virtual machines to test the cryptsetup
> software. I can create and remove the encrypted volumes just fine and
> mount them, however whenever I am finished setting up my system and
> reboot, my kernel panics, ends, then says that it cannot mount root fs
> on unknown block (hd0,0). I am sure that it is not a misconfiguration
> with the kernel, as I have built kernels for unencrypted systems and
> they have booted fine. Some information:
>
> The encrypted volumes are created with:
> cryptsetup -y -v -c serpent-xts-plain -s 512 -h sha512 create dmname
> device
>
> Previous partition layouts was like such:
> /dev/sda1 +b Linux 100M (/boot) (not encrypted)
> /dev/sda2 Linux Swap / Solaris 2G (swap)
> /dev/sda3 Linux 10G (root)
> /dev/sda4 Extended
> /dev/sda5 Linux 2G (/var)
> /dev/sda6 Linux 6G (/home)
>
> This last time the layout was like such:
> /dev/sda1 +b Linux 100M (/boot) (not encrypted)
> /dev/sda2 Linux LVM 2G (swap)
> /dev/sda3 Linux LVM 10G (root)
> /dev/sda4 Extended
> /dev/sda5 Linux LVM 2G (/var)
> /dev/sda6 Linux LVM 6G (/home)
>
> The distribution I am using is Gentoo with a custom (to test at one
> time) and modified i386_defconfig (every other time) kernel patched with
> GRSecurity.
>
> This last time installing cryptsetup I made sure to install packages in
> a specific order, like installing cryptsetup before grub legacy and
> still got the same error. I had set root (hd0,0) in grub command line
> and setup (hd0) on the command line. At one time I had tested setup on
> (hd0,0), still the same error. When issuing grub-install /dev/sda in
> bash, it will say that df cannot read filesystems and that it cannot
> read a device map file, so I had to install grub in grub command shell.
Grub is its own thing, does the bootloader load the kernel from an
encrypted fs? grub legacy? grub 2?
>
> I install cryptsetup from portage with USE="-thin" emerge -avtq
> cryptsetup. -thin does not install thin provisioning tools and the boost
> sys utils which I assume are very big because they take very long to
> install.
cryptsetup does not have any thin use flag afaik, lvm2 is the one using
thin provisioning ...
>
> After installing cryptsetup, I configure /etc/crypttab (which does not
> exist) as follows:
> swap /dev/mapper/swap /dev/urandom
> swap,cipher=serpent-xts-plain,size=512,hash=sha512
> root /dev/mapper/swap none
> root,cipher=serpent-xts-plain,size=512,hash=sha512
> var /dev/mapper/swap none
> var,cipher=serpent-xts-plain,size=512,hash=sha512
> home /dev/mapper/swap none
> home,cipher=serpent-xts-plain,size=512,hash=sha512
Gentoo does not really use crypttab, does it? instead it will use dmcrypt
in conf.d (for SYSVinit), might use crypttab for systemd though.
>
> /etc/fstab looks like:
> /dev/sda1 /boot ext2 noauto,noatime 0 2
> /dev/mapper/swap none swap sw 0 0
> /dev/mapper/root / ext4 defaults,relatime 0 1
> /dev/mapper/var /var ext4 defaults,relatime 0 1
> /dev/mapper/home /home ext4 defaults,relatime 0 0
> /dev/cdrom /mnt/cdrom auto noauto,user 0 0
>
fstab does not really matter when the kernel tries to mount the root
filesystem, fstab won't be needed until fscking or so...
> I append the output of dmsetup tables to /etc/dmtab as the file says to
> do, and then configure /etc/conf.d/dmcrypt to the following lines:
> target=swap
> source='/dev/sda2'
> key='/dev/urandom'
> options='-c serpent-xts-plain -s 512 -h sha512'
>
> target=root
> source='/dev/sda3'
> options='-c serpent-xts-plain -s 512 -h sha512'
>
> target=var
> source='/dev/sda5'
> options='-c serpent-xts-plain -s 512 -h sha512'
>
> target=home
> source='/dev/sda6'
> options='-c serpent-xts-plain -s 512 -h sha512'
>
Okay, so I presume you do use SYSVinit. Again, dmcrypt won't be needed
until the boot runlevel is reached, you problem starts WAY before this.
> I also add lvm and dmcrypt to the boot runlevel. Kernel parameters are
> set as follows:
> kernel /boot/kernel cryptdevice=/dev/sda3:root
> crypto=sha512:serpent-xts-plain:512:0 root=/dev/mapper/root quiet
Unfortunately you don't say anything about your initrd/initramfs, because
at some point during early boot you'll have to provide the passphrase.
You are telling the kernel to use /dev/mapper/root which in turns seems to
be missing when the kernel tries to mount it.
That being said, the other options are obviously for your initramfs which
in turn should run cryptsetup. These should be documented by the
initramfs/initrd generator used. The initramfs/initrd should usually drop
you to a rescue shell. This way you could check what actually happened
etc.
As your GRUB line does not include an initramfs, how do you actually
provide the masterkey to cryptsetup and run cryptsetup? Or did you
piggy-back the initramfs?
>
> I have shifted and removed parts of these options in various ways
> possibly 15 or more different ways and nothing has worked.
>
> After all of this none of it works. I reboot and get a kernel panic, and
> then it says: VFS: root fs cannot be mounted on unknown block (hd0,0).
> And yes I have set LVM and DM_CRYPT options etc in the kernel.
I hope I could help to look in the right place for the necessary
information etc.
Regards
-Sven
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)
2014-09-22 10:02 ` Arno Wagner
@ 2014-09-22 19:07 ` Sven Eschenberg
2014-09-22 20:59 ` Arno Wagner
0 siblings, 1 reply; 10+ messages in thread
From: Sven Eschenberg @ 2014-09-22 19:07 UTC (permalink / raw)
To: dm-crypt
On Mon, September 22, 2014 12:02, Arno Wagner wrote:
> On Mon, Sep 22, 2014 at 07:41:39 CEST, Heiko Rosemann wrote:
>> On 09/22/2014 12:50 AM, vaskez@airmail.cc wrote:
>> > Several times I have set up virtual machines to test the cryptsetup
>> > software. I can create and remove the encrypted volumes just fine
>> > and mount them, however whenever I am finished setting up my system
>> > and reboot, my kernel panics, ends, then says that it cannot mount
>> > root fs on unknown block (hd0,0). I am sure that it is not a
>> > misconfiguration with the kernel, as I have built kernels for
>> > unencrypted systems and they have booted fine. Some information:
>>
>> You will need to setup an initramfs or modify the one provided with
>> the gentoo install to open your encrypted volumes (at least the root
>> volume). I do not remember how it is "supposed to be done" in gentoo,
>> but I do remember it's not as simple as installing software in the
>> right order.
>
> The thing is that the kernel cannot open LUKS encrypted partitions
> by itself. It needs user-space tools (cryptsetup) for that. That
> means the system must be running and have a working root filesystem.
> The initrd mechanism provides a temporary root filesystem for that
> use.
I think in his case is is plain dmcrypt which does not invalidate your
point of course.
>
> As I do not like initrds on my systems (too much hassle changing
> anything), I use a different approach: Non-encrypted root and
> anything I consider security-critical on encrypted partition(s).
Which is not hassle free either, esp. on headless systems. On one hand
local mounts and fscking is done early, so cryptsetup should be even
before that point, then again it can be difficult to provide the key
remotely that early during boot. (I know KVMoIP is your friend here ;-) ).
>
> A common criticism of that set-up is that it allows an attacker
> to change things on the root partition, but the same applies to
> the initrd (and the kernel!) as well and hence the initrd approach
> does not really offer better security. If you want to prevent that,
> you have to use some variant of secure boot, for example placing
> bootloader, kernel and initrd on an encrypted memory-stick with
> keypad or the like. And you better verify the BIOS checksum as
> well, although that may not be enough if somebody put a blue-pill
> in there. Fortunately such attacks are expensive and come with a
> high risk of detection, so unless you are a known terrorist or
> crimnal master-mind, don't worry about these.
I agree, but pulling parts of /etc or /var onto crypto targets, while
leaving parts unencrypted is quite ugly. So many people would just encrypt
/ alltogether to save them from that hassle.
>
> Second thing is that a running system is far easier to attack and
> as soon as it is opened, disk-encryption does not offer any
> protection anymore....
>
Indeed
>
> Arno
>
>
Regards
-Sven
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)
2014-09-22 19:07 ` Sven Eschenberg
@ 2014-09-22 20:59 ` Arno Wagner
2014-09-22 23:39 ` Sven Eschenberg
0 siblings, 1 reply; 10+ messages in thread
From: Arno Wagner @ 2014-09-22 20:59 UTC (permalink / raw)
To: dm-crypt
On Mon, Sep 22, 2014 at 21:07:58 CEST, Sven Eschenberg wrote:
> On Mon, September 22, 2014 12:02, Arno Wagner wrote:
[...]
> I think in his case is is plain dmcrypt which does not invalidate your
> point of course.
Possibly. As it does nit make much difference, I did nt make sure I\
got that right.
> >
> > As I do not like initrds on my systems (too much hassle changing
> > anything), I use a different approach: Non-encrypted root and
> > anything I consider security-critical on encrypted partition(s).
>
> Which is not hassle free either, esp. on headless systems. On one hand
> local mounts and fscking is done early, so cryptsetup should be even
> before that point, then again it can be difficult to provide the key
> remotely that early during boot. (I know KVMoIP is your friend here ;-) ).
Tell me about it. I have a headless firewall/fileserver in my
kitchen, and I got really fed up withhaving to carry it to
my desk whenever something stuck during boot. I finally
installed a serial interface to be able to debug it with a
laptop and minicom. I have given up on encryption during boot
for it, it just has an encrypted data partition that I mount
manually over ssh.
> > A common criticism of that set-up is that it allows an attacker
> > to change things on the root partition, but the same applies to
> > the initrd (and the kernel!) as well and hence the initrd approach
> > does not really offer better security. If you want to prevent that,
> > you have to use some variant of secure boot, for example placing
> > bootloader, kernel and initrd on an encrypted memory-stick with
> > keypad or the like. And you better verify the BIOS checksum as
> > well, although that may not be enough if somebody put a blue-pill
> > in there. Fortunately such attacks are expensive and come with a
> > high risk of detection, so unless you are a known terrorist or
> > crimnal master-mind, don't worry about these.
>
> I agree, but pulling parts of /etc or /var onto crypto targets, while
> leaving parts unencrypted is quite ugly. So many people would just encrypt
> / alltogether to save them from that hassle.
I have only data encrypted. Nothing in /etc/ or /var/ needs extra
protection IMO. The only thing besides data that I see as worthwhile
protecting are ssh private keys. Your needs may differ and I do
understand the argument. It is just important to remember that an
initrd is just as juicy a target for an attacker as a root
partition and if you do it manually, the initrd is more
complicated. Of course I also have non-module kernels tailored
for my systems, so that removes another reason for an initrd.
Gr"usse,
Arno
> > Second thing is that a running system is far easier to attack and
> > as soon as it is opened, disk-encryption does not offer any
> > protection anymore....
> >
>
> Indeed
>
> >
> > Arno
> >
> >
>
> Regards
>
> -Sven
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)
2014-09-22 20:59 ` Arno Wagner
@ 2014-09-22 23:39 ` Sven Eschenberg
2014-09-23 8:46 ` Arno Wagner
0 siblings, 1 reply; 10+ messages in thread
From: Sven Eschenberg @ 2014-09-22 23:39 UTC (permalink / raw)
To: dm-crypt
On Mon, September 22, 2014 22:59, Arno Wagner wrote:
> On Mon, Sep 22, 2014 at 21:07:58 CEST, Sven Eschenberg wrote:
>> On Mon, September 22, 2014 12:02, Arno Wagner wrote:
> [...]
>> I think in his case is is plain dmcrypt which does not invalidate your
>> point of course.
>
> Possibly. As it does nit make much difference, I did nt make sure I\
> got that right.
>
>> >
>> > As I do not like initrds on my systems (too much hassle changing
>> > anything), I use a different approach: Non-encrypted root and
>> > anything I consider security-critical on encrypted partition(s).
>>
>> Which is not hassle free either, esp. on headless systems. On one hand
>> local mounts and fscking is done early, so cryptsetup should be even
>> before that point, then again it can be difficult to provide the key
>> remotely that early during boot. (I know KVMoIP is your friend here ;-)
>> ).
>
> Tell me about it. I have a headless firewall/fileserver in my
> kitchen, and I got really fed up withhaving to carry it to
> my desk whenever something stuck during boot. I finally
> installed a serial interface to be able to debug it with a
> laptop and minicom. I have given up on encryption during boot
> for it, it just has an encrypted data partition that I mount
> manually over ssh.
>
You are lucky in a way, still physical access ;-). In this case having a
usb device with the key(s) is a viable option. Stick it in during boot and
pull it when the system is up. Works out of the box on some distros.
Well, maybe manually will win over laziness for me too. I am somewhat
fiddling on something like that currently.
BTW: Remeber the classic VT-10x Terminals? A modern portable variant would
be neat, I think. Like a netbook, but just a display controller+serial
chip, could be really flat and lightweight.
>> > A common criticism of that set-up is that it allows an attacker
>> > to change things on the root partition, but the same applies to
>> > the initrd (and the kernel!) as well and hence the initrd approach
>> > does not really offer better security. If you want to prevent that,
>> > you have to use some variant of secure boot, for example placing
>> > bootloader, kernel and initrd on an encrypted memory-stick with
>> > keypad or the like. And you better verify the BIOS checksum as
>> > well, although that may not be enough if somebody put a blue-pill
>> > in there. Fortunately such attacks are expensive and come with a
>> > high risk of detection, so unless you are a known terrorist or
>> > crimnal master-mind, don't worry about these.
>>
>> I agree, but pulling parts of /etc or /var onto crypto targets, while
>> leaving parts unencrypted is quite ugly. So many people would just
>> encrypt
>> / alltogether to save them from that hassle.
>
> I have only data encrypted. Nothing in /etc/ or /var/ needs extra
> protection IMO. The only thing besides data that I see as worthwhile
> protecting are ssh private keys. Your needs may differ and I do
> understand the argument. It is just important to remember that an
> initrd is just as juicy a target for an attacker as a root
> partition and if you do it manually, the initrd is more
> complicated. Of course I also have non-module kernels tailored
> for my systems, so that removes another reason for an initrd.
Of course all depends on your setup and need. Unfortunately configuration
data can be sensitive. Some daemons used to store credentials in /etc
(pppd ?, network filesystems?). If you run an MTA, you'd probably want to
secure the mailspool and maildirs (both usually in /var). With ssh private
keys you meant the host keys, I guess?
>
> Gr"usse,
> Arno
>
Regards
-Sven
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)
2014-09-22 23:39 ` Sven Eschenberg
@ 2014-09-23 8:46 ` Arno Wagner
0 siblings, 0 replies; 10+ messages in thread
From: Arno Wagner @ 2014-09-23 8:46 UTC (permalink / raw)
To: dm-crypt
On Tue, Sep 23, 2014 at 01:39:19 CEST, Sven Eschenberg wrote:
> On Mon, September 22, 2014 22:59, Arno Wagner wrote:
[...]
> > Tell me about it. I have a headless firewall/fileserver in my
> > kitchen, and I got really fed up withhaving to carry it to
> > my desk whenever something stuck during boot. I finally
> > installed a serial interface to be able to debug it with a
> > laptop and minicom. I have given up on encryption during boot
> > for it, it just has an encrypted data partition that I mount
> > manually over ssh.
> >
>
> You are lucky in a way, still physical access ;-). In this case having a
> usb device with the key(s) is a viable option. Stick it in during boot and
> pull it when the system is up. Works out of the box on some distros.
>
> Well, maybe manually will win over laziness for me too. I am somewhat
> fiddling on something like that currently.
>
> BTW: Remeber the classic VT-10x Terminals? A modern portable variant would
> be neat, I think. Like a netbook, but just a display controller+serial
> chip, could be really flat and lightweight.
Indeed. But I guess the market is too small for that and a cheap
netbook + usb-serial adapter and minicom work too well as replacement.
> >> > A common criticism of that set-up is that it allows an attacker
> >> > to change things on the root partition, but the same applies to
> >> > the initrd (and the kernel!) as well and hence the initrd approach
> >> > does not really offer better security. If you want to prevent that,
> >> > you have to use some variant of secure boot, for example placing
> >> > bootloader, kernel and initrd on an encrypted memory-stick with
> >> > keypad or the like. And you better verify the BIOS checksum as
> >> > well, although that may not be enough if somebody put a blue-pill
> >> > in there. Fortunately such attacks are expensive and come with a
> >> > high risk of detection, so unless you are a known terrorist or
> >> > crimnal master-mind, don't worry about these.
> >>
> >> I agree, but pulling parts of /etc or /var onto crypto targets, while
> >> leaving parts unencrypted is quite ugly. So many people would just
> >> encrypt
> >> / alltogether to save them from that hassle.
> >
> > I have only data encrypted. Nothing in /etc/ or /var/ needs extra
> > protection IMO. The only thing besides data that I see as worthwhile
> > protecting are ssh private keys. Your needs may differ and I do
> > understand the argument. It is just important to remember that an
> > initrd is just as juicy a target for an attacker as a root
> > partition and if you do it manually, the initrd is more
> > complicated. Of course I also have non-module kernels tailored
> > for my systems, so that removes another reason for an initrd.
>
> Of course all depends on your setup and need. Unfortunately configuration
> data can be sensitive. Some daemons used to store credentials in /etc
> (pppd ?, network filesystems?). If you run an MTA, you'd probably want to
> secure the mailspool and maildirs (both usually in /var). With ssh private
> keys you meant the host keys, I guess?
No, the user keys. I have a "privilege hieracy" among my machines
and downwards login is via password-less ssh, i.e. via the user's
private key. On the other hand, I think it is important to keep the
attacker-model in mind. Somebody with physical access to a running
machine can get everything anyways, most simple (can be bought
pre-packaged) if there is a firewire port, as that gives full
memory access. A bit harder, but likely possible is hot-plugging some
sort of PCI-E debugger. Then there is the old-fashioned (by now)
freezing of the memory and reading it externally. Hence a running
machine is not protected against a competent resouceful attacker
anyways. That leaves incompetent or resource-starved attackers
and non-running systems. On my Laptop, for example, I make sure
I notice access and I just protect the data if themachineis not
running. Of course I do not use hibernate/sleep modes, as there,
prepackaged attack kits are available as well. On my pgysical
server, I have said data-partition which is not normally decrypted.
On my vserver-residing mail-servers, I have no encryption at all,
as the vserver-provider can get at everything anyways. I do encrypt
all sensitive email via PGP/GnuPG though.
I have to admit that I am always a bit puzzeled when people
encrypt disks that are in a data-center and routinely mounted
and decrypted. That does not make much sense. Are they afraid
somebody will be able to steal the physical disks out of their
servers? There are two possible valid reasons though for doing
it: regulatory requirement and disk disposal.
Gr"usse,
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)
2014-09-22 16:10 ` Sven Eschenberg
@ 2014-09-25 19:25 ` vaskez
2014-09-25 22:57 ` Sven Eschenberg
0 siblings, 1 reply; 10+ messages in thread
From: vaskez @ 2014-09-25 19:25 UTC (permalink / raw)
To: sven; +Cc: dm-crypt, arno, heiko.rosemann
Thank you for your replies. Creating an initramfs image did the trick.
The only problems as of now are that the initramfs image fails to prompt
for the passphrase to the root partition. It will drop me into a rescue
shell, and from there I can use cryptsetup on the command line to
decrypt the root partition, then I must exit and it will continue
booting as normal. I hit OpenRC from there and the rest of my partitions
prompt for a passphrase. I created an initramfs image with dracut with
these options:
dracut -a "lvm dm crypt" -H --xz --strip initrd.img
I am still using these kernel paramters:
cryptdevice=/dev/sda3:root crypto=sha512:serpent-xts-plain:512
root=/dev/mapper/root net.ifnames=0 quiet
Are there other parameters that I should be using? Perhaps something
from dracut? I do not know of kernel parameters that can be accepted by
the kernel or where to find them, I have only used what has been shown
from Arch Linux wiki on dm-crypt plain.
Also whenever I halt my system it will print 30 some lines of ioctl
complaining about the root fs is still in use, then quit. I do not think
this is much a problem, because it will skip it and umount the other
filesystems, then mount root as ro and finally shutdown. Do you think
that this is a problem? If so, how would I be able to stop it?
> First of your problems are very distributzion specific.
>
> The kernel complains that it cannot find the block device that was
> passed
> via root= parameter (without root= it will probably use the first hd
> block
> device it sees as fallback).
>
> On Mon, September 22, 2014 00:50, vaskez@airmail.cc wrote:
>> Several times I have set up virtual machines to test the cryptsetup
>> software. I can create and remove the encrypted volumes just fine and
>> mount them, however whenever I am finished setting up my system and
>> reboot, my kernel panics, ends, then says that it cannot mount root fs
>> on unknown block (hd0,0). I am sure that it is not a misconfiguration
>> with the kernel, as I have built kernels for unencrypted systems and
>> they have booted fine. Some information:
>>
>> The encrypted volumes are created with:
>> cryptsetup -y -v -c serpent-xts-plain -s 512 -h sha512 create dmname
>> device
>>
>> Previous partition layouts was like such:
>> /dev/sda1 +b Linux 100M (/boot) (not encrypted)
>> /dev/sda2 Linux Swap / Solaris 2G (swap)
>> /dev/sda3 Linux 10G (root)
>> /dev/sda4 Extended
>> /dev/sda5 Linux 2G (/var)
>> /dev/sda6 Linux 6G (/home)
>>
>> This last time the layout was like such:
>> /dev/sda1 +b Linux 100M (/boot) (not encrypted)
>> /dev/sda2 Linux LVM 2G (swap)
>> /dev/sda3 Linux LVM 10G (root)
>> /dev/sda4 Extended
>> /dev/sda5 Linux LVM 2G (/var)
>> /dev/sda6 Linux LVM 6G (/home)
>>
>> The distribution I am using is Gentoo with a custom (to test at one
>> time) and modified i386_defconfig (every other time) kernel patched
>> with
>> GRSecurity.
>>
>> This last time installing cryptsetup I made sure to install packages
>> in
>> a specific order, like installing cryptsetup before grub legacy and
>> still got the same error. I had set root (hd0,0) in grub command line
>> and setup (hd0) on the command line. At one time I had tested setup on
>> (hd0,0), still the same error. When issuing grub-install /dev/sda in
>> bash, it will say that df cannot read filesystems and that it cannot
>> read a device map file, so I had to install grub in grub command
>> shell.
>
> Grub is its own thing, does the bootloader load the kernel from an
> encrypted fs? grub legacy? grub 2?
>
>>
>> I install cryptsetup from portage with USE="-thin" emerge -avtq
>> cryptsetup. -thin does not install thin provisioning tools and the
>> boost
>> sys utils which I assume are very big because they take very long to
>> install.
>
> cryptsetup does not have any thin use flag afaik, lvm2 is the one using
> thin provisioning ...
>>
>> After installing cryptsetup, I configure /etc/crypttab (which does not
>> exist) as follows:
>> swap /dev/mapper/swap /dev/urandom
>> swap,cipher=serpent-xts-plain,size=512,hash=sha512
>> root /dev/mapper/swap none
>> root,cipher=serpent-xts-plain,size=512,hash=sha512
>> var /dev/mapper/swap none
>> var,cipher=serpent-xts-plain,size=512,hash=sha512
>> home /dev/mapper/swap none
>> home,cipher=serpent-xts-plain,size=512,hash=sha512
>
> Gentoo does not really use crypttab, does it? instead it will use
> dmcrypt
> in conf.d (for SYSVinit), might use crypttab for systemd though.
>
>>
>> /etc/fstab looks like:
>> /dev/sda1 /boot ext2 noauto,noatime 0 2
>> /dev/mapper/swap none swap sw 0 0
>> /dev/mapper/root / ext4 defaults,relatime 0 1
>> /dev/mapper/var /var ext4 defaults,relatime 0 1
>> /dev/mapper/home /home ext4 defaults,relatime 0 0
>> /dev/cdrom /mnt/cdrom auto noauto,user 0 0
>>
>
> fstab does not really matter when the kernel tries to mount the root
> filesystem, fstab won't be needed until fscking or so...
>
>> I append the output of dmsetup tables to /etc/dmtab as the file says
>> to
>> do, and then configure /etc/conf.d/dmcrypt to the following lines:
>> target=swap
>> source='/dev/sda2'
>> key='/dev/urandom'
>> options='-c serpent-xts-plain -s 512 -h sha512'
>>
>> target=root
>> source='/dev/sda3'
>> options='-c serpent-xts-plain -s 512 -h sha512'
>>
>> target=var
>> source='/dev/sda5'
>> options='-c serpent-xts-plain -s 512 -h sha512'
>>
>> target=home
>> source='/dev/sda6'
>> options='-c serpent-xts-plain -s 512 -h sha512'
>>
>
> Okay, so I presume you do use SYSVinit. Again, dmcrypt won't be needed
> until the boot runlevel is reached, you problem starts WAY before this.
>
>> I also add lvm and dmcrypt to the boot runlevel. Kernel parameters are
>> set as follows:
>> kernel /boot/kernel cryptdevice=/dev/sda3:root
>> crypto=sha512:serpent-xts-plain:512:0 root=/dev/mapper/root quiet
>
> Unfortunately you don't say anything about your initrd/initramfs,
> because
> at some point during early boot you'll have to provide the passphrase.
>
> You are telling the kernel to use /dev/mapper/root which in turns seems
> to
> be missing when the kernel tries to mount it.
>
> That being said, the other options are obviously for your initramfs
> which
> in turn should run cryptsetup. These should be documented by the
> initramfs/initrd generator used. The initramfs/initrd should usually
> drop
> you to a rescue shell. This way you could check what actually happened
> etc.
>
> As your GRUB line does not include an initramfs, how do you actually
> provide the masterkey to cryptsetup and run cryptsetup? Or did you
> piggy-back the initramfs?
>
>>
>> I have shifted and removed parts of these options in various ways
>> possibly 15 or more different ways and nothing has worked.
>>
>> After all of this none of it works. I reboot and get a kernel panic,
>> and
>> then it says: VFS: root fs cannot be mounted on unknown block (hd0,0).
>> And yes I have set LVM and DM_CRYPT options etc in the kernel.
>
> I hope I could help to look in the right place for the necessary
> information etc.
>
> Regards
>
> -Sven
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)
2014-09-25 19:25 ` vaskez
@ 2014-09-25 22:57 ` Sven Eschenberg
0 siblings, 0 replies; 10+ messages in thread
From: Sven Eschenberg @ 2014-09-25 22:57 UTC (permalink / raw)
To: dm-crypt
On Thu, September 25, 2014 21:25, vaskez@airmail.cc wrote:
> Thank you for your replies. Creating an initramfs image did the trick.
> The only problems as of now are that the initramfs image fails to prompt
> for the passphrase to the root partition. It will drop me into a rescue
> shell, and from there I can use cryptsetup on the command line to
> decrypt the root partition, then I must exit and it will continue
> booting as normal. I hit OpenRC from there and the rest of my partitions
> prompt for a passphrase. I created an initramfs image with dracut with
> these options:
> dracut -a "lvm dm crypt" -H --xz --strip initrd.img
>
> I am still using these kernel paramters:
> cryptdevice=/dev/sda3:root crypto=sha512:serpent-xts-plain:512
> root=/dev/mapper/root net.ifnames=0 quiet
>
> Are there other parameters that I should be using? Perhaps something
> from dracut? I do not know of kernel parameters that can be accepted by
> the kernel or where to find them, I have only used what has been shown
> from Arch Linux wiki on dm-crypt plain.
As you use dracut, please consult the dracut documentation and/or
mailinglist, as the remaining problems depend solely on that bloatware.
FYC:
http://fedoraproject.org/wiki/Dracut/Options#Dracut_kernel_command_line_parameters
The parameters you use (except for root=) are NOT kernel parameters.
If I had to guess: Dracut is not as distribution agnostic as it cliams and
thus does not even try to start your crypto target.
>
> Also whenever I halt my system it will print 30 some lines of ioctl
> complaining about the root fs is still in use, then quit. I do not think
> this is much a problem, because it will skip it and umount the other
> filesystems, then mount root as ro and finally shutdown. Do you think
> that this is a problem? If so, how would I be able to stop it?
The gentoo openrc init scripts are quite fatal in that they try to
'shutdown' everything, including LVMs, dmcrypt targets etc. they did not
necessarily start. Tracking what was setup during boot is quite
cumbersome, when most utils provide switches to shutdown just everything
they can find.
That being said: If there's no entry for your root device in
/etc/conf.d/dmcrypt you won't get a message during start that it is
already configured, and the script will not try to close the mapping (this
is actually dracut's job). Similiar things apply to LVMs/mounts etc.
Regards
-Sven
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-09-25 22:57 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-21 22:50 [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0) vaskez
2014-09-22 5:41 ` Heiko Rosemann
2014-09-22 10:02 ` Arno Wagner
2014-09-22 19:07 ` Sven Eschenberg
2014-09-22 20:59 ` Arno Wagner
2014-09-22 23:39 ` Sven Eschenberg
2014-09-23 8:46 ` Arno Wagner
2014-09-22 16:10 ` Sven Eschenberg
2014-09-25 19:25 ` vaskez
2014-09-25 22:57 ` Sven Eschenberg
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.