Discussion:
i386: Geode LX and NOPL
(too old to reply)
James Addison
2023-05-20 08:30:01 UTC
Permalink
Hi folks,

I don't think that I should file this as a Debian bugreport, because
it's not a problem that I've experienced with Debian.

And I don't think that it's appropriate to write to Debian developers
directly about it yet, because I haven't been able to test the results
of what I'm curious about here.

However: my understanding is that the Geode LX is basically an i686
CPU that lacks one instruction (a 'no operation' - noop - called
NOPL). There's a long and entertaining writeup about that here:
https://www.jookia.org/wiki/Nopl

It's an unusual CPU and didn't see wide consumer adoption except
within the OLPC (One Laptop Per Child) project, where it was used for
two of the early laptop models (XO 1.0 and XO 1.5).

Recently, Intel has begun proposing some security improvements for
i686 that make use of the NOPL instruction -- and that, I think, could
cause support for the Geode LX to fall away from many Linux operating
systems because there's a fair and very reasonable argument that
adding security features for the majority of users outweighs
supporting an old and unusual CPU.

However, to get to the point after that lengthy context: there is a
patch available on the Linux kernel mailing list that adds emulation
of NOPL instructions at the kernel level. I would be curious to know
whether anyone has tried that - I intend to, after finding some
hardware that includes a Geode LX. The patch is found at:

https://lore.kernel.org/all/20210626130313.1283485-1-***@orca.pet/

(note: it's unclear to me whether the NOPL emulation only works for
the Linux kernel itself, or whether it extends to enabling programs
that run on the system (aka userspace binaries) that contain NOPL
instructions to run. _if_ kernel-level NOPL emulation allows both the
kernel _and_ those programs to run correctly, then I think it could be
a neat way to provide the security properties of Intel CET on most
i686 hardware, while still also allowing OLPC laptops to run the same
software (albeit with slightly reduced security properties))

Thanks (and I'll try to remember to update this thread with any findings),
James
Charles Curley
2023-05-20 13:50:01 UTC
Permalink
On Sat, 20 May 2023 09:07:57 +0100
Post by James Addison
Hi folks,
I don't think that I should file this as a Debian bugreport, because
it's not a problem that I've experienced with Debian.
And I don't think that it's appropriate to write to Debian developers
directly about it yet, because I haven't been able to test the results
of what I'm curious about here.
However: my understanding is that the Geode LX is basically an i686
CPU that lacks one instruction (a 'no operation' - noop - called
https://www.jookia.org/wiki/Nopl
It's an unusual CPU and didn't see wide consumer adoption except
within the OLPC (One Laptop Per Child) project, where it was used for
two of the early laptop models (XO 1.0 and XO 1.5).
I have four FIT-PC 1s (https://en.wikipedia.org/wiki/Fit-PC,
https://linux-hardware.org/?probe=c256a73072). Two are in daily use
with Bullseye, the other two are spares I have upgraded to Bookworm to
test that. They run Geodes. It has been problematic for X support, and
the kernel has only supported the temperature sensors recently.
Post by James Addison
Recently, Intel has begun proposing some security improvements for
i686 that make use of the NOPL instruction -- and that, I think, could
cause support for the Geode LX to fall away from many Linux operating
systems because there's a fair and very reasonable argument that
adding security features for the majority of users outweighs
supporting an old and unusual CPU.
However, to get to the point after that lengthy context: there is a
patch available on the Linux kernel mailing list that adds emulation
of NOPL instructions at the kernel level. I would be curious to know
whether anyone has tried that - I intend to, after finding some
I have not. I was unaware of it until I read your email. I have no
great interest in trying it.
Post by James Addison
(note: it's unclear to me whether the NOPL emulation only works for
the Linux kernel itself, or whether it extends to enabling programs
that run on the system (aka userspace binaries) that contain NOPL
instructions to run. _if_ kernel-level NOPL emulation allows both the
kernel _and_ those programs to run correctly, then I think it could be
a neat way to provide the security properties of Intel CET on most
i686 hardware, while still also allowing OLPC laptops to run the same
software (albeit with slightly reduced security properties))
Thanks (and I'll try to remember to update this thread with any
findings), James
The FIT-PC is hard wired to 256MB of RAM, some of which is dedicated to
video RAM. Getting Bullseye installed on that was an interesting
struggle. I do not intend to try it with Bookworm. I plan to upgrade
the remaining two Bullseye machines to Bookworm once that is released.

I will then start looking for replacements for the FIT-PCs, possibly
with RISC-V processor(s). The lack of RAM is one reason. The FIT-PCs
are painfully slow for interactive use, even without X. Those two
concerns may be specific to the FIT-PC and not apply to other Geode
computers.

Also, and of greatest concern, Linux support for the i686 architecture
is waning. Not just the kernel, but userland programs as well. As that
support wanes, less and less testing will make the i686 architecture
less secure and less stable. This will accelerate the process of
abandoning i686.


***@freeman:~# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 10
model name : Geode(TM) Integrated Processor by AMD PCS
stepping : 2
cpu MHz : 499.879
cache size : 128 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow cpuid 3dnowprefetch vmmcall
bugs : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
bogomips : 999.75
clflush size : 32
cache_alignment : 32
address sizes : 32 bits physical, 32 bits virtual
power management:

***@freeman:~#
--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/
Stefan Monnier
2023-05-20 14:40:01 UTC
Permalink
Post by James Addison
Recently, Intel has begun proposing some security improvements for
i686 that make use of the NOPL instruction -- and that, I think, could
cause support for the Geode LX to fall away from many Linux operating
systems because there's a fair and very reasonable argument that
adding security features for the majority of users outweighs
supporting an old and unusual CPU.
The `i386` port of Debian is basically dedicated to old machines (the
newer machines are expected to use the `amd64` port), so I suspect the
"works on old machines" argument will tend to prevail.

This said, as Charles points out, support for some old machines is
slowly eroding due to the slowly increasing RAM requirements. Not sure
how many GeodesLX machines are sufficiently beefy to run
Bookworm acceptably.

I was still able to use Debian on a (headless, armhf) 512MB machine
without too much suffering two years ago, but I suspect that less than
that might be impractical.


Stefan
Greg Wooledge
2023-05-20 15:30:01 UTC
Permalink
Post by Stefan Monnier
I was still able to use Debian on a (headless, armhf) 512MB machine
without too much suffering two years ago, but I suspect that less than
that might be impractical.
Depends on what you plan to use it for. That amount of RAM would be
unacceptable for a desktop environment running one of the major web
browsers, but it might be perfectly fine for, say, a DNS server. Maybe
even overkill.
Stefan Monnier
2023-05-20 16:30:01 UTC
Permalink
Post by Greg Wooledge
Post by Stefan Monnier
I was still able to use Debian on a (headless, armhf) 512MB machine
without too much suffering two years ago, but I suspect that less than
that might be impractical.
Depends on what you plan to use it for. That amount of RAM would be
unacceptable for a desktop environment running one of the major web
browsers, but it might be perfectly fine for, say, a DNS server. Maybe
even overkill.
For the day-to-day operation, you're probably right (512MB was plenty
for most of the services that machine offered).
"impractical" was referring to running APT, mostly, tho it may also
depend on how many packages you have installed.


Stefan

Loading...