lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 11 Sep 2008 16:07:36 +1000
From: Curtis Maloney <cmaloney@...dgate.net>
To: Florian Weimer <fw@...eb.enyo.de>
Cc: Theo de Raadt <deraadt@....openbsd.org>,
	B 650 <dunc.on.usenet@...glemail.com>, bugtraq@...urityfocus.com
Subject: Re: Sun M-class hardware denial of service

Florian Weimer wrote:
> * Theo de Raadt:
>> Management eventually has to decide to impact the SLA's of all domains.
>> That means that Sun's promise of isolation is bunk.
> 
> I don't want to downplay your frustration, but the pattern is fairly
> common: When someone tries to port a new operating system to some
> partitioning system, it's not totally unheard of that the new code takes
> down (parts of) the sytem beyond the assigned partition.

Something that seems to be being missed is that it doesn't matter HOW the 
problem was found, NO domain usage (be it application or OS ) should be able 
to impact the uptime of the other partitions.

>> How absolutely bizzare.  Basically you spend half a million dollars on
>> Sun hardware, and it isn't required to do this better than VMWare?
> 
> I think you've got it exactly backwards: you don't let non-trusted
> people run code on these machines because they are so expensive.

The point of the partitioning is that you can isolate semi-trusted usage so 
it won't cause downtime for other semi-trusted users.  The fact it
(a) marks the hardware as unusable
(b) doesn't let the system admin override/correct that
(c) requires _all_ hardware to be power cycled, not just the effected parts
is the problem.  If (b) or (c) were fixed, I think the issue wouldn't be.

-- 
Curtis Maloney
cmaloney@...dgate.net

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ