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 -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
