GELI encrypted root, boot password problem

W

wildtollwut

Hello,

Today I upgraded my small i386 server to FreeBSD 9.1-STABLE. My root is based on ZFS and is completely encrypted via geli. I boot from a USB key and enter the passphrase before root is mounted at boot time. This worked fine until the upgrade to 9.1. Now I can't seem to enter a passphrase, nothing is happening when I hit Enter. The system doesn't hang apparently as I may enter the scroll lock mode and scroll to my heart's delight :)

It's a USB keyboard and unplugging and replugging is of no use. The keyboard works fine in the boot menu. Disabling ACPI or enabling safe mode don't help :/

If I remember correctly a similar problem was present in 8.0 or 8.1 but got fixed since.
 
On some machines USB2 keyboards won't work well with the password prompt (because kernel modules can't be loaded on-demand until mountroot succeeded). I had this issue with a Supermicro box in the past, and fixed it by updating its BIOS and enabling setting USB legacy mode.

On some other machines USB devices respond (or the responses are handled) only after GELI has prompted for the password/secret, so the prompt fades into the other output made during boot.

Of course, you can get the combination of these two :D

Try setting kern.geom.eli.debug to something between 1 and 3 in loader.conf for more GELI output. Also, if deleting /var/log/messages after boot is an option to you, you can try to set kern.geom.eli.visible_passphrase to 1, which causes your password input to become visible.
 
Unfortunately my BIOS doesn't have an option like 'USB legacy mode' and there is no newer BIOS available.

As of 9.1-STABLE The keyboard is handled in g_eli.c by a call to cngets() (this was gets() in 9.0). I tried reverting to the gets() function which is essentially similar except for an extra call to cngrab() but this didn't help with my problem.

If I can't get it to work using geli's debug messages I'm going to try to go back to the USB keyboard driver from 9.0 as well and see if this helps. But this is all not very satisfactory :|

Update: Strangely enough, kern.geom.eli.visible_passphrase=1 has no effect at all (kern.geom.eli.debug=3 does but doesn't help). I still don't see any of my input, as if the "input field" didn't have the focus.

Update2: Reverting to 9.0's USB keyboard driver ukbd.so didn't work either. Any other ideas what I could try?
 
I tried another keyboard - exactly the same behaviour.

Update:
After setting
Code: 
hint.atkbd.0.disabled="1"
hint.kbdmux.0.disabled="1"
in /boot/device.hints, I now get
usbd_set_config_index: could not read device status: USB_ERR_TIMEOUT

No idea if this is related.

Update2:
I now disconnected all boot drives which leaves me with the mountroot prompt. Here I don't have any keyboard access at all, not even scroll lock. Hence I suspect this is rather a USB driver bug than something geli-related
 
Just tried 9.2-BETA1. The keyboard is working again in the mountroot prompt but still not for the GELI password prompt. Very strange...
 
wildtollwut said:
Hello,

Today I upgraded my small i386 server to FreeBSD 9.1-STABLE. My root is based on ZFS and is completely encrypted via geli. I boot from a USB key and enter the passphrase before root is mounted at boot time.
Click to expand...

Can I ask what guide (or how) you set up an encrypted geli ZFS root with a bootable USB key?

My server is set up using this guide:Full Disk Encryption (with ZFS root) for FreeBSD 9.x

I have had no luck in finding the steps to follow to use a bootable USB key with an encrypted ZFS root, can you help?

Some of the questions I had regarding using a bootable USB key and and encrypted ZFS root are:
  1. When can you remove the USB key after the machine has finished booting up?
  2. What type of file system do you use on the USB key? UFS? ZFS?
  3. When upgrading FreeBSD, I assume the USB key needs to be inserted and mounted for the upgrade the succeed?
  4. Can you convert from using an unencrypted ZFS boot pool to using a bootable USB key?

I'd really appreciate any help or assistance regarding this as after countless hours Googling it I have come up empty handed which I thought strange as its such a cool option to secure your system this way.

Many thanks! ;)
 
The USB key can basically be removed after root mount is successful. I used to remove it when the login prompt appeared. The file system on the key is a simple UFS that essentially contains the directory /boot from the install disk.
Updates are hassle-free as in they can be performed normally. After the kernel and its modules have been updated, I manually copy them to the USB key which has worked fine for the last four or so updates.

I don't think an easy conversion from non-encrypted to encrypted is possible because in my setup GELI is loaded and used first on the volumes. After the volumes are attached ZFS can use them to create/mount a working file system. If we had the ZFS encryption feature this wouldn't be necessary, but well :) Additionaly when initializing the GELI devices a parameter (-b?) has to be supplied for the password prompt to appear during boot.
Had I known before that there are that much problems with accessing this password prompt via USB keyboard I suppose I would only have used a boot via USB key (and without password prompt).

If I remember correctly, this is the tutorial I used. It's a little out of date now as e.g. gpart could be used for partitioning but the main part is still valid. Feel free to ask in case of problems or further questions.


--

My own system is still not working unfortunately. I'll have to go back to 9.0 if that's possible somehow :/
 
Probably last update for this thread: I didn't manage to sort out my problems. Hence I returned to 9.0-STABLE. I shall be grateful for any future hints or a solution, however.
 
Update: today I tried 9.2-RELEASE. Unfortunately, the problem still persists. I am unable to enter anything or press enter at the GELI prompt and therefore cannot boot. I'm stuck with 9.0 for the time being. Any ideas where to post this so it won't get buried as in the mailing lists and probably addressed by someone knowledgeable? It seems to be a regression for what it's worth...
 
Quarterly update: 10.0 still doesn't fix my problem :( I'd really like to somehow assist in fixing this but up to now, no luck.
 
Hi all,

Just to share my experience:

I faced the same wall last summer. FreeBSD 9.2-RELEASE + GELI + ROOT on ZFS + AES-NI setup with booting from a USB drive using Supermicro MB and WD RE4 1 TB SATA2 HDDs worked as a charm. But the same setup using a Gigabyte H77-D3H MB worked only with attached Hitachi Deskstar SATA2 2 TB HDDs. Passwords for other vendors' HDDs were not accepted during boot. Changing keyboards and sysctl variables didn't help. I gave up disk encryption after struggling for a week because such a setup is unpredictable. Even if it works fine today what will happen when when a hardware replacement is needed tomorrow?

I hope the findings above help someone.
 
Some new findings on my problem. I, once again, tried reverting to code from the 9.0 kernel and implanted it in the 10.0-kernel. I was surprised at first, because I could enter the password at boot and the system worked properly. However, I accidentally enabled the APIC that I had disabled (as my system was crashing/freezing after some days with enabled APIC). Now, I'm either not able to boot my system or able to boot it with the APIC enabled but it will only live two or three days. Currently, I'm compiling a kernel with kernel debugging support. vmstat -i doesn't signal any interrupt storms which could lead to a complete freeze.
 
Follow up: I was unable to solve my problems with the old hardware. In the meanwhile I switched to an Intel NUC keeping my old hard disk which worked like a breeze. The APIC/ACPI/Interrupt problems are gone and the system is even a little faster now.
 
Have you tried to press <Return> several times until it shows an error regarding wrong password and the number of left retries?
 
(Somewhat delayed reply) Yes I tried that - no keypress whatsoever was accepted. The only solution for my problem was to switch to new hardware and use the amd64 architecture. I think the problem was rooted in the interplay of USB driver, probably faulty hardware/firmware and other intricacies with the i386 architecture :)
I did attempt to tackle the problem from various sides, even Kernel-level debugging but to no success. After switching to the Intel NUC the problems are gone and the system is faster.
 
I'm having this very issue except that I do not have an option to switch to new hardware.

I did a fresh install with 10.1-BETA3. I decided to encrypt the
boot partition using geli (only option given).

The keyboard i have is a USB keyboard. The keyboard works fine in all
scenarios except for when prompted with the geli password.

http://i.minus.com/ibbw2T5C7Oppp5.jpg

I tried with multiple different keyboards connected. Here's an Apple
keyboard and a standard PC Roswill keyboard.

There's no response at all from geli.

I tried installing FreeBSD without geli and I had no issues with the
keyboard to login later during boot. It appears to be a problem with geli.

I do want to have my boot drive encrypted.

Does anyone have any ideas? Suggestions? Money to send me?

Motherboard: http://www.amazon.com/gp/product/B00FM4M7TQ
 
I don't think it's a GELI issue but rather a USB keyboard driver problem. Most likely you will also not get a
keyboard in the mountroot prompt (as in my case). You could try asking the question on the freebsd-usb mailing list again but this seems to be a recurring bug or rather a symptom of an underlying problem that nobody has figured out yet - probably even a timing problem.
Problems apparently often occur with Atom hardware. I still have the old hardware here, if someone gave me a primer on how to (Kernel) debug the problem, I would be more than happy to help.
 
wildtollwut said:
I don't think it's a GELI issue but rather a USB keyboard driver problem. Most likely you will also not get a
keyboard in the mountroot prompt (as in my case). You could try asking the question on the freebsd-usb mailing list again but this seems to be a recurring bug or rather a symptom of an underlying problem that nobody has figured out yet - probably even a timing problem.
Problems apparently often occur with Atom hardware. I still have the old hardware here, if someone gave me a primer on how to (Kernel) debug the problem, I would be more than happy to help.
Click to expand...

Thanks for your comment. I just asked on freebsd-stable and someone had a suggestion to try "mashing the keyboard
during the system's initial device probing". I'm going to give that a whirl.
 
I found a setting called "Port 60/64 Emulation which when disabled allowed me to enter the password for encryption. (Woo-hoo!)

The description in the BIOS for this setting is:

"Enables I/O Port 60h/64h emulation support"

I also noticed that when I do a system halt, there is a prompt to press keyboard to reboot. That also didn't work with the way things work.

So, it seems to me there's a fix related to this Port 60/64 that could be done on the OS side of things.
 
Interesting! But unfortunately by BIOS does not have such an option. What does it do actually? For me, as written before, it sometimes helped to disable ACPI or the APIC but this never lasted more than one minor version. It would really be great to get to the bottom of this.

Edit: Ah, I see, this is what is does apparently:
When enabled, the BIOS will emulate I/O ports 64h and 60h for your USB keyboard and mouse. This enables PS/2 functionality like keyboard lock, password setting and scan code selection.
Click to expand...
This will circumvent the original bug but I fear it won't help much to fix it.
 
wildtollwut said:
Interesting! But unfortunately by BIOS does not have such an option. What does it do actually? For me, as written before, it sometimes helped to disable ACPI or the APIC but this never lasted more than one minor version. It would really be great to get to the bottom of this.
Click to expand...

You should chip in here: https://bugs.freebsd.org/bugzilla/show_ ... ?id=194226

saying you have the same problem but that your BIOS doesn't have the option so it's more critical.

I have no idea what this emulation does. Hopefully one of them (core devs) understands.
 
So wait, did you _enable_ this option or disable it in order to get it to work? Because the Bugzilla you linked says that USB does not work if the option is enabled.
 
I tried disabling all legacy USB options first. I discovered that doing so actually got it to work. The problem then was that I wasn't able to choose bootloader options.

Then I tried disabling just the emulation and that got everything to work.
 
You must log in or register to reply here.
Back
Top