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]
Message-ID: <76366b180906250838x36a82aaexe89caa2db48d4386@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ