lifetime failures (LF)

This morning at LCA Andrew Tanenbaum gave a talk about Minix 3 and his work on creating reliable software.

He cited examples of consumer electronics devices such as TVs that supposedly don't crash. However in the past I have power-cycled TVs after they didn't behave as desired (not sure if it was a software crash - but that seems like a reasonable possibility) and I have had a DVD player crash when dealing with damaged disks.

It seems to me that there are two reasons that TV and DVD failures aren't regarded as a serious problem. One is that there is hardly any state in such devices, and most of that is not often changed (long-term state such as frequencies used for station tuning is almost never written and therefore unlikely to be lost on a crash). The other is that the reboot time is reasonably short (generally less than two seconds). So when (not if) a TV or DVD player crashes the result is a service interruption of two seconds plus the time taken to get to the power point and no loss of important data. If this sort of thing happens less than once a month then it's likely that it won't register as a failure with someone who is used to rebooting their PC once a day!

Another example that was cited was cars. I have been wondering whether there are any crash situations for a car electronic system that could result in the engine stalling. Maybe sometimes when I try to start my car and it stalls it's really doing a warm-boot of the engine control system.

Later in his talk Andrew produced the results of killing some Minix system processes which show minimal interruption to service (killing an Ethernet device driver every two seconds decreased network performance by about 10%). He also described how some service state is stored so that it can be used if the service is restarted after a crash. Although he didn't explicitely mention it in his talk it seems that he has followed the minimal data loss plus fast recovery features that we are used to seeing in TVs and DVD players.

The design of Minix also has some good features for security. When a process issues a read request it will grant the filesystem driver access to the memory region that contains the read buffer - and nothing else. It seems likely that many types of kernel security bug that would compromise systems such as Linux would not be a serious problem on the HURD. Compromising a driver for a filesystem that is mounted nosuid and nodev would not allow any direct attacks on applications.

Every delegate of LCA was given a CD with Minix 3, I'll have to install it on one of my machines and play with it. I may put a public access Minux machine online at some time if there is interest.

Some ideas for running a conference

Firstly for smooth running of the presentations it would be ideal if laptops were provided for displaying all presentations (obviously this wouldn't work for live software demos but it would work well for the slide-show
presentations). Such laptops need to be tested with the presentation files that will be used for the talks (or pre-release versions that are produced in the same formats). It's a common problem that the laptops owned by the speakers will have problems connecting to the projectors used at the conference which can waste time and give a low quality display. Another common problem is that laptops owned by the conference often have different versions of the software used for the slides which renders them differently, the classic example of this is OpenOffice 1.x and 2.x which render presentations differently such that using the wrong one results in some text being off-screen.

The easy solution to this is for the conference organizers to provide laptops that have multiple boot options for different distributions. Any laptop manufactured in the last 8 years will have enough disk space for the
latest release of Debian and the last few Fedora releases. As such machines won't be on a public network there's no need to apply security updates and therefore a machine can be used at conferences in successive years, a 400MHz laptop with 384M of RAM is quite adequate for this purpose while also being so small that it will sell cheaply.

A slightly better solution would be to have laptops running Xen. It's not difficult to set up Xephyr in fullscreen mode to connect to a Xen image, you could have several Xen instances running with NFS file sharing so that the speaker could quickly test out several distributions to determine which one gives the best display of their notes. This would also allow speakers to bring their own Xen images.

This is especially important if you want to run lightning talks, when there is only 5 minutes allocated for a talk you can't afford to waste 2 minutes in setting up a presentation!

In other news Dean Wilson gave my talk yesterday a positive review.

LCA talk

This afternoon I gave a talk at the Debian mini-conf of LCA on security improvements that are needed in Debian, the notes are online here.

The talk didn't go quite as well as I had desired, I ended up covering most of the material in about half the allotted time and I could tell that the talk was too technical for many audience members (perhaps 1/4 of the audience lost interest). But the people who were interested asked good questions (and used the remainder of the time). Some of the people who are involved in serious Debian coding were interested (and I'll file a bug report based on information from one of them after making this post).

I believe that I was quite successful in my main aim of giving Debian developers ideas for improving the security of Debian. My second aim of educating the users about options that are available now (with some inconvenience) and will be available shortly in a more convenient form was partially successful.

The main content of my talk was based on the lightning talk I gave for OSDC, but was more detailed.

After my talk I spoke to Crispin Cowan from Novell about some of these issues. He agrees with me about the need for more capabilities which I take as a very positive sign.