Ave du Mont Royal, Montréal.

Here’s an interesting blog entry: Are you afraid to blog? by Robert Scoble (found via Jim Grisanzio of Sun). It’s a must read for corporate bloggers, although it doesn’t really cover the area of personal blogging, unless perhaps you are trying to market yourself.

I’ve embarked on a few public personal blogs in the past and abandoned them all after a short time. I guess I felt as if I’d shared too much of my own life that was ultimately of no real interest to anyone else anyway. So yes, I guess I am afraid to blog to some extent, on a personal level.

On more general topics such as politics, it’s not that I don’t want to express myself (and I have), it’s more an issue of time and focus. Writing does not come easily to me, and I’m not able to breezily whip up sharp paragraphs on whatever thoughts happen to be lurking in my mind. To write about an issue, I would need to first be sure of my research, then spend significant amounts of time and energy trying to construct an articulate, well constructed essay. The end result is never great, but it’s usually something I can live with.

But this kind of writing takes away both time and energy that I’d rather currently spend on more technical tasks relating to kernel development and security. I’m continually amazed at how much smarter and more experienced the people around me are, both at Red Hat and in the FOSS communities. Dealing with people with such giant brains all day is a truly humbling experience. To a large extent, for the foreseeable future, I feel that I need to continue to focus on expanding technical skills and knowledge, gaining more experience. This means not doing some other things that also take up a lot of energy, including any really concerted attempt at writing.

So I’m not exactly sure what to expect from this blog. It won’t be too personal, nor will it likely be a vehicle for deep observations and pontifications. (Probably much to the relief of anyone reading this). I don’t really feel like being part of Red Hat marketing, although I can’t guarantee that I won’t mention work specific things that could be construed as such, perhaps correctly.

So what is left to discuss? It’s kind of like Amateur Radio, where the rules in some countries exclude discussions of any real interest. For example, in the US, the FCC rules include:

§97.117 International communications.

Transmissions to a different country, where permitted, shall be made in plain language and shall be limited to messages of a technical nature relating to tests, and, to remarks of a personal character for which, by reason of their unimportance, recourse to the public telecommunications service is not justified.

Well, hopefully it won’t be that bad.

I’ve just finished reading Secure Coding, Principles & Practices, by Graff and van Wyk. I thought it started out a little slowly but by the end of the book they did a really good job of pulling important high-level ideas together into a practical, systematic approach to development from a security point of view. The recommended reading list at the end of the book is good, and I was impressed that they listed my favourite security book first: Ross Anderson’s Security Engineering.

A Linux Journal article I wrote on SELinux and filesystems has been published online. Hopefully this will be useful to people looking for more information on SELinux, which I don’t think is really documented very well yet. One of the issues, I think, is that the people currently working on getting SELinux into shape for general consumption are currently too busy to do much in the way of documentation, general presentations etc. The article by Faye Coker still seems to the best general introduction to SELinux.

I’ve been playing with Jari Ruusu’s Pentium-optimized MD5 code (from loop-aes), looking to integrate it into the kernel Crypto API. The performance improvement looks impressive so far for IPsec. For loopback AH, the performance on my Xeon quadruples, from 10MB/s to 40MB/s. Jari’s code uses only i386 instructions, optimized for the Pentium II. I wonder how much more this could be optimized with instructions & techniques for newer CPUs. The performance improvement for loopback ESP with null encryption and MD5 authentication is about 18%, from 2.7MB/s to 3.2MB/s. I wonder what’s making ESP so slow to start with though. Clearly, ESP header processing is going to add overhead, but this still seems pretty bad. Hmmm.

Looks like we’ll finally have some optimized crypto in the kernel, having just received GPL licensing signoff from the original author of the i586 optimized AES code, Brian Gladman.

In addition to optimized ASM code (of which we need more), we also need support for hardware crypto. This requires a new asynchronous API and an overhaul of much calling code (e.g. IPSec). I presented on the topic at the recent Kernel Networking Summit in Oregon (slides).

For anyone interested in helping with development, there’s a new Crypto API mailing list. Some collected requirements can be found in this aging document.

Kernel disk encryption has been problematic: the cryptoloop code is buggy on journaled filesystems, has multiple security problems, and is unmaintained. The newer dm-crypt solution is technically superior, but as it is compatible with cryptoloop encryption, it also has the same security issues. Thankfully, noted cryptographer David Wagner has stepped in to help review the security of our existing code, and has offered to help review future development. Discussion of improved security for dm-crypt is happening on the dm-crypt mailing list.

Michael Halcrow of IBM gave a talk last week at OLS on disk encryption, reviewing existing schemes and then explaining how he plans to extend Cryptfs for use as a Linux desktop disk encryption system. The OLS proceedings don’t seem to be officially online yet but they should be soon (or ask around for a copy). The Cryptfs work looks promising, hopefully we’ll see it upstream soon.