[dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)

Arno Wagner arno at wagner.name
Tue Sep 23 10:46:27 CEST 2014

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. 

Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno at 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

More information about the dm-crypt mailing list