OpenBSD Journal

g2k14: Ted Unangst on the Art of the Tedu

Contributed by tbert on from the less-is-more dept.

Ted Unangst (tedu@) talks about teduing a goodly amount of code, among other things:

Despite being in the same room as many other LibreSSL developers for the first time (since the beginning of LibreSSL at least), I didn't do too much work on that front. I did remove the compression feature (as made famous by the CRIME attack; not all protocols or deployments are vulnerable, but we're also aiming for a simpler feature set overall) and made a few other cleanups. While it's very helpful to be in the same room as other hackers to exchange ideas, having everyone pounding on the source at the same time is a little troublesome so I elected to stay out of the way.

I did, however, take the chance to bounce some ideas for a ressl API off the other developers. Instead of continuing to use the OpenSSL API, the ressl API is entirely separate. Internally, ressl itself uses the OpenSSL API, but the interface presented to the user is quite different. Our particular focus is on absolving the user of the need to know about X.509 and ASN.1 internals; instead you simply ask ressl to verify the remote peer's hostame. And actually, you don't even need to do that because that's the default behavior. (Un)fortunately, jsing@ liked the idea so much he ran ahead and implemented it before I got the chance. One of the dangers of being at a hackathon, I guess.

Besides that, I continued my hackathon tradition of deleting a lot code that most people probably never even knew existed. Say goodbye to asa, fpr, mkstr, xstr, oldrdist, fsplit, uyap, and bluetooth. Of these, you may possibly miss bluetooth support. Unfortunately, the current code doesn't work and isn't structured properly to encourage much future development.

I reviewed a few filesystem diffs from pelikan@ for ext2fs and tobias@ for msdosfs. At the beginning of the hackathon I showed some developers a diff that changes the buffer cache to using a 2Q like strategy. That's gone through a few iterations, but won't make 5.6. Expect to see it soon, though.

I made two changes to the kernel malloc(). The first was an idea deraadt@ had suggested some time ago. The current poison values (designed to detect use after free and other corruption) are rather limited, meaning that if a particular flag bit is set or unset, the incorrect code may continue to function. I change the poison values to inverted patterns, reversing all the bits. This proved to be very successful, finding many more bugs. Too successful, in fact, because there's not enough time to chase down and fix all the fallout before release, so that change has since been reverted.

The second change was to add a size argument to free(9). This is currently not used, as most callers pass 0 to indicate unknown, but will allow us to simplify some code on the free side and make some other fun changes as well.

For userland malloc(3), I did some work to accelerate threaded applications. I now have a stable first version of this ready, but it will wait for the next release as well.

(Comments are closed)

  1. By Puffy ( on

    Great work! It's too bad about the malloc() changes.

    Has there ever been a valid reason for delaying the 6-month release?

    1. By Philip Guenther ( on

      > Has there ever been a valid reason for delaying the 6-month release?

      Well, it almost happened that time we lost the second Theo clone** right before release lock and the third clone had some memory issues coming out of the freezer, but despite the testing and artwork running late the CD factory turned it around quickly enough that we still hit the November 1st target.

      ** was that one killed in the landslide or the one that the Wendigo ate? They all start to blur together...


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]