MIT hackers generously lent us the use of the Green building tonight. It needs some of its pixels repaired, though!

There are more photos on Flickr.

So… how would this work? Presumably the computer would run some code that is not under the control of the user/owner of the machine, and protected by the TPM module. That code would then validate if the machine is free of malware or not – somehow. I have no idea how that could possibly be foolproof, but let’s assume for a moment there is a way to do this.

First problem: your computer would have to run code that most likely comes without source, is hard or impossible to inspect, and cannot be changed.

Let’s say for the sake of argument that this validation code is somehow optional. Or perhaps you are an enterprising person, and you’ve managed to kick this stuff off your computer (TPM-ectomy, anyone?). Next problem: now you can’t validate your computer with your ISP to prove that it is free of malware. To do that, you need access to the secret encryption key buried in the TPM.

This is called remote attestation: the machine(s) your computer communicates with can see information about your computer – say, what operating system you run, and what patch level – and because that data is signed or encrypted by your TPM chip, you can not change it.

Note that it’s already pretty easy for remote machines to see what (version of) an operating system a computer runs, for instance with TCP/IP fingerprinting, but that is easy to fake.

Remote attestation is the real danger of ‘trustworthy’ computing. They can try to put all sorts of things in the hardware; if people have physical access, someone will find a way around it. But if they make it impossible to network your computer without an operational TPM chip then we might as well kiss all our free software and free hardware goodbye. It won’t be any good to run a computer with GNU/Linux, if we can’t go online with it… Or if our online banking refuses to talk to our computer because our machine is not deemed to be running a fully patched version of Windows.

Given that this position paper comes from Microsoft, it’s not too hard to see where they want to go. Microsoft would love to be in a position where ISPs and banks require certain patchlevels of its software. Can you imagine a better way to force people to keep upgrading their Windows licenses? Or to force people to stop using free operating systems?

I have a better idea to combat the malware problem, mr. Charney. Why don’t we ask people to stop using Windows. Without Windows, the malware/botnet problem would not be nearly as bad as it is today.

Those boot sectors assume your iPod has one of the factory disks installed. I’ve got an old 4th gen iPod that I converted to compact flash after its disk died. It happens to have an 8G CF card in there.

Since I don’t do Windows, I downloaded the 20G 4th gen bootsector, put that on the iPod, and used fdisk to change the size of the FAT32 partition. And that worked fine.

Here’s the link to an ISO with the DRAC5 source:

http://opensource.dell.com/releases/drac5/1.60/

(link updated 2012/12/09, thanks sync0x!)

The two most serious problems were atrocious Intel video performance, and ongoing sound issues. Thankfully, the Intel issues have been addressed. Specifically, a really nice Troubleshooting Intel Performance document by Bryce Harrington has appeared. It lays out what is happening (in short: major driver refactoring), why it is affecting performance on some hardware, and specifically what to check and how to work around speed issues.

I ended up going back to the xserver-xorg-video-intel-2.4 package which fixes my main issue – really slow workspace switches. Looks like kernel and X.org fixes have already made it to Karmic Koala, but I’m happy to use the older driver until Karmic is released.

As for tor, Jaunty packages are now available so to install tor, just add

deb     http://mirror.noreply.org/pub/tor jaunty main
deb-src http://mirror.noreply.org/pub/tor jaunty main

to your

/etc/apt/sources.list

and apt-get install tor.

Finally – there’s a better way to reload the sound modules:

alsa force-reload

1. Tor is not packaged anymore, apparently there is no Ubuntu maintainer. Upstream provides Ubuntu packages, but they have no jaunty package yet. So, we need to build from the intrepid source package. Add

  deb-src http://mirror.noreply.org/pub/tor intrepid main

to your /etc/apt/sources.list, and

  apt-get update
  cd /usr/src
  apt-get build-dep tor
  apt-get source tor -b

2. Bug 270046: Apparmor *still* fights with cups-pdf. This one’s been around since the Hardy days. You’d think it would be fixed by now… Specifically, print jobs to the PDF printer will just vanish because apparmor does not allow cupsd to save them in ~/PDF. Solution: disable apparmor for cupsd:

  apparmor_parser -R /etc/apparmor.d/usr.sbin.cupsd
  /etc/init.d/apparmor restart

3. Bug 339555: Intel video is really really really really slow. Case in point: workspace switching takes seconds. (Partial) fix: upgrade to a experimental 2.6.30rc3 kernel. Even with that kernel, video performance on this GM965/GL960 based system is still not what it should be. To be continued, no doubt.

4. Bug 334657: Subpixel/Lcd mode with VRGB/VBGR makes fonts on qt4 applications unreadable. Really, really unreadable. Fix: use experimental patched qt4-x11 packages.

5. Sound has been an issue on this laptop from day one. It’s a Dell inspiron 1420N that shipped with Ubuntu preinstalled, but at the time a special Dell-supplied kernel was necessary to get working sound. The sound hardware is

$ lspci -vnn
00:1b.0 Audio device [0403]: Intel Corporation 82801H (ICH8 Family) HD Audio Controller [8086:284b] (rev 02)
	Subsystem: Dell Device [1028:01f3]
	Flags: bus master, fast devsel, latency 0, IRQ 21
	Memory at fe9fc000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: 
	Kernel driver in use: HDA Intel
	Kernel modules: snd-hda-intel
$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

First of all I had to add my user to the pulse-rt group – pulseaudio was complaining loudly about that in /var/log/syslog. That’s a Jaunty upgrade bug.

Secondly, for some reason I can not get sound to work until I unload the snd_hda_intel module and reload it. Sadly, that means closing all applications that are using the sound hardware – mpd, firefox, pidgin, the gnome volume control applet, etc. I don’t know what’s causing this, but I had the same problem on Intrepid after the last kernel upgrade. Again, to be continued.

The wrapping worked fine, but the Drupal cache really gets in the way sometimes. For instance, my legacy code does not use the drupal_set_message functions when a form submit fails. That means that the page that tells the user they made a mistake gets cached, leading to all sorts of unexpected results.

I looked around for a way to disable the Drupal cache for an entire module, but only found some results that didn’t quite do the trick. But then I stumbled across the CacheExclude module, which does exactly what I want. I didn’t want to include yet another module for something as simple as this, so just duplicated the ‘magic’ lines in my module:

function your_module_name_init() {
  // We don't want caching for this module
  if (drupal_match_path($_GET['q'],'url_of_your_module/*')) {
    $GLOBALS['conf']['cache'] = FALSE;
  }
}

In that snippet, you’ll want to change ‘url_of_your_module’ to a string unique to the path of your module. For instance, if your module lives a http://my.web.site/the-wrapped-module/, then you could put ‘the-wrapped-module’ in the place of ‘url_of_your_module’.

And that does the trick. Now, I’m by no means a Drupal expert, so there may well be a better way to do this. Feel free to leave a comment if you know how.

Affiliated Mortgage Protection
292 Terminal Ave W,
Clark, NJ- 7066.
(732)-499-0700

We answered five of their calls the past three weeks, and each time asked them to stop calling. Apparently, they happily ignore these requests.

They called again this evening and the lady on the phone had the nerve to say that she would have to put me on hold to get taken off their list, because I would have to talk to a supervisor. I hung up. We’re on the do not call list, so I filed a complaint.

Anyway – no more. I decided to let Asterisk deal with them:

; Affiliated Mortgages.
exten => XXXXXXXXXX,n,GotoIf($["${CALLERID(num)}" = "7324990700"]?Telemarketer)

; Telemarketers. Let it ring for 5 minutes and then hang up on them.
exten => XXXXXXXXXX,n(Telemarketer),Ringing
exten => XXXXXXXXXX,n,Wait(300)
exten => XXXXXXXXXX,n,Hangup

Make sure you have

[general]
unanswered = yes

in your cdr.conf if you want to log the call attempts from frustrated telemarketers

http://support.euro.dell.com/support/downloads/download.aspx?c=uk&l=en&s=gen&releaseid=R155882&formatcnt=2&libid=0&fileid=208066

Man – what a pile of crap. This thing is a self-extracting archive for rpm-based systems (redhat/suse). Fine – except that I run Debian on that machine. Anyway, you can run it with –extract to extract the contents:

./delldset_v1.4.0.8.bin --help


Command-line options for Dell System E-Support Tool (DSET)

Usage:  [options...]

Options:

-h,--help        : Display command-line usage help
-i,--install     : Install/upgrade the DSET application
-v,--version     : Display version information
--list           : Display contents of package (+)
--extract  : Extract files to specified path (+)

Using no options will display the interactive user
interface which will guide you through using DSET.

These contents are basically an rpm file and some support files:

-r-xr-xr-x  1 ward ward     4133 Apr  2  2007 Dell_License*
-r-xr-xr-x  1 ward ward     9909 May  8  2007 README*
-r-xr-xr-x  1 ward ward       58 May  8  2007 Version.txt*
-r-xr-xr-x  1 ward ward 15200341 May  9  2007 delldset-1.4.0-8.i386.rpm*
-rw-r--r--  1 ward ward 15187240 Oct 27 15:57 delldset_1.4.0-9_i386.deb
-r-xr-xr-x  1 ward ward    10271 Apr  2  2007 install.sh*
-r-xr-xr-x  1 ward ward      472 Apr  2  2007 sphelp.txt*
-r-xr-xr-x  1 ward ward       24 May  4  2005 test.sh*
-r-xr-xr-x  1 ward ward     9877 Apr  2  2007 utility.sh*

The rpm can be transformed into a .deb with alien:

$ alien delldset-1.4.0-8.i386.rpm 
Warning: Skipping conversion of scripts in package delldset: postinst postrm preinst prerm
Warning: Use the --scripts parameter to include the scripts.
delldset_1.4.0-9_i386.deb generated
$ alien delldset-1.4.0-8.i386.rpm --scripts
delldset_1.4.0-9_i386.deb generated

Which installs fine – but you really want to be using a kernel that has ipmi functionality compiled as modules; otherwise the package will not install properly until you add

hapi.allow.user.mode=yes

to /etc/omreg.cfg. In any case, you need to have ipmi as modules for the rest of this sequence of commands, so you might as well boot into a stock Debian kernel.

You’ll probably want to have installed Dell’s open manage before you run the DSET report. To do that, add

  deb ftp://ftp.sara.nl/pub/sara-omsa dell sara

to your /etc/apt/sources.list file and

  apt-get update
  apt-get install dellomsa

So, then you would be ready to run the dellsysteminfo command but WAIT – don’t do it yet. That script is dangerous. It does stuff like this, probing for the running services (from /opt/dell/dset/bin/dell-sysreport.sh):

#Dell: Extra OS stuff we want

echo "     Getting status of services ..." ${TEE2LOG}

#Dell: SuSE doesn't have a "service status" method so do it the manual way 
#catifexec "/sbin/service" "--status-all" 
 
rm -f $ROOT/service > /dev/null 2>&1 
 
SERVICEDIR=/etc/init.d 
 
#pushd ${SERVICEDIR} > /dev/null 
          for SERVICE in `ls -1 ${SERVICEDIR}` ; do 
 
            case "${SERVICE}" in 
#Skip over these "services" since they tend to hang some systems when requested for status 
              functions | halt | killall | single| linuxconf| kudzu | bgpd | boot | reboot | single | nscd | \ 
                  halt.* | rc | boot.* | *rpmorig | *rpmnew | *rpmsave | *~ | *.orig) 
      ;; 
              *) 
                if [ -x "${SERVICEDIR}/${SERVICE}" -a -f "${SERVICEDIR}/${SERVICE}" ]; then 
        echo "Service Name: ${SERVICE}" >> $ROOT/service 
                 /usr/bin/env -i LANG=$LANG PATH=$PATH TERM=$TERM "${SERVICEDIR}/${SERVICE}" status >> $ROOT/service 2>&1 
    echo >> $ROOT/service 
    echo "---------------------------------------------------------------------------" >> $ROOT/service 
               fi 
                ;; 
            esac 
          done 
#popd > /dev/null

That didn’t go over too well on my system – a bunch of things stopped working (like the ‘w’ command), samba started segfaulting, etc. It’s clearly calling some init scripts that don’t deal well with being asked for a status.

So I commented out that part of the script, which made things a lot happier – but of course services are now not mentioned in the report.

The other problem with the dset package is that it is riddled with calls to awk, sort, etc with absolute paths. Seriously, this is not 1995. You’ll need to fix tons of calls – just grep for ‘/bin/awk’, ‘/bin/grep’, ‘/bin/sort’ etc in /opt/dell/dset.

When all that’s done, you can generate the report

  dellsysteminfo

which will drop a zip file with a horribly long name (including the use of round brackets, sigh) in /root/ with the password ‘dell’. Awesome security guys. Why is there even a password if it’s so trivial?

The Dell tech I’m e-mailing with (who is very helpful btw, this post is not a criticism about Dell’s support people – only about their GNU/Linux tools) said I’d need to upgrade the system bios and the ‘ESM’, which is the ‘system firmware’. The former was easy with the help of this blog post. In a nutshell:

aptitude install libsmbios-bin libsmbios1 libsmbiosxml1
getSystemId

That will print out your ‘System ID’. Look up the latest system bios for that System ID at

http://linux.dell.com/repo/software/bios-hdrs/

and download it. Then

modprobe dell_rbu
dellBiosUpdate -u -f bios.hdr

and reboot, at which point your bios will be upgraded if all goes well. Note that if your cmos battery is dead, you can’t upgrade your bios anymore because all the command line tool does is load it into ram and flip a switch to tell the bios to upgrade itself on the next boot; without cmos battery either that switch or the bios in ram may not survive a reboot.

So that worked fine. The ESM update was a little trickier. I downloaded another .BIN file from

http://support.euro.dell.com/support/downloads/download.aspx?c=fr&l=fr&s=gen&releaseid=R147948&SystemID=PWE_PNT_2800&servicetag=8YGYQ1J&os=WNET&osl=fr&deviceid=5814&devlib=0&typecnt=0&vercnt=7&catid=-1&impid=-1&formatcnt=4&libid=29&fileid=196749

At least that thing didn’t try to do all sorts of rpm manipulations, it just runs a few scripts (again, you can verify with –extract).

The tricky thing here is that running the BIN file conflicts with the ipmi modules. Here’s what I did:

Boot into single user mode, and stop openmanage and ipmievd:

/etc/init.d/instsvcdrv stop
/etc/init.d/ipmievd stop

Then unload all ipmi modules:

rmmod ipmi_devintf
rmmod ipmi_si 
rmmod ipmi_msghandler

Then start screen, and start the .BIN file. It will look around, cause the ipmi modules to be loaded again and if all is well ask you if you really want to update your ESM, [Y/N].

At this point, break out of screen with ctrl-a d, and unload the ipmi modules again (I kid you not!):

rmmod ipmi_devintf
rmmod ipmi_si 
rmmod ipmi_msghandler

Now return to screen

screen -r

and press ‘Y’. Don’t worry, it’s going to load the ipmi modules yet again, and then starts printing dots on the screen as the upgrade progresses. It takes a while – at least 5 minutes on my system. So just wait until it is done.

Eventually the script said ‘update complete’. I read this trick with screen and the unloading of the ipmi modules somewhere on a dell wiki, but I can’t find the link now (sorry!) so I can’t give credit.

Anyway, and I was able to verify the upgrade with ipmitool (I upgraded to firmware revision 1.72):

# ipmitool -I open mc info
Device ID                 : 32
Device Revision           : 0
Firmware Revision         : 1.72
IPMI Version              : 1.5
Manufacturer ID           : 674
Manufacturer Name         : Unknown (0x2a2)
Product ID                : 0 (0x0000)
Device Available          : yes
Provides Device SDRs      : yes
Additional Device Support :
    Sensor Device
    SDR Repository Device
    SEL Device
    FRU Inventory Device
    IPMB Event Receiver
    Chassis Device
Aux Firmware Rev Info     :
    0x00
    0x00
    0x00
    0x00

So in the end I got almost everything to work (except for the dset output which is still partially missing). But seriously, this was way harder than it should be.

That DSET package is a total mess and needs some serious reworking.

The system bios upgrade procedure is elegant and simple – there Dell deserves credit.

The ESM upgrade… not so much. Seriously – what’s up with those ipmi modules getting in the way twice?

In a nutshell, I’d like Dell to hire some people to clean up the GNU/Linux tools they provide. But they have to be people who know about more than just rpm-based distros, and who are interested in truly cross-distribution solutions and want to work with all (popular) distributions. Basically, if Dell can get their tools into Debian, Fedora and OpenSuse, things will trickle down to almost every other popular flavor of GNU/Linux. There is a lot of work to do…