In Episode 1 all the droids were shut down by the failure of 1 system. That seems like a failure to implement the LCM principle...

I find that LCM is the Least Intuitive Principle. I think the reason for this is that when most people these days think of a shared mechanism, they think of shared libraries, and I believe the principle doesn't apply to them.

Yes, writing a large number of support libraries has the potential of introducing bugs, but having everyone roll their own seems even more error prone. For example, the JPEG vulnerability had a lot of impact, but we were able to eliminate them in a fairly short amount of time. If a well-tested and widely used component has bugs, can you imagine how many more vulnerabilities there would be in the hundreds of home-brewed JPEG implementations?

The principle text talks about something else, though. First, it mentionsshared data & resources as channels for information flow — something notably absent from shared libraries. The second example in fact advocates writing shared libraries instead of a privileged service used by everyone. I still have trouble wrapping my head around that one, since if there's something in your system that could be implemented as a user library, even if you do provide a privileged implementation of it, there's nothing forcing your users from switching.

So really, I think the principle (or at least its second part) is saying that you want to design your system so that few mechanisms require privilege, but that's not the image evoked by the phrase "LCM."

Maybe "keep the TCB small" is what they are driving at. When there's a choice of whether something goes in the TCB prefer the option where it doesn't.

Nikita,

I'm with you that this is a hard one, and think your analysis is good. Would you dump it if you could re-do the list? There's already least priv.

Anon,

TCB post-dates Saltzer and Schroeder, so that's cheatin'.