Kernel 3.4 and above support x32: https://sites.google.com/site/x32abi/ Pleas set CONFIG_X86_X32=y in config-x86_64-generic so that one can run x32 binaries under Fedora 18 kernel.
an x32 capable kernel alone isn't going to be much use. Unless there's buy-in from the glibc package maintainers, setting this isn't going to be much use. If an x32 libc is going to happen, we can re-evaluate this later for the kernel.
(In reply to comment #1) > an x32 capable kernel alone isn't going to be much use. Unless there's > buy-in from the glibc package maintainers, setting this isn't going to be > much use. > It is correct that you need user space support for x32 to compile x32 programs. However, enable x32 in kernel allows people to use Fedora 18 as a platform to do x32 work, which is independent of x32 user space support on Fedora.
It seems to me x32 support really should be going through the usual Fedora feature process. I believe I indicated this to HJ when he first inquired about x32 support in Fedora. Obviously if it's an approved feature, then glibc and the other tools will do what's necessary to support it. However, I don't see it on the F18 feature list: http://fedoraproject.org/wiki/Releases/18/FeatureList Information on the process itself can be found here: http://fedoraproject.org/wiki/Features/Policy HJ is right in that enabling the kernel makes it easier for those doing work on X32. The kernel folks might want to move forward on that independently of what happens in user space -- I certainly can't make that call. But without kernel bits there's no point at all in glibc x32 bits.
If x32 makes it through as an accepted feature we want to support, we can certainly do that work. My concern with just enabling the kernel, and calling it done is that it affects every user, by potentially exposing them to as-yet unfound security bugs, for zero gain.
moving to rawhide to re-target for F19, as the F18 feature process is already closed. HJ, filing a feature on that sooner rather than later would be better, as the window between releases is short.
Last time when x32 support issue came up, http://lists.fedoraproject.org/pipermail/devel/2012-May/167103.html I can understand the reluctance from Fedora community. Please note that I only request x32 support in kernel, not in user space. I am not asking for full x32 support in Fedora. Does setting CONFIG_X86_X32=y in config-x86_64-generic count as x32 support?
(In reply to comment #6) > Last time when x32 support issue came up, > > http://lists.fedoraproject.org/pipermail/devel/2012-May/167103.html Dave mentioned security concerns, which Jakub seems to address in that very thread: http://lists.fedoraproject.org/pipermail/devel/2012-May/167115.html > I can understand the reluctance from Fedora community. > Please note that I only request x32 support in kernel, not > in user space. I am not asking for full x32 support in > Fedora. Does setting CONFIG_X86_X32=y in config-x86_64-generic > count as x32 support? Yes. If it's enabled, it's essentially supported which is why we suggested a feature. The other suggestion in the thread you linked to is a secondary arch which is by far more work than a Feature. We are not enabling this in F18. Please work within the confines of the Fedora process.
(In reply to comment #7) > Dave mentioned security concerns, which Jakub seems to address in that very > thread: > > http://lists.fedoraproject.org/pipermail/devel/2012-May/167115.html In addition to this, it increases the potential attack surface for all users, 99.9% of which will never even use this feature unless we enable it for additional packages. If we are not doing a userspace for this, this is an unnecessary risk. If you're building your own libc, you can build your own kernel too.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Closing this. If a feature gets filed and approved by fesco, please open a new bug.
*** Bug 1091641 has been marked as a duplicate of this bug. ***
Fedora is supposed to be bleeding edge and a development platform. No one (sane) runs Fedora on mission critical systems. With the ~6/12 month upgrade cycle it doesn't even make a particularly good workstation distro -- way too much churn. That's why you're constantly upgrading to newer kernels instead of running 3+ year old stable kernels (like RHEL and other enterprise distros). Even though those newer kernels often regress. If you care about security to the insane level you seem to imply then you should not be compiling the vast majority of the kernel features/drivers that you do. The kernel attack surface is barely any larger with this (most of the system calls on x32 are the same as on x86_64, the rest usually pretty much just use the i686 emulation paths). The worry about less address randomization is probably true, but applies to i686 as well since both share a 32 bit address space. Furthermore address randomization worries don't matter so long as Fedora doesn't ship any x32 daemons/servers. I don't want to get Fedora to ship an x32 rebuild of everything (making it a full blown tri arch), ie. x32 packages for *everything*. However it would be nice if I could write and compile a C 'Hello World' program without having to jump through hoops and without having to recompile kernel/binutils/gcc/glibc. AFAICT, the kernel is a one line config change away from this. binutils support already appears to be present. gcc support is at least partially there (the compiler supports it, but core support libs are missing) afaict glibc is in the worse shape (although the code is there, just not built atm). However: it is much easier to install a cross-compiler toolchain on the side than it is to install a slightly modified kernel (simply because I don't need to ever upgrade the cross-compiler toolchain, while new kernel releases that would force me to rebuild the kernel come out once or twice a week).