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
| ||
|
Date: Wed, 12 Dec 2018 09:12:34 +0000 From: Steven Newbury <steve@...wbury.org.uk> To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, macro@...ux-mips.org, tg@...bsd.de, luto@...nel.org, arnd@...db.de, dalias@...c.org, s@...oud.org, catalin.marinas@....com, fweimer@...hat.com, glaubitz@...sik.fu-berlin.de, christian.brauner@...onical.com, hjl.tools@...il.com, hpa@...or.com Subject: Re: Can we drop upstream Linux x32 support? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 First off I'd like to request: Please don't break my userspace! I have a number of systems running with x32-abi as native. They work well, I've no want or desire to upgrade their memory or CPUs to make keep them working as well as they do now. Let alone the hassle of having to redeploy with a completely different ABI. I've been working on getting as much userspace as I can working with x32 since it first became somewhat usable, I've sent patches upstream and pushed to encourage projects to write portable code. Sometimes that has meant just little tweaks to build systems, or sometimes disabling asm where I consider it isn't worth the effort of making it work. For other projects I've converted the asm or even in some cases got the JIT working, mozjs17 for example. So I'm both a user and a developer. Breaking support for x32 would be really bad for me, but if I'm the only one using it I suppose I can't really justify it being kept on that basis. I know CERN has sucessfully experimented with it over the years though, so I wouldn't be surprised if there are other users hiding out there. I can't help but wonder if it wouldn't make more sense to drop x86 support from long mode than x32. AMD64 x86 support was always intended as a compatibility feature, I very much doubt there are more people out there using an x86 native userspace on a 64 bit kernel than there are native x32 users. x86 support could be implemented via KVM and/or qemu-user. There is no reason to keep the extra complexity in the kernel for what is effectively an emulation layer anyway. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEWa1B4K0Hk12RDstE+lAa6BzrmeAFAlwQ0QQACgkQ+lAa6Bzr meBILQf9EF1GqHKfnRC7AOFnNCm0235OmH1dJJd4+6zzLWTKGAAvFF6T1F1IG3fu QTZTEok5s238BapjrvgZ5bxtMP0TGNK++vGZ8ESb6Hi+Q975duemWD8ZsSVPw7SH YcqEgmxKn28iHq/W//SUPo1kqz7D0jFCDU9dIA1wQY+AwTIzjfMPltWGrKbMbOBQ LsW+VlL7PfoEzx9sXvaMpjgINEouCvLcuTvhTRclCOO5MWqTQLdIdL9urrBGukUN 7dvKiWWAk6c/Af1W5jnLtYIijaztu3hrZ7lykFmOnwyDoeOhqzIhUkcDaLJcy7Vo Rsrb1CjzFngpbgTJeOkyC9ZGZ2CZ0g== =TCpw -----END PGP SIGNATURE-----
Powered by blists - more mailing lists