Moving to no-multilib

depontius · Advocate Joined: 05 May 2004 Posts: 3509

This is more on my ongoing game of musical motherboards...

I'm converting a deskside into a server. First I did a full update. Then I looked at @world and started removing stuff, doing a --depclean every so often. At some point I remembered that this is supposed to be a server, and switched the profile to "default/linux/amd64/17.1/hardened (stable)". The next emerge gave me some problems, but between some more removals, some USE flag adjustments, etc, I again got clean updates. (including --depclean) So I also started installing server-related code, and so far all is going well.

Then I remembered that a lot of people don't like multilib. I can certainly see that it increases the attack surface, at the very least. So I started looking into getting rid of it. Some time back I had some ABI_X86 issues while doing updates, so in /etc/portage/make.conf I have ABI_X86="32 64". Looks like multilib to me. I know that there's a separate no-multilib profile - "default/linux/amd64/17.1/no-multilib/hardened (stable)", but figured I'd first see what it looked like if I tried just using ABI_X86="64" on a pretend emerge. Many packages would install, but then I start getting all sorts of conflicts, all focused around ABI_X86.

A few of those packages were mesa and llvm, along with things involved with them. (I have USE="X" so that I can have GUI code, but I don't run an X server on this machine.) When I start trying to focus on a few individual things, like just mesa and perhaps a few other programs with ABI_X86="64" I get hate-mail, but it indicates that they will be rebuilt that way.

MAYBE I could just walk through the process this way. First do the easy stuff, then start doing sets of packages. But I have a bad feeling that it could leave me halfway up the creek without a paddle. By the way, "--backtrack=100" didn't help.

Does switching to a no-multilib profile make a difference beyond ABI_X86? I figured I'd look at the "easy part" first.
_________________
.sigs waste space and bandwidth

NeddySeagoon · Posted: Sun Sep 13, 2020 11:27 pm Post subject:

depontius,

If you don't actually install any 32 bit only code, only your toolchain will remain 32 bit capable.
/no-multilib/ has a different on disk layout to mulltlib. Multilib has to keep the 64 bit and 32 bit files of the same name apart.

As the 32 bit code won't be used, is it worth the work to convert?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

depontius · Advocate Joined: 05 May 2004 Posts: 3509

Thank you for that view.

I presume that the difference for no-multilib is just a reduced attack surface, so I don't see the disk layout as being a big issue.

This makes me think that I can get rid of the 32-bit code in an iterative fashion, largely as I've been describing.
_________________
.sigs waste space and bandwidth

Ionen · Developer Joined: 06 Dec 2018 Posts: 2804

Nowadays, for 17.1, layout is pretty much identical actually. 17.1 no-multilib amd64 will still have a separate lib64 and a non-symlink lib, only difference is that lib will almost only be populated by python stuff, some gcc stuff, kernel modules, etc... rather than 32bit libraries.

I guess this is to make it "possible" to switch to back&forth, although if have any reason to think may want to, don't do no-multilib anyway

I only use it for servers myself where I also disabled support in the kernel (or if low flash storage + no build deps binpkg-using box). But only real difference I see is that no-multilib allows you to lack 32bit glibc, while you're forced to keep it on multilib regardless of ABI_X86=

figueroa · Posted: Mon Sep 14, 2020 3:12 am Post subject:

I don't think your make.conf ABI_X86="32 64" is doing what you think. I am running multilib, I don't have ABI_X86= in make.conf and emerge --info shows ABI_X86="64".
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi

Anon-E-moose · Posted: Mon Sep 14, 2020 9:53 am Post subject:

ABI_X86 affects some things, and changing the profile (which sets multilib on gcc and glibc, apart from the ABI flag), and there's a multilib flag.

I changed (a while back) from multilib to straight 64 bit, when I gave up on wine. I just don't remember the whole process, not painful, but some things will require rebuilding, gcc, glibc, and any other program that creates 32 bit libs/progs. First thing I did was resolve the ABI stuff, which still leaves some packages there, gcc, glibc, etc, and then swapped out the profile (or maybe I turned off the multilib USE flag first then swapped profile, I don't remember).
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

Anon-E-moose · Posted: Mon Sep 14, 2020 9:54 am Post subject:

NeddySeagoon · Posted: Mon Sep 14, 2020 10:37 am Post subject:

Ionen,

Its not possible to switch from no-multilib to multilib as the no-multilib toolchain in the stage3 is built with (-no-multilib).
That means all the code to build 32 bit binaries is missing, so its not possible to build gcc, glibc and friends with 32 bit support.
The switch the other way has been done, I'm sure I saw it on the forums a long time ago.

For completeness, nothing is impossible on Gentoo.
The switch from no-multilib to multilib requires an atomic replacement of the toolchain. I think that's been done too. :)
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Ionen · Developer Joined: 06 Dec 2018 Posts: 2804

Yeah that's why I used quotes around "possible", I didn't mean it's intended or straight forward. But the directory structure at least shouldn't need any migration as it is now if done anyway.

ff11 · l33t Joined: 10 Mar 2014 Posts: 664

mv · Watchman Joined: 20 Apr 2005 Posts: 6779

Anon-E-moose · Posted: Mon Sep 14, 2020 5:30 pm Post subject:

The reason for me going to no-multilib was just getting rid of the 32 bit libs (once I quit using wine) as they were of no use to me, saves space, save emerge time (on those multilib packages), and gets rid of the annoying (at times) cry of you need some ABI_X86 set a certain way when emerging.

As far as attack surface, 32bit libs are no more or less prone than the 64bit libs.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

mike155 · Posted: Mon Sep 14, 2020 7:15 pm Post subject:

Hu · Administrator Joined: 06 Mar 2007 Posts: 22422

depontius · Advocate Joined: 05 May 2004 Posts: 3509

I'll agree that the attack surface argument is a small one, but it's an increment.

As for progress, this morning I recompiled everything that would go simply to 64-bit only, and I'm stuck with (at least) these.

Hu · Administrator Joined: 06 Mar 2007 Posts: 22422

If they're all part of the same set, what happens if you tell Portage to rebuild all of them as pure 64-bit in a single call to emerge? Usually, circular requirements like this only cause a problem if you try to rebuild only part of the circle, and Portage gets stuck that the part you didn't allow it to rebuild would become unsatisfied.

Etal · Veteran Joined: 15 Jul 2005 Posts: 1932

Hu · Administrator Joined: 06 Mar 2007 Posts: 22422

The newest of those is around 10 years old, and all 4 of them are about kernel bugs in IA32 emulation. Switching to no-multilib is necessary before disabling kernel support for IA32 emulation, but switching to no-multilib, on its own, would not have protected against those. The administrator must take the additional step of rebuilding the kernel without IA32 emulation.

Anon-E-moose · Posted: Mon Sep 14, 2020 10:27 pm Post subject:

depontius · Advocate Joined: 05 May 2004 Posts: 3509

pietinger · Posted: Tue Sep 15, 2020 8:52 am Post subject:

ff11 · l33t Joined: 10 Mar 2014 Posts: 664

Hu · Administrator Joined: 06 Mar 2007 Posts: 22422

Note that both Flatpak and AppImage achieve their "ease" by failing to integrate with the system, and instead bundling everything the wrapped application will need. This means redundant, and potentially outdated / unmaintained / insecure, copies of libraries will be present and used by the wrapped application.

ff11 · l33t Joined: 10 Mar 2014 Posts: 664

depontius · Advocate Joined: 05 May 2004 Posts: 3509

In the current case, it's all pure Gentoo. No flatpak or appimage or anything else like that. Oh, a couple of overlays, but I think they may be hangovers from deskside days. I need to root them out and see about getting rid of them.

After making sure I was up to date this morning, I did another emerge with "-multilib" and nothing changed.

I may try the no-multilib/hardened profile, if only temporarily, to see if it calls for changes.
_________________
.sigs waste space and bandwidth