Bug 854317 - Please set CONFIG_X86_X32 to y
Summary: Please set CONFIG_X86_X32 to y
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 19
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1091641 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-04 15:42 UTC by H.J. Lu
Modified: 2014-04-27 21:14 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-05 19:37:40 UTC


Attachments (Terms of Use)

Description H.J. Lu 2012-09-04 15:42:11 UTC
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.

Comment 1 Dave Jones 2012-09-04 17:31:10 UTC
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.

Comment 2 H.J. Lu 2012-09-04 17:42:45 UTC
(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.

Comment 3 Jeff Law 2012-09-04 17:46:38 UTC
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.

Comment 4 Dave Jones 2012-09-04 18:09:46 UTC
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.

Comment 5 Dave Jones 2012-09-04 18:47:59 UTC
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.

Comment 6 H.J. Lu 2012-09-04 19:36:06 UTC
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?

Comment 7 Josh Boyer 2012-09-04 19:46:15 UTC
(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.

Comment 8 Dave Jones 2012-09-04 21:17:23 UTC
(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.

Comment 9 Fedora End Of Life 2013-04-03 15:40:46 UTC
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

Comment 10 Justin M. Forbes 2013-04-05 19:37:40 UTC
Closing this. If a feature gets filed and approved by fesco, please open a new bug.

Comment 11 Josh Boyer 2014-04-27 00:20:38 UTC
*** Bug 1091641 has been marked as a duplicate of this bug. ***

Comment 12 Maciej Żenczykowski 2014-04-27 21:14:57 UTC
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).


Note You need to log in before you can comment on or make changes to this bug.