> Not really - what I am not doing is trying to beat up a firmware > problem that whilst being quite bad can be mitigated by using native > features of Solaris. Too bad if OpenBSD cannot do the same - I am not > really sure about the benefits of OpenBSD on that scale of hardware > anyway considering the lack of kernel threading and the parlous state > of userland threading. I don't think you get it. OpenBSD doesn't care a whit about this. They stumbled upon it as the result of bringing up OpenBSD on such a machine. No - currently I wouldn't run OpenBSD on an M-class box either, other than for development purposes. but that's not really the point is it. Nobody except you is saying this problem has anything to do with running OpenBSD on a machine. The point is anyone with a black hat with sufficient clue enough to ignore this sort of ass-covering nonsense and write a kernel module, and go look at what the OpenBSD kernel *does* to wedge the zone, and make a solaris kernel module that does the same. At which point, at a minimum, the same wedging becomes possible from solaris, so yes, this is breaking separation. You're saying "well golly gee, but it's still separation if you don't let the attacker load kernel modules." good on you. have fun with your attacker, may you meet one of competence level greater than a script kiddie someday. I have, they're nice guys. and smart. smarter than me in a lot of things :) Personally if I'm buying gear to drink the whole virtualization kool-aid - the kool-aid has to work - meaning stuff done in the guest OS should never be able to do stuff like this. -Bob
