I use geli to encrypt partition on my laptop for a very long time.
The only problem is when I need to suspend the laptop (yes, suspend works almost like a charm on my t43) - I need to detach  my encrypted partition then. It would be more or less safe for me to leave it attached, as I lock my console with ’vlock -a’ command, so the only thing a thief can do is to turn off the laptop, thus remove keys from the memory. Although leaving attached partition with all the keys in memory doesn’t seem right…
BTW. ‘vlock -a’ is really nice, because when everything is locked, it will reset the system when one tries to enter DDB. Not sure if that is intended behaviour, but very useful.
Detaching encrypted partition is a bit PITA, as I keep a lot of stuff in there, so before I can unmount the file system and detach it, I need to go through all my x-terms and cd out of directories from encrypted file system, I need to close all encrypted files, etc.
I decided to implement suspend and resume subcommand for geli(8). Before I suspend my laptop I execute ‘geli suspend’. This command tells GELI GEOM class in the kernel to remove all sensitive informations, and delay all further I/O request until ‘geli resume’ (or ‘geli detach’) command is called. This way I don’t need to unmount file system sitting on top of the encrypted partition. When I execute ‘geli resume’ command after resume, I provide my password just like for ‘geli attach’ command, which allows GEOM class to recreate all the keys in the kernel and start the I/O traffic again.
The tricky part is not to suspend a provider which ’geli resume’ needs to access, because you will simply deadlock your system. For example it most likely won’t work for fully encrypted disk. One way to fix this is to join functionality of suspend and resume geli subcommands, ie. ‘geli suspend’ will automatically ask for the passphrase (without the need of reading or executing anything), which can be given after resuming the laptop. I haven’t decided what to do about that yet, the code is in my perforce tree for now and will probably be committed after the RELENG_7 is branched.
Some time ago I got my hands on a bunch of more or less broken Linksys 802.11 APs and wireless routers. They have been sitting in my closet until recently, when I decided to mock a bit with one of the WRT54G models.
First things first – I had to establish contact with the onboard firmware. Since the board didn’t respond on any of the ethernet interfaces I set out to construct an RS-232 level converter to use with the onboard 3.3V TTL serial interface.
Judging from google, people use all kinds of weird and somewhat complicated (not to mention quite expensive) circuits in order to convert the voltage levels of the WRT54G serial interface to RS-232 levels. I decided to go with my own simple, cheap and effective design based on the Maxim MAX3232 as shown below:
The pinout of the IDC connector on the Linksys WRT54G – X3 in the diagram above – is as follows (thanks to Rod Whitby for posting information on the pinouts, saved me a bit of trial-and-error):
| Pin # |
Description |
Pin # |
Description |
| 1 |
3.3V |
2 |
3.3V |
| 3 |
Tx (ttyS1) |
4 |
Tx (ttyS0) |
| 5 |
Rx (ttyS1) |
6 |
Rx (ttyS0) |
| 7 |
NC |
8 |
NC |
| 9 |
GND |
10 |
GND |
The onboard firmware of the WRT54G provides a console on ttyS0 at 115200 1N8. Since the above pinout lacks RTS/CTS lines we have to rely on software flow control.
To connect to the console one might use a command like cu(1):
$ cu -l /dev/ttyU0 -s 115200
Below is a couple of action-shots of the circuit in use:
The next logical step is to get FreeBSD/mips up and running on this thing ;-)
Several people have asked me about the system monitor running on the root window of my ThinkPad X60s’ X11 desktop – not many of them had spotted that is was actually just conky with an advanced configuration and a custom wallpaper:
My ~/.conkyrc can be downloaded from here. The panel at the bottom center is from FluxBox, my window manager of choice. The panel to the left is fbpager, a desktop pager for use with FluxBox.
This years EuroBSDCon was great fun! It was the second time I attended EuroBSDCon, and it was great meeting up with – what has come to my understanding is – the “usual crowd” again.
The talks this year were very high quality and the social and networking aspect was very enjoyable – ranging from Robert Watson’s talk about the TrustedBSD enhancements to the traditional Unix security model to my ZFS debug session with Pawel Jakub Dawidek.
I took a few, muddy photos at the conference – they can be found at the usual place. See you all next year in Strasbourg!
When I started the “sky” project (the new jail based www.FreeBSD.org) I never expected how much magic was involved, or how long it would take to set up a new www.FreeBSD.org from scratch, so that’s why the project has been going slow for a while.
Over the last month or so the current www.FreeBSD.org has had severe hardware problems which caused it to crash often. That is of course rather annoying but the positive thing is that it has given me motivation for finishing up the setup on sky. Now that EuroBSDCon 2007 is over I will also have more time to do other FreeBSD stuff again.
I am currently at the FreeBSD Developers summit and I’m mainly working on sky. It’s been a while since I messed with it so just upgrading ports etc. in the jails has taken some time, but I’m not done yet – so stay tuned for more updates.
Oh, and if www.FreeBSD.org is down, try wwwfe.FreeBSD.org which is the main FreeBSD website running on sky.FreeBSD.org.
EuroBSDCon 2007 starts in a few days. It will take place in Copenhagen, Denmark this year, so my travel time is greatly reduced compared to last year (where it took place in Milan, Italy).
I am especially looking forward to Sam Leffler’s talk about long distance wireless networks, Robert Watson’s talk about FreeBSD security features and Kirk McKusick’s talk about the BSD fast filesystem – and, of course, networking with other *BSD enthusiasts.
Erwin kindly offered me a ride on his bike to get there, so hopefully the weather gods wont be too agry the next couple of days ;)
Oh, and remember to bring two government issued photo IDs if you want me to sign your PGP/GPG key or a CACert Web of Trust form.
See you in Copenhagen!
X Window System Release 7.3
2007-09-06
The X11R7.3 release incorporates the 1.4 version of the X.Org X Server, which
is most notable for the addition of input hotplugging support, with device
detection managed either through HAL or a dbus-connected manager.
Also new in the X Server since X11R7.2 is the 1.2 version of the RandR
extension, which allows for runtime configuration of outputs within X Screens
and an improved static configuration system for multihead in a RandR 1.2
environment.
This release also rolls in a new driver, xf86-video-vermilion, and re-adds
the xf86-video-glide driver which had been present in the monolithic releases.
The xbacklight command-line tool is also added for configuring backlight
properties through RandR 1.2. Other modules have also gone through the usual
host of updates and bugfixes as well.
Previous release managers may find me strange, but I didn't mind too much dealing with the release. It was approximately the expected level of stress and frustration. I made some changes this time around which greatly reduced the burden -- the old "branded" tarballs (
modulename-X11Rwhatever-version.tar.b2 instead of just
modulename-version.tar.bz2) are now a thing of the past, and the published directory structure is simplified. I've update the wiki instructions for the next release manager, and it's relatively short. Basically the only work that's left is what should be left -- making sure all the modules work well together, and making sure the blocker bugs for the server get resolved.
As far as that, I think it was a mixed result. Blocker bugs for the server I think I handled reasonably well -- hounding the appropriate people for the critical fixes, and not blocking to deal with the last-minute fixes for minor issues. But the whole-release integration didn't go too well, with at least one required module update having been left out initially (fixed this morning). What I hope we can have happen for the next katamari:
- I'll tinderbox the proposed module list in our ports tree to shake out integration issues.
- Module maintainers may update util/modular/module-list.txt to make sure their stuff lands in the next release.
Our new translator, Gábor Páli has been doing very well, he submitted 4 new translations, which I committed today, thus we have now a webpage and 6 articles. We are considering starting the translation of handbook, too. I’m glad that made such a good progress in this project and I hope other volunteers will join when they see our results and realize that this is a serious project.
Ok, it’s been a while that I’ve written here, thus I’m dropping some lines about SoC. You can check the actual progress on my wiki page, but I want to write about two parts, which I considered the most important. One of those is the DESTDIR functionality for ports. I also invested a lot of time and effort into this during SoC 2006, but that time I went into a wrong direction. Sometimes it is hard to implement a new functionality later, which was not planned originally, it seems it happened in that case. The good idea came too late and I could not accomplish that in 2006, but as I could participate again, I successfully reworked it and we have now a simple, but working version in CVS. This implementation uses chroot(1) and it made the structure of the ports/Mk code a bit simpler as we have it as a real module, called bsd.destdir.mk.
The another important project was to extract the Perl code from bsd.port.mk into bsd.perl.mk to make it more flexible and better modularized. Each major functionality has a module in ports/Mk, but it hasn’t been the case with Perl thus far. Besides, there hasn’t been implemented a convenient way of version checking. As usual we wanted something like:
USE_PERL5= 5.8.0+
I implemented this syntax for the following knobs: USE_PERL5, USE_PERL5_RUN, USE_PERL5_BUILD, PERL_CONFIGURE and PERL_MODBUILD. With this change each Makefile looks simpler and they provide a consistent IGNORE message if no appropriate Perl version is available. While here, I sweeped the ports and removed the support for old Perl versions to make things even clearer. The big patch hasn’t been committed yet, portmgr@ is running some tests on the package building cluster, as this is a really heavy change and we should pay much attention when handling this case.
Summaryzing this summer, I have to admit that I could not work as intensively as I presaw, because I had private life issues at the beginning of the program. Despite, I think it was cool enough, and of course, I’m going to continue the work on the Ports infrastructure.
Ryan Woodings, Chief Geek at MetaGeek, LLC kindly donated a Wi-Spy 2.4x spectrum analyzer to me, thus allowing me to work on getting it supported in FreeBSD like I did with their earlier product. Thanks!
I must say, the Wi-Spy 2.4x simply rocks. It’s resolution is much better (3x) than that of 1st generation Wi-Spy and the external antenna is of course a nice addition as well. Below is a photo of my two Wi-Spys for comparison.
Here’s a screenshot of the current development version of spectrum-tools (formerly wispy-tools). The top graph is from my new Wi-Spy 2.4x, the bottom graph is from my 1st generation Wi-Spy – you can clearly see the improved resolution and amplitude range of the Wi-Spy 2.4x.
The yellow line is the current signal level, the green is the average signal level and the blue is the peak signal level.
My patch which adds support for the Wi-Spy 2.4x to the FreeBSD kernel can be found in usb/116057.
I just submitted my patch to remove calls (exec()ing) to basename/dirname in bsd.port.mk to GNATS. I didn’t time if this improves anything, but I assume doing a regex replacement in a make-variable uses less resources than doing a fork()&exec() or a system() call.
I don’t think this gives a huge improvement at all, it’s maybe even below the measurement threshold, but hey, why using external tools if the internal features are enough to do what you want? At least this patch is recorded now somewhere…
