Re: 64bit port

Re: 64bit port

[David Miller]

   Date: Sat, 1 May 1999 11:11:21 +0100 (GMT)
   From: Alex Buell <alex.buell@tahallah.demon.co.uk>

   Ie. on loading of a binary could quickly scan it for illegal
   sequences and overwrite with NOPs, then execute it. Of course, this
   doesn't cater for things that does J-I-T compilation & execution
   though.

You roughly have described how we hope to work around it.

IRIX does something very similar to work around cpu lockup
bugs on early MIPS r4k parts.

Later,
David S. Miller
davem@redhat.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: 64bit port

[David Miller]

   From: hpa@transmeta.com (H. Peter Anvin)
   Date: 	1 May 1999 09:39:27 GMT

   I think that was only UltraSPARC I.

Not true.

All currently shipping UltraSparc's have at least one of the two
64-bit lockup bugs.  On the Ultra-I the user can do it no matter where
the text section is mapped, this is why Solaris doesn't offer 64-bit
installation by default on the < 250Mhz Ultra-I's which are the chips
affected by this first bug.

All UltraSparc chips (to my knowledge) are effected by the second hw
bug, which can only be triggered if the user can execute code in the
top of low 2GB of the 64-bit address space (it involves doing a PC
relative call which over/under-flows the program counter across the
64-bit top/bottom addresses, while doing an access into the VA space
hole in the delay slot, or something like this, I don't know the exact
trigger sequence yet).  This is why Solaris-7 does not allow 64-bit
userspace to map anything in these areas in 64-bit mode, which as a
side-effect makes the medium-low code model close to useless.

When Jakub and I get the 64-bit userland bootstrapped, I'll start
running crashme to learn what the exact instruction sequences are so
we have a chance at coding a more suitable workaround than what
Solaris has chosen.

Later,
David S. Miller
davem@redhat.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/