Wandering Thoughts archives

Why free things are so attractive in universities

I've seen a number of people saying that universities who took advantage of ipsCA's offer of free SSL certificates for educational institutions are now getting their money's worth, and that it clearly would have been better to pay a real SSL CA vendor for real certificates. Would that it were so simple.

The real attraction of the free ipsCA certificates here (and likely at other universities) was not that they saved you $40 US or so. Their real attraction was that you could get them without bureaucracy.

Spending actual money on SSL certificates would have raised a horde of questions that had to be answered. Who was the best and cheapest vendor? Did we really need a proper SSL certificate for this purpose, or could we either live without SSL or use a self-signed certificate (or even create a local CA)? What budget category and area paid for this certificate, and who had to authorize it? If this service costs $40, is it actually worth it (and can you convince the authorizer of that)?

Getting an ipsCA certificate took one sysadmin ten minutes. It was no contest. And of course we wound up getting more certificates because we didn't have to cost-justify them. A proper certificate for our inbound MX so that even cautious people could do TLS-encrypted ESMTP? Sure, why not, it's free.

This applies to far more than SSL certificates. It is the universal attraction of free stuff at universities, because spending money (even quite trivial amounts of money) can take huge amounts of effort, annoyance, and time. Naturally, things that let you avoid all of this are very attractive.

(In theory the staff time and effort required to spend money acts to drastically raise the real cost of small purchases. In practice, universities generally consider staff time to be free.)

There is an immediate corollary to this for people who want to offer free stuff to universities. The important thing is not that it is free, it is that it requires no bureaucracy; free is a necessary but not sufficient condition for this. A free thing that requires the departmental chair to sign an official agreement that must be inspected by a university lawyer might as well cost a thousand dollars, for all the interest that you're likely to see from us.

Things that limit the performance of hardware acceleration

Suppose that you have an infinitely fast hardware accelerator, one that can compute something of interest in no time at all. What external issues limit the total performance advantage that you can get by putting this hardware accelerator in a system?

I can think of the following limiters:

• main memory speed limits, the latency and bandwidth limits of system RAM. This limits how fast you can interact with system memory.

• the speed limits of the underlying hardware that you're talking to, if you are. For example, hardware RAID cannot go faster (over the long term) than the speed of the underlying disks, and anything that talks to a network is limited by the network's latency and bandwidth constraints.

• the setup and transaction costs for passing commands and data between you and the CPU. For instance, how many PCI reads and writes does it take to tell your hardware acceleration to do something, or to determine its status?

  (When thinking about this, it's important to also consider the speed impacts of any necessary memory barriers.)

• some sorts of interrupts, and in general any need for CPU involvement and decisions in your actions. Having to wait for CPU involvement is effectively a pipeline stall in your processing, with all of what you'd expect from that.

  (Interrupts are not necessarily a performance limit by themselves, since they may just be notification to the CPU that it can pay attention to you. They generally will incur transaction costs, though.)

My impression is that a lot of the increasing sophistication of hardware in general has been driven by reducing the transaction costs of operations, starting with DMA and moving upwards from there. There once was a day when the OS poked a bunch of control registers for each operation; these days, the OS writes all of that information to control blocks in memory, then pokes the hardware once to point it at the control blocks.

The advantages of open source software RAID

In light of a recent entry, I feel like singing the praises of software RAID, especially open source software RAID. For the moment, let's set aside the performance and cost issues of software RAID versus hardware RAID, because it's honestly not what I really care most about.

Software RAID in general has two major advantages:

• much more of what is going on is exposed, instead of being locked away inside a black box. For example, you are guaranteed to see the raw disk status and error messages if something starts to go wrong, and often you can directly inspect system state with the tools of your choice.

• it is not tied to having specific hardware. If you can bring your OS up on something that you can plug your disks into, you can get at your data again.

The alternate phrasing of the second advantage is that hardware RAID is portable across operating systems while software RAID is portable across hardware. In practice, the second is vastly more important to most people than the former.

The further advantage of open source software RAID is that you can actually look into things to find out what's going on, and you may be able to do something about any problems that you run into. (In short, it's even more open to inspection than ordinary software RAID.)

In theory, it's possible for hardware RAID to be almost as open and as inspectable as software RAID. In practice, I don't think I've ever seen hardware RAID come close; the degree of openness required seems to be foreign to hardware RAID companies, who often barely document the interface to their cards much less things like RAID storage formats.

All of this matters because every RAID implementation has historically had bugs; the only question is when you find out about them and how much you can do about it. Hardware RAID and closed software RAID is saying 'trust us, we got it right this time and all of our stuff just works'. The positive side of my Linux software RAID situation is that if I want to, I actually can instrument the kernel, get full reports about everything going on, and so on, which is a lot more than I'd get with hardware RAID.

Secure or useful: pick one

A great deal of time, pragmatic security involves striking a balance between actual security and usefulness. The more secure you are, the less useful you are; the more useful you are, the less secure. Here, I am taking a broad view of 'useful', one that encompasses not just things like features but also how easy your system is to use, and how much the security gets in the way.

(Sometimes, very rarely, this is not the case. When this happens, celebrate and take full advantage of it.)

There is no single right answer to where to strike this balance; you have to make a tradeoff based on your environment, your risk factors, and so on.

For example, the consider the tradeoffs involved in having shared filesystems and common logins across a group of somewhat disparate machines. Users really like this and it makes your environment much easier for them to use, but it drastically increases the worst-case results of a compromise, especially if you are cautious about security; with everything in one security domain, you have to assume that all of the machines are compromised if any of them is.

So, do you use shared filesystems and common logins, or do you isolate machines and force users to copy things around by hand (probably typing one-time passwords in each time)? Clearly it depends. In many environments, you share and probably are less paranoid when a compromise happens; you tilt towards usefulness and away from absolute security. In some environments, things are sufficiently important that you isolate and protect very strongly, tilting the balance the other way.

(Bearing in mind that security is people, you need to be careful not to wind up being so useless that people work around your security in order to get things done.)