[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

MOK utility and serial console



Hello,

Recently I had a horrible experience trying to resurrect a computer
that it turned out had a failed motherboard. The new board had EFI
secure configured and it is not entirely obvious on how to turn that
off. Being visually-impaired, accessing the initial setup menus proved
extremely challenging since the machine does not have a native 16550a
UART.

I used the gnome live CD to start speech synthesis and a
gnome-terminal.  I converted the bios-based boot process to EFI, then
immediately realized secure boot was enabled because a dialogue box
popped telling me disabling that was possible but it required
intervention on the console.

Fine, I thought, and generated a simple password. I randomly typed it
after rebooting, but secure boot did not go away. A closer look at the
secure boot wiki indicated you have to reboot, select enroll MOK,
select continue, confirm, then type the password. (I had subsequently
decided to enroll a MOK so that my Virtualbox machines would start)

I also was trying to enable USB serial with ftdi driver through grub
and get a serial console, because I have a USB ftdi device. I found a
blog post that showed what modules to insert during Grub launch and
wrote up a quick grub template for it that would run before 00_header.

To my surprise, the modules are not properly signed, so grub refused
to load the grub modules for usbserial_ftdi and friends. I determined
this by using my phone running the "lookout" app (not the antivirus
one) and although the text was extremely garbled because I could not
line it up exactly with a monitor, loads of warnings about secure boot
told me the modules that ship with grub are not signed.

The MOK manager thing appears to run before grub, so, getting it to
support serial seems nontrivial, and getting it to run over a USB
serial seems down right impossible due to the complexity of loading
the usb stack so you can have the serial port. Interestingly enough,
the USB keyboard works so somewhere it is initialized.

In the end, I had to randomly press a key quickly (have to OCR the
screen, read it, press the key, and hope you do it within 10 seconds)
or you have to go through the whole process of trying to import the
MOK key again.

Since I created a passphrase with my key, the virtualbox builder
refuses to sign vboxdrv.ko and friends because it does not have a way
for retrieving a pass phrase from the user. I usually don't have
passphrases on my certs, but, without a passphrase, an attacker who
has access to the MOK key can sign anything, tainting my kernel with a
malicious module and without user intervention on the console.

So I'm not really sure where to start here, but a blind developer is
going to have a hard time working in a secure boot system without the
ability to interface with the mok manager.  I am well aware that any
backdoor accomodations for accessibility could be exploited by
attackers to circumvent the secure boot system.  If this were a
virtual image, it would get even more complicated as my virtual images
are all headless.

In the end, I hacked the vboxdrv.sh to ask the user for a password,
but for some reason I have to do that every time the machine boots--it
does not start vboxdrv by itself upon initial boot even though the
modules are signed.

I'm hoping somebody can help here, because this was certainly more
challenging than I bargained for, and caused several days of downtime.
I CAN'T WAIT to see how much fun it is to build my own kernel with its
modules and sign each and every one.

Thanks

_J


Reply to: