Re: Sun M-class hardware denial of service

> 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 consideri

Re: Sun M-class hardware denial of service

> > > 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. > >

Re: Sun M-class hardware denial of service

On Sun, Sep 28, 2008 at 08:53:10PM -0600, Theo de Raadt wrote: > > Oh you can avoid the problem by using only the vendor recommended > configurations! > Yes. > Or so you think. A Solaris kernel module could trigger exactly the > same bug. > Uh duh. You need to read a bit closer - you realis

Re: Sun M-class hardware denial of service

On Sun, Sep 28, 2008 at 08:36:17PM -0600, Theo de Raadt wrote: > > Oh I get it. > No you don't. > You can use a "trust relationship with your > administrators" to get around the fact that Sun sold a piece of > hardware which does not provide the isolation they promised in their > white papers a

Re: Sun M-class hardware denial of service

On Sun, Sep 28, 2008 at 08:14:35PM -0600, Theo de Raadt wrote: > > OpenBSD of course cannot run in a Solaris zone. > Right. Glad that is clear. > OpenBSD can run in a hardware zone, and when something it does (which > we don't know yet) locks up that hardware zone, the only way to get > the ha

Re: Sun M-class hardware denial of service

On Sun, Sep 28, 2008 at 07:53:11PM -0600, Theo de Raadt wrote: > > Apparently you just plain can't understand simple english. > and apparently you cannot read the whole message - I said "too bad if OpenBSD cannot do this"... > If you put someone running OpenBSD into a zone, and that zone locks

Re: Sun M-class hardware denial of service

> > Oh I get it. > > > > No you don't. > > > You can use a "trust relationship with your > > administrators" to get around the fact that Sun sold a piece of > > hardware which does not provide the isolation they promised in their > > white papers and documentation. > > > > It is a bug. What y

Re: Sun M-class hardware denial of service

> On Sun, Sep 28, 2008 at 08:14:35PM -0600, Theo de Raadt wrote: > > > > OpenBSD of course cannot run in a Solaris zone. > > > > Right. Glad that is clear. > > > OpenBSD can run in a hardware zone, and when something it does (which > > we don't know yet) locks up that hardware zone, the only w

Re: Sun M-class hardware denial of service

On Sun, Sep 28, 2008 at 08:14:16AM -0600, Theo de Raadt wrote: > > the only workaround is to buy a seperate machine for the other uses. > No. > So you buy a machine that can be split up into different machines, and > guess what, you still have to buy extra ones because it doesn't > work. > Un

Re: Sun M-class hardware denial of service

> On Sun, Sep 28, 2008 at 08:14:16AM -0600, Theo de Raadt wrote: > > > > the only workaround is to buy a seperate machine for the other uses. > > > > No. > > > So you buy a machine that can be split up into different machines, and > > guess what, you still have to buy extra ones because it does

Re: Sun M-class hardware denial of service

> and apparently you cannot read the whole message - I said "too bad if > OpenBSD cannot do this"... > > > If you put someone running OpenBSD into a zone, and that zone locks up > > completely and cannot be reset because of a flaw Sun has now admitted, > > then if you NEED that zone back, you have

Re: Sun M-class hardware denial of service

* Theo de Raadt: >> On the other hand, I generally prefer a "trust me, I know what I'm >> doing" switch on the systems I deal with. It's really frustrating if a >> system tries to protect itself from me, and consequently fails to comply >> with the actual requirements in this situation. > > As we

Re: Sun M-class hardware denial of service

> On the other hand, I generally prefer a "trust me, I know what I'm > doing" switch on the systems I deal with. It's really frustrating if a > system tries to protect itself from me, and consequently fails to comply > with the actual requirements in this situation. As well, note that a power-off

Re: Sun M-class hardware denial of service

* Theo de Raadt: > Oh I get it. You can use a "trust relationship with your > administrators" to get around the fact that Sun sold a piece of > hardware which does not provide the isolation they promised in their > white papers and documentation. Quoting from

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 s

Re: Sun M-class hardware denial of service

On Wed, Sep 10, 2008 at 09:01:05PM +0200, Florian Weimer wrote: > > > 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 c

Re: Sun M-class hardware denial of service

... ciao: : on "9-9-2008" "B 650" writ: : I think it's a bit of a leap to call this a DoS vulnerability. : The power cycle of the remainder of the frame can be done at your leisure which, convenient if nothing else, still has to be done. so, at some point, "all" 'mission critical applicatio

Re: Sun M-class hardware denial of service

* Theo de Raadt: > That is WRONG. The long-term uptime of all other domains on the > machine are eventually impacted because the entire physical machine > must, after a service call to Sun, eventually be powered down. > > Management eventually has to decide to impact the SLA's of all domains. > T

Re: Sun M-class hardware denial of service

> > Yet you don't know what it is that causes the issue? What's Sun's > support arrangement for OpenBSD on SPARC? If it is reproduced in > Solaris, then I'm sure Sun would address it, but where is the benefit > for them to do so at present? It's not about OpenBSD on sparc - the OpenBSD

Re: Sun M-class hardware denial of service

- Original Message - From: "Theo de Raadt" <[EMAIL PROTECTED]> To: "B 650" <[EMAIL PROTECTED]> Cc: Sent: Tuesday, September 09, 2008 4:27 PM Subject: Re: Sun M-class hardware denial of service You stated in your original message that this

RE: Sun M-class hardware denial of service

> From: Theo de Raadt [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 09 September, 2008 17:28 > To: B 650 > Cc: bugtraq@securityfocus.com > > > I apologise if I'm misunderstanding you, but it seems to me that this > > issue can only be initiated by a privileged user on a domain. > > If one domain c

Re: Sun M-class hardware denial of service

> I apologise if I'm misunderstanding you, but it seems to me that this > issue can only be initiated by a privileged user on a domain. If one domain can be broken into, and a Solaris kernel module is loaded which then crashes that one domain, the entire machine eventually has to be powered off to

Re: Sun M-class hardware denial of service

On Tue, Sep 9, 2008 at 8:42 PM, Theo de Raadt <[EMAIL PROTECTED]> wrote: >> While having to power cycle the remainder of the frame may be a pain, the >> fact it isolates the fault to only power off the affected domain suggests to >> me that it is working as designed (the relative virtue of the desi

Re: Sun M-class hardware denial of service

> While having to power cycle the remainder of the frame may be a pain, the > fact it isolates the fault to only power off the affected domain suggests to > me that it is working as designed (the relative virtue of the design not up > for debate). The power cycle of the remainder of the frame can

Re: Sun M-class hardware denial of service

I think it's a bit of a leap to call this a DoS vulnerability. While having to power cycle the remainder of the frame may be a pain, the fact it isolates the fault to only power off the affected domain suggests to me that it is working as designed (the relative virtue of the design not up for deba