root labs rdist

I recently upgrade my laptop to FreeBSD 7 in anticipation of the upcoming 7.0 release. This should be a major advance with new features such as ZFS and increased scalability due to improvements in the ULE scheduler. It went ok overall with a few important changes to note.

First, don’t use make delete-old-libs until you’ve updated all your ports. That article also includes a script for figuring out what’s no longer used. There was a bump in major version numbers for all libraries when symbol versioning was enabled, so you’ll get lots of “not found” errors for third-party applications if you run this before upgrading your ports. If this happens, all is not lost. You can continue running by symlinking most libraries to their new versions:

	ln -s /usr/lib/libc.so.7 /usr/lib/libc.so.6

Next, there are some changes to the Intel wireless drivers. The iwi-firmware-kmod port is no longer needed now that the firmware is included in the base kernel. You just have to set a tunable to agree to the license:

	legal.intel_iwi.license_ack=1

And load the various firmware files via /boot/loader.conf:

	iwi_bss_load="YES"
	iwi_ibss_load="YES"
	iwi_monitor_load="YES"

For more information, see the iwi man page. With these changes, my system again works fine. Now I need to look into fixing some acpi problems.

For those of you looking for more security and crypto posts, you won’t be disappointed with my next series.

The Panasonic R/W/T/Y series is a set of ultralight notebooks, also available in a US model. I like the Y4-Y7 for their large screen, light weight, and long battery life.

There are a couple things needed to get suspend/resume working on these models in FreeBSD. To get the backlight on and video working again, we need to trigger the 0xc000 video BIOS reset. Set the following in /etc/sysctl.conf:

hw.acpi.reset_video=1

The built-in mouse is stuck once we resume. We need to reinitialize it by setting the following in /boot/loader.conf. This should really be done automatically since the reinitialization should work on most systems. But more testing will have to be done before that is enabled by default.

hint.psm.0.flags="0x2000"

With these changes, I can suspend/resume to RAM successfully. For more info, check the handbook.

As a FreeBSD committer, I also run FreeBSD on a lot of my machines. I recently upgraded my desktop with portupgrade and found that gnupg no longer worked. I got the error message:

gpg-agent[13068]: can’t connect server: `ERR 67109133 can’t exec `/usr/local/bin/pinentry’: No such file or directory’
gpg-agent[13068]: can’t connect to the PIN entry module: IPC connect call failed
gpg-agent[13068]: command get_passphrase failed: No pinentry
gpg: problem with the agent: No pinentry

I found these two articles and noticed that my gpg had been upgraded from the 1.x to 2.x series. The 1.x gpg had an integrated password entry prompt but 2.x requires an external package. This can be fixed by installing the security/pinentry port. I’m not sure why it wasn’t marked as a dependency for gpg2.

In a previous comment, Tim Newsham mentions reverse engineering an application by running it in a VM. As it so happened, I gave a talk on building and breaking systems using VMs a couple years ago. One very nice approach is ReVirt, which records the state of a VM, allowing debugging to go forwards or backwards. That is, you can actually rewind past interrupts, IO, and other system events to examine the state of the software at any arbitrary point. Obviously, this would be great for reverse engineering though, as Tim points out, there haven’t been many public instances of people doing this. (If there have, can you please point them out to me?)

An idea I had a few years back was to design a VM-based system to assist in developing Linux or FreeBSD drivers when only Windows drivers are available. The VM would be patched to record data associated with all IO instructions (inb, outb, etc.), PCI config space access, and memory-mapped IO (a “wedge” device.) It would pass through the data for a single real hardware device. To the guest OS, it would appear to be a normal VM with one non-virtual device.

To reverse engineer a device, you would configure the VM with the bus:slot:function of the device to pass through. Boot Windows in the VM with the vendor driver installed. Use the device normally, marking the log at various points (”boot probe”, “associating with an AP”). Pass that log on to the open source developer to assist in implementing or improving a driver.

A similar approach without involving a VM would be to make a Windows service that loads early and hooks HAL.DLL as well as sets protection on any memory mappings of the target device. Similar to copy-on-write, access to that memory would trigger an exception that the service could handle, recording the data and permitting access. This could be distributed to end users to help in remote debugging of proprietary hardware.