[8525] in bugtraq

home help back first fref pref prev next nref lref last post

Re: [Fwd: NOTE: Solaris 7 gotcha for some ultras]

daemon@ATHENA.MIT.EDU (Solar Designer)
Fri Nov 13 11:28:07 1998

Date: 	Fri, 13 Nov 1998 12:01:34 +0300
Reply-To: Solar Designer <solar@FALSE.COM>
From: Solar Designer <solar@FALSE.COM>
X-To:         alan@LXORGUK.UKUU.ORG.UK
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  <m0zdgQn-0007UEC@the-village.bc.nu> from "Alan Cox" at Nov 11,
              98 07:59:54 pm

Disclaimer: Everything I'm saying below is pure speculation. I'll appreciate
any corrections.

> If they worked around it I'd be more impressed, if they shipped replacement
> CPU's I'd be even more impressed still. The ultrasparc was advertised as
> a 64bit CPU, people did buy them on that basis.

This brings me to a question: what's so special about the 64-bit mode in
the kernel that makes this bug exploitable? It's a user space instruction
that crashes the system, right? We were able to use 64-bit operations on
Solaris 2.5 (well, I did on a 2.5.1) with hand-written assembly. (Top 32
bits of some of the registers were getting lost at context switches.)

So, I see two possibilities: either the bug is in fact still exploitable
in 32-bit mode, too (but possibly not by a C source), or it is related to
one of the following:

1. Full 64-bit virtual addresses.
2. Register windows.
3. Are there any other possibilities?

It is entirely possible that I'm missing something here. It would be nice
if someone from Sun could clarify which property of the 64-bit support in
the kernel makes this bug unexploitable.

Signed,
Solar Designer

home help back first fref pref prev next nref lref last post