
Lots of bugs in 32-bit x86 Linux entry code - swills
https://lwn.net/ml/oss-security/CALCETrW1z0gCLFJz-1Jwj_wcT3+axXkP_wOCxY8JkbSLzV80GA@mail.gmail.com/
======
geofft
Relatedly, Ubuntu no longer builds for i386 as a complete architecture:
[https://lists.ubuntu.com/archives/ubuntu-devel-
announce/2019...](https://lists.ubuntu.com/archives/ubuntu-devel-
announce/2019-June/001261.html)

They are still building i386 packages for use on 64-bit kernels, for the sake
of precompiled 32-bit software (games etc). That's scenario B from Simon
McVittie's reply in this thread, and it sounds like that's not affected.

~~~
yingw787
I was able to upgrade from Lubuntu 16.04 to 18.04 for my 32bit IBM Thinkpad
T42 using do_release_upgrade. It’s not downloadable on the website, but I
think for 18.04 the build is still there.

~~~
geofft
I think they've stopped building them in 19.10. 18.04 is an LTS supported for
5 years, so users of i386-only CPUs are fine until 2023.

~~~
mavhc
I have a load of 32bit laptops, "I'll put ChromiumOS on them", nope, that's
not a thing any more. OK, err Linux? Apparently not. Could put Windows 10 on
them I guess.

~~~
bildung
You could try Debian, which is essentially Ubuntu minus some themes. I doubt
Debian will drop i386 support soon (I just searched and couldn't find hints of
an end of support of i386)

~~~
yencabulator
But then you'll have all these kernel bugs.

~~~
bildung
What do you mean?

------
jdsully
I remember being an early adopter of 64-bit Linux with my Athlon64 back in the
day. Lots of stuff was broken and I got a lot of debate on whether it was any
faster or worthwhile at all. It's really cool to see the technology curve go
full circle.

~~~
cptskippy
Completely off topic but...

Althlon64 was a swift kick in the nuts for Intel, but AMD really didn't
followup until Ryzen. I wonder if they're going to stick around and fight this
time.

~~~
kbenson
Sometimes when the swift kick in the nuts is delivered to an 800-pound
gorilla, it doesn't matter if you stay around to fight, you're outclassed.

This time, AMD may have stepped up with a steel pipe. We'll see how well they
can use it...

~~~
lsofzz
> This time, AMD may have stepped up with a steel pipe. We'll see how well
> they can use it...

:-))))

------
jhoechtl
Hah!

> And the developers in question should have an appropriate degree of
> nostalgic adoration of segments, gates, and other delights from the i386
> era.

------
skissane
> We need real CI resources

It would be easy to boot the 32-bit kernel in a VM as part of a CI pipeline
and then run some automated tests to catch issues like this.

(Unless by "real" he means non-virtualised? Is there anything about these bugs
that would only reproduce on bare metal?)

~~~
TD-Linux
I think the issue is not the hardware needed but simply the cost of the extra
compute. Linux doesn't have an "official" CI server but relies on third
parties running it, and none of them want to spend $ on compute for an
architecture they will never use.

~~~
amluto
The hardware cost should be negligible. The relevant cost is labor.

------
cpeterso
"I strongly suspect that there is at least one bug left."

:)

~~~
saagarjha
That probably would be a valid addition to any bug fix in a large project, to
be honest.

------
human_banana
Maybe because nobody uses 32-bit x86 anymore?

~~~
bryanlarsen
No, that's the i386 architecture, which is still well supported AFAICT. x86_32
is a funny architecture that requires 64 bit chips but uses 32 bit pointers.

[http://www.h-online.com/open/features/Kernel-Log-x32-ABI-
get...](http://www.h-online.com/open/features/Kernel-Log-x32-ABI-gets-
around-64-bit-drawbacks-1342061.html)

~~~
acqq
No, see the source from Linux kernel:

[https://github.com/torvalds/linux/blob/master/arch/x86/Kconf...](https://github.com/torvalds/linux/blob/master/arch/x86/Kconfig)

For all x86 processors, now there is a name "X86_32" which "depends on !64BIT"
(i.e. 64BIT flag has to be off).

and there is a name "X86_64" which "depends on 64BIT" (i.e. 64BIT flag being
on).

Under new convention X86 is a common prefix for both 32 and 64-bit kernels for
x86 processors, and the suffix _32 means the kernel uses only 32bit
instructions, and _64 that it uses 64bit instructions.

And also, there's handling of an old arch name "i386" which is recognized to
mean 64BIT is off and if only "x86" is seen as arch name then there is a
prompt that asks 64BIT yes or no. It also notes that the old name used for
kernel with 64BIT off was "i386" and the old name used for kernel with 64BIT
on was "x86_64".

Finally, the support for X32 ABI (allowing running executables which use
64-bit instructions but only "short" 32bit pointers in 64-bit kernel
[https://en.wikipedia.org/wiki/X32_ABI](https://en.wikipedia.org/wiki/X32_ABI))
is enabled in my 64-bit distro:

    
    
        ~$ sudo grep -P G_X86_X?\\d{2}= /boot/config-$(uname -r)
        CONFIG_X86_64=y
        CONFIG_X86_X32=y
    

The first line means this is a 64bit kernel for x86 processors, the second
that X32 support is enabled on that kernel.

In short, there are two kinds of X86 kernels:

X86_32 -- formerly known as i386

X86_64 -- formerly known as x86_64

and an option for existence of X32 ABI in X86_64 called CONFIG_X86_X32.

~~~
xelxebar
Beatuiful, high-value reply. Thank you for making the connection to upstream
and unpacking things with good, concise exposition.

------
sockalocka
Edit: I am possibly wrong here, and confusing this with an issue that was
reported earlier

------
dang
Url changed from
[https://lwn.net/Articles/805539/](https://lwn.net/Articles/805539/), which
points to this.

Submitted title was "Essentially no upstream development resources dedicated
to x86_32 Linux"

~~~
swills
Thank you!

------
Ericson2314
Oh, the freeloading. How much more CI do we need...

