[LWN Logo]

Date:	Mon, 8 Feb 1999 08:24:41 -0800
From:	David Miller <davem@twiddle.net>
To:	weejock@ferret.lmh.ox.ac.uk
Subject: Re: ioctl implementation on UltraPenguin?

   Date: Mon, 8 Feb 1999 16:04:07 +0000 (GMT)
   From: Matthew Kirkwood <weejock@ferret.lmh.ox.ac.uk>

   Could you remind me of the bug details, please?

Ask Sun, the refuse to give me details without signing a
non-disclosure agreement, and I cannot write an acceptable workaround
in the kernel without giving away the details (and thus breaking such
an NDA).

Sun's solution is to disable 64-bit user binary execution on the cpus
which have the hw bugs, and I don't want to do that.  But until I
reverse-engineer exactly what the bug is that you can trip from
userland in 64-bit mode, I have to accept the same fix...

Actually, there are two hardware bugs, I've figured out a little bit
about one of them:

1) In 64-bit mode

2) If you allow instructions to execute in the low or
   high 2GB of the address space.

3) The instruction sequence is something like:

   XXX
   call	. +/- some_huge_constant
   YYY

   Where XXX and/or YYY make a memory reference into
   the VA hole in the 64-bit address space (which should
   trap) and the call displacement causes the 64-bit PC to
   {under,over}flow, the cpu stops.

I believe the other hw bug which I know very little about also has
something to do with memory accesses to the VA hole.

If you're concerned, simply turn off CONFIG_BINFMT_ELF in the sparc64
kernel configuration, and you are not vulnerable.  This will be the
least of your problems wrt. existing UltraPenguin CDROMs out there, as
you can easily scan the linux-kernel list for vulnerabilities only
fixed in the last week or so, and thus the CDROM kernels are
subsceptable to.

(what I'm trying to say is, this isn't a "burn the CDROMs, oh my
 goodness!" issue, the 64-bit userland bug, because so there are so
 many other exploits possible which are not even sparc specific)

Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of the message to majordomo@vger.rutgers.edu