linux-kernel - Realistically possible to run a IA64 big-endian process using PSR.be register?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Thu, 25 Jun 2009 11:38:22 -0400
From:	Andrew Paprocki <andrew@...iboo.com>
To:	LKML <linux-kernel@...r.kernel.org>
Subject: Realistically possible to run a IA64 big-endian process using PSR.be 
	register?

I'm just wondering if anyone has tried to run a long-lived big-endian
process on IA64 by setting the PSR.be bit from user space. As an
example, it appears that OpenSSL md5 code uses this register to switch
endian modes at runtime, but it does so only for some computation code
that doesn't make any syscalls.

According to http://www.kernel.org/doc/Documentation/ia64/fsys.txt:
"PSR.be
        Cleared when entering fsys-mode.  A srlz.d instruction is used
        to ensure the CPU is in little-endian mode before the first
        load/store instruction is executed.  PSR.be is normally NOT
        restored upon return from an fsys-mode handler.  In other
        words, user-level code must not rely on PSR.be being preserved
        across a system call."

Can the library calls be wrapped to ensure any data handling is
performed and the bit is set after they return?

Disclaimer: Please don't hit me. :) I understand this is ugly, but I'm
just looking to see if we can experiment with this and if anyone has
attempted it before. The code can not be reliably made endian neutral
in any reasonable time frame.

Thanks,
-Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/