On 30 Sep 2003, Michael Uhler wrote:
> > Well, I think this is OK -- 64-bit opcodes are generally useless for
> > software built for the o32 ABI, so they should not normally happen in
> > regular code. Perhaps some fancy hand-coded assembly might try to use
> > them to get unusual results, including an invalid opcode trap handler for
> > the processors that do not support them at all. But I don't think we
> > should try to work hard to prevent broken software from shooting into its
> > foot.
> I'm not a real fan of architecting software to dismiss broken (or rogue)
> programs since it tends to open up a whole lot of holes that cause
> O/S crashes. For instance, an o32 program should never be able to pass
> a non-sign-extended value thru a GPR to the O/S in a system call. How
> many places in the O/S implicitly assume this is true? The architecture
That actually we get right -- the arguments at the stack are obviously
32-bit and the ones in argument registers are explicitly sign-extended
from their 32 LSBs in our syscall prologue for o32 syscalls.
> was never intended to run real 32-bit programs with 64-bit ops enabled,
> and I would strongly urge you not to do this now.
After a bit of thinking, I consider this not to be a real problem. Apart
from the kernel interface, which sanitizes values passed, the rest is pure
userland, where allowing undefined operation with 64-bit opcodes cannot
really hurt. Of course running a buggy or malicious program may lead to
bad results or loss of data, but it'll be limited to the user responsible
for running such software and the root user by definition has to know what
he is doing and specifically he is responsible for not running untrusted
software on critical systems.
That said, I don't really have a strong preference either way -- it just
doesn't seem to be worth the hassle for me to explicitly defend against
such a marginal case. Although it may be good to try validating this
assumption with `crashme'.
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail: email@example.com, PGP key available +