Profile 17.0

[jagdpanther]

Does it matter if I recompile my kernel using the new gentoo profile 17 (ie. -pie) before or after I reubild my system with ' emerge -e @world' ??

[NeddySeagoon]

jagdpanther

No. The kernel rebuild can be any time after the gcc rebuild.
I'm not sure it matters as the kernel build system sets all its own CFLAGS.
Therefore, the kernel may not change.

[jagdpanther]

NeddySeagoon:

> No. The kernel rebuild can be any time after the gcc rebuild.

Thanks.

I ask because I read a comment about an issue with virtuabox-modules after the writer upgraded to gentoo profile 17 but before he re-compiled his kernel. (I use three 'extra' kernel module packages: virtualbox-modules, vmware-modules and nvidia-drivers and am trying to minimize issues with the large 'emerge -e @world')

[NeddySeagoon]

jagdpanther,

That's a different question.
You must update the kernel before you update modules that build against it.

Update kernel
emerge @module-rebuild

[Fitzcarraldo]

is there a flag that will tell portage to exclude all the already-reinstalled packages?

No, but you can try something along the lines of

Code: Select all

emerge -1 $(eix-installed-after -btF /usr/bin/gcc)

I found that the above-mentioned eix-installed-after command did not exclude the already re-installed packages, so I did the following instead, which did exclude the already-installed packages:

Code: Select all

# eix-installed-after -btF /usr/bin/gcc | sort > before-gcc
# eix-installed-after -tF /usr/bin/gcc | sort > after-gcc
# diff -U $(wc -l < before-gcc) before-gcc after-gcc | sed -n 's/^-//p' > diff-list
# tail -n +2 diff-list > merge-list
# emerge -1 --keep-going $(cat merge-list)

[Ant P.]

Longer answer: the kernel both is and isn't PIE code - it's very position-dependent because CPU interrupt vectors and BIOS interfaces live at fixed positions in low memory. It *also* has to be position-independent because everything newer than a 386 has the concept of plug and play, where devices and their reserved addresses can come and go outside of the kernel's control, and it has to navigate around those. It doesn't use GCC's normal flags for that reason.

[dmpogo]

The question remains "How slow is compiling with pie?". It seems very slow but I did not have a benchmark to compare to other than the total emerge -e world time. Since the last time I did a world emerge was at least two portage versions and one minor gcc version back, that's not a data point, just a concern.

In another thread I had compared some phoronix benchmarks against this system versus published ryzen 7 results. I could rerun them and see if they had changed.

Another approach is to compare compile times for one or more packages using measured times between this system on profile 17.0 and my profile 13.0 Phenom II system by turning off three cores and limiting the CPU multiplier. That still wouldn't account for the other system having twice the RAM unless I benchmarked builds that don't use swap on either system.

I'll do some research and report my findings in a new thread on Gentoo Chat.

Thanks, would be interesting to see the numbers. I may do a check as well, if I find the time. But, without hard numbers, compilation of gcc itself seemed notably slower.
I have new i7 Skylake laptop with 16 GB RAM and just installed gcc-6.4.0 with 13.0 profile couple of weeks ago, and did notice notable delay. Recompile gcc yesterday with 17.0 profile, and it took lwhat seemed like 45 minutes. Again, I did not time it, but was just coming back again expecting it to finish long time ago, and it did not.
On my old 2007 core 2 duo desktop, it took over 1 hour, and I left before it finished.

Anyway, that needs to be checked, this was just a feel on my side.

[BitJam]

I recently did a system upgrade. Quad core to octa core, 8 Gig to 32 Gig, faster sata. This pretty much canceled out the pie degradation so the compile time for gcc was almost the same.

[dmpogo]

I recently did a system upgrade. Quad core to octa core, 8 Gig to 32 Gig, faster sata. This pretty much canceled out the pie degradation so the compile time for gcc was almost the same.

Sounds like bad news for people with fixed hardware to support

[Fitzcarraldo]

On my Clevo W230SS laptop (Intel Core i7-4810MQ CPU @ 2.80GHz and 16GB RAM) the output of the command 'genlop -t gcc' before and after migration from the 13.0 plasma profile to the 17.0 plasma profile doesn't show much difference in merge times.

Code: Select all

# uname -a
Linux clevow230ss 4.12.12-gentoo #2 SMP Sat Dec 2 04:20:45 GMT 2017 x86_64 Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz GenuineIntel GNU/Linux
# grep MemTotal /proc/meminfo
MemTotal:       16346168 kB
# eselect profile list | grep plasma | grep -v systemd
  [6]   default/linux/amd64/13.0/desktop/plasma
  [18]  default/linux/amd64/17.0/desktop/plasma *

Code: Select all

    Wed Nov 22 01:36:07 2017 >>> sys-devel/gcc-6.4.0
       merge time: 32 minutes and 4 seconds.   <------ Merge time using gcc-5.4.0-r3 and 13.0 profile

     Fri Dec  1 02:34:10 2017 >>> sys-devel/gcc-6.4.0
       merge time: 32 minutes and 35 seconds.  <------ Merge time using gcc-6.4.0 and 17.0 profile

     Fri Dec  1 17:39:01 2017 >>> sys-devel/gcc-6.4.0
       merge time: 31 minutes and 15 seconds.  <------ Merge time using gcc-6.4.0 and 17.0 profile

     Sat Dec  2 02:54:37 2017 >>> sys-devel/gcc-6.4.0
       merge time: 32 minutes and 22 seconds.  <------ Merge time using gcc-6.4.0 and 17.0 profile

[mv]

Code: Select all

emerge -1 $(eix-installed-after -btF /usr/bin/gcc)

I found that the above-mentioned eix-installed-after command did not exclude the already re-installed packages

It excludes everything which was (re)emerged after the timestamp of /usr/bin/gcc.
This timestamp is usually the timestamp when gcc-config was used last time. If you did use this after the installation of gcc, you should probably use another file for reference (or you can omit the -F and specify sys-devel/gcc:7.2.0 (use your slot number) instead, or -l sys-devel/gcc-7.2.0 (use your version number)).

Code: Select all

# eix-installed-after -btF /usr/bin/gcc | sort > before-gcc
# eix-installed-after -tF /usr/bin/gcc | sort > after-gcc

It would be serious a bug in the eix-installed-after script (or of the stat utility) if the intersection of these files contains anything (unless something changed the timestamp of /usr/bin/gcc or the /var/db database between the two calls). If you can reproduce this, please report an eix bug.

BTW, to find the intersection of two sorted files you can use

Code: Select all

comm -12 file1 file2

or for unsorted files also

Code: Select all

commlist -2 file1 "" file2

(commlist is in dev-util/mv_perl in the mv overlay).

[slackline]

No need to if you're already on 7.2.

Thanks for the reply, do you mean I can just select the new profile and then emerge -e @world or do I still need to compile sys-devel/binutils and sys-libs/glibc (already done up to emergeing sys-devel/libtool).

Sorry for the dumb quesiton, just not clear to me what it is I've no need to do.

Sorry, the news item was originally written when gcc-7.2 was still without keywords.

If you're already on 7.2, just replace 6.4.0 with 7.2.0 everywhere in the instructions. You still need to follow the whole procedure though to be 100% sure that everything works.

That said... On a typical system, the fallout from not rebuilding world may be rather small. Many of the developers who tested the 17.0 profiles did no rebuilds at all, and ended up only with a few random build failures at some point later. Then again, the devs recognize the errors that result (I hope), can fix them (I hope) and do not file invalid bugs about it (I hope)...

Proceeded with re-emerging world and a couple of packages didn't build, some rebuilt again on trying others didn't those that didn't are detailed in bug reports as follows...

#621848 dev-libs/klibc
#636420 games-puzzle/pingus
#639776 xfce4-extra/xfce4-diskperf-plugin
#638634 sys-apps/raidutils (although as noted this appears to be dead upstream, can't recall ever using it myself so have removed it)

I use the no-multilib profile...

Code: Select all

# eselect profile list
Available profile symlink targets:
  [1]   default/linux/amd64/13.0
  [2]   default/linux/amd64/13.0/selinux
  [3]   default/linux/amd64/13.0/desktop
  [4]   default/linux/amd64/13.0/desktop/gnome
  [5]   default/linux/amd64/13.0/desktop/gnome/systemd
  [6]   default/linux/amd64/13.0/desktop/plasma
  [7]   default/linux/amd64/13.0/desktop/plasma/systemd
  [8]   default/linux/amd64/13.0/developer
  [9]   default/linux/amd64/13.0/no-multilib
  [10]  default/linux/amd64/13.0/systemd
  [11]  default/linux/amd64/13.0/x32
  [12]  default/linux/amd64/17.0
  [13]  default/linux/amd64/17.0/selinux
  [14]  default/linux/amd64/17.0/hardened
  [15]  default/linux/amd64/17.0/desktop
  [16]  default/linux/amd64/17.0/desktop/gnome
  [17]  default/linux/amd64/17.0/desktop/gnome/systemd
  [18]  default/linux/amd64/17.0/desktop/plasma
  [19]  default/linux/amd64/17.0/desktop/plasma/systemd
  [20]  default/linux/amd64/17.0/developer
  [21]  default/linux/amd64/17.0/no-multilib *
  [22]  default/linux/amd64/17.0/systemd
  [23]  default/linux/amd64/17.0/x32
  [24]  hardened/linux/amd64
  [25]  hardened/linux/amd64/selinux
  [26]  hardened/linux/amd64/no-multilib
  [27]  hardened/linux/amd64/no-multilib/selinux
  [28]  hardened/linux/amd64/x32
  [29]  hardened/linux/musl/amd64
  [30]  hardened/linux/musl/amd64/x32
  [31]  default/linux/uclibc/amd64
  [32]  hardened/linux/uclibc/amd64

...and have rebuilt the kernel, I do use an initramfs which if I've understood correctly uses the minimal libc that dev-libs/klibc provides, and whilst I rebuilt the initramfs as part of rebuilding the kernel I'm holding back on rebooting the system until such time as I've rebuild dev-libs/klibc at which point I'll regenerate the initramfs.

Thanks to all who've worked hard on this, can't be easy making such a large change and I imagine a lot of work and testing has gone on in the background.

slackline

[pablo_supertux]

@klynastor: Do you think you will be even able to measure this performance difference?

On an x86 system, one should be able to measure it. On an amd64 system, it should be rather hard to construct an example where one can measure any difference.

I've finished recompiling all my ~1300 packages, that was a long marathon. You say in amd64 it should be rather hard to construct an example that makes any difference. Perhaps I'm just imaging it, but I do have the feeling, that the system has become a little bit slower than usual. Let's see how it feels after a couple of days.

[Wallsandfences]

for me it's mono that doesn't build...

[proteusx]

So profile 17.0 necessitates that I should move to GCC 6 with PIE,
rebuild the whole @world, which will invariably break my system,
and possibly make it slower, just to "improve the overall security finger print" (sic).
Lots of pain for little or no gain.
It seems to me that I need this profile change like I need a hole in my forehead.

[Spargeltarzan]

@proteusx: For me the "just to improve the overall security fingerprint" is now something what I don't have to care manually about any more. Thank you Gentoo As someone wrote already in this thread, within an amd64 system you will most likely notice no difference regarding performance. If you are afraid it will, or you don't want pie generally, force no-pie.

To activate this setting, Gentoo had to think which option most users will probably want - in my point of view this was the right decision.

When you are afraid your world rebuild will break your system, you have now got a nice chance to clean things up - the result of the world emerge will proof you did a good job.

[eccerr0r]

So what's the guidance on x86 systems that need all the performance they can get?

Recently I've found building gcc-6.4 to be miserable, ~6+ hours on an Atom-1.6GHz (x86 only) dual thread. Though this is not related to PIC but all of the slower machines, invariably x86, will hurt even more when they're slower to begin with.

I might have to migrate my 32-bit VM to 64-bit to avoid wasting more CPU cycles than needed :(

BTW I hear a 10-15% hit on x86 but this is hearsay, I did not personally test this.

[proteusx]

For me the "just to improve the overall security fingerprint" is now something what I don't have to care manually about any more.

You do not have to "care manually" about it any more and as a result some others have to toil manually from now on.

I wonder how many did "Gentoo" ask before deciding that the hardened option is an "option most users will probably want".

I for one care a lot about stability and performance and care little about security.
I regarded shadow as an annoyance and pam as a serious impediment. Nasty software.
Fortunately pam can be crippled easily with pam_permit.so

Anyway I have already taken care of pie along the lines of [post=8149800] this post[/post]
This is why we love Gentoo. We can easily circumvent creeping developer authoritarianism
and do whatever we like.

EDIT typos.

[tld]

So what's the guidance on x86 systems that need all the performance they can get?

Ditto...especially given that my MythTV systems (that my family depends) on are all x86, this whole thing (which I just started reading about today) is without question the most terrifying thing I've ever heard in almost 14 years using Gentoo.

I'm seeing somewhat mixed messages as to whether this whole recompile to PIE is in fact really necessary or not(??). If it truly must be one way or the other for everyone due to some technical reasons, then I suppose I can appreciate the decision. If not, this is a seriously horrific mandate to force on everyone, and it doesn't sound like I gain anything I care about from it...and may even take a performance hit. Any clarity on all this would be hugely appreciated. For now I sort of just want to cry.

Tom

[eccerr0r]

From what I hear, PIE on Linux is only good for security (and libraries that can be used in multiple programs). It does not help speed (and may even hurt speed). It does not help binary sizes.

As mainline Linux requires a MMU, the MMU argument has no teeth. PIE code is great for machines with no MMU.

I do question the need for this if there is a speed hit for security. This is once again something done that sacrifices speed to solve a problem that should have been solved by writing the software correctly (i.e., securely).

[BitJam]

I've been compiling for about 24 hours. It is almost done and there are a handful of packages that didn't build. The only one I'm concerned about ATM is nvidia-drivers which failed with:

Code: Select all

error code model kernel does not support PIC mode

Do I need to rebuild the kernel before rebuilding kernel modules? Do I need to use special compiler flags when I rebuild the kernel? My guess is that I should disable pie for the kernel modules but that is only a guess and I'm not sure how to do it.

[The Doctor]

The attacks PIE stops can't all be stopped by codding well. Theft should also be stopped by raising kids right but you still have a lock on your door because it doesn't always work out that way. Many of these attacks are used by purpose written malware as a means of privilege escalation.

The directive to recompile world is because if you don't you are likely to see unusual failures and the devs don't want to be bombarded with invalid bug reports, and with good reason. The failures would not be obviously linked. Kind of like why the GCC upgrade guide says you should emerge -e world when upgrading between major versions.

As for speed hits, that appears to be mostly speculation and conformation bias. If you actually check compile times for individual packages there is not much of a difference. If you could load up you machine with Grsecurity, PaX, and SELinux without taking a noticeable speed hit than just PIE alone isn't going to do anything noteworthy.

[Hu]

For systems running in amd64 mode, there should be no noticeable change in size or speed, since rip-relative addressing is normal in amd64 mode. For systems running in x86 mode, PIC (which is called PIE when used on the main program, and PIC when used on a shared library) consumes an extra register to fake eip-relative addressing since the ISA does not support it naturally. This will cause some code to run slower, since x86 has always been badly register starved. Code with large numbers of in-flight variables (such as many cryptographic digest algorithms) is often forced to spill some variables to the stack. PIC deprives the function of one additional register that non-PIC does not claim, so one more variable will need to be spilled. If the algorithm was right at the limit of what it could hold in registers, this marks the difference between spilling and not spilling. (Even if spilling is required, the stack to which it spills will almost certainly be in the L1 cache, which will mitigate the performance cost.)

Unless you've been going out of your way or using strange programs, your shared libraries are very likely PIC and have been for years. The introduction of PIE means that the main binary will also be position independent, which was historically done on hardened for a small security boost and not done on non-hardened because, for x86, it had a cost.

Whether the switch to eip-relative addressing causes a measurable change in the generated code will depend heavily on how often the code accesses global variables (and to some extent, on whether the compiler is clever about not preparing a PIC register unnecessarily). If it uses globals, then it needs a free register to fake the eip-relative addressing. A spot test here suggests that gcc-7 is clever about not using PIE unnecessarily.

Code: Select all

int global;

void f()
{
	++global;
}

int g()
{
	return global;
}

int h()
{
	return 5;
}

Code: Select all

	.file	"p.c"
	.text
	.p2align 4,,15
	.globl	f
	.type	f, @function
f:
.LFB0:
	.cfi_startproc
	call	__x86.get_pc_thunk.ax
	addl	$_GLOBAL_OFFSET_TABLE_, %eax
	movl	global@GOT(%eax), %eax
	addl	$1, (%eax)
	ret
	.cfi_endproc
.LFE0:
	.size	f, .-f
	.p2align 4,,15
	.globl	g
	.type	g, @function
g:
.LFB1:
	.cfi_startproc
	call	__x86.get_pc_thunk.ax
	addl	$_GLOBAL_OFFSET_TABLE_, %eax
	movl	global@GOT(%eax), %eax
	movl	(%eax), %eax
	ret
	.cfi_endproc
.LFE1:
	.size	g, .-g
	.p2align 4,,15
	.globl	h
	.type	h, @function
h:
.LFB2:
	.cfi_startproc
	movl	$5, %eax
	ret
	.cfi_endproc
.LFE2:
	.size	h, .-h
	.comm	global,4,4
	.section	.text.__x86.get_pc_thunk.ax,"axG",@progbits,__x86.get_pc_thunk.ax,comdat
	.globl	__x86.get_pc_thunk.ax
	.hidden	__x86.get_pc_thunk.ax
	.type	__x86.get_pc_thunk.ax, @function
__x86.get_pc_thunk.ax:
.LFB3:
	.cfi_startproc
	movl	(%esp), %eax
	ret
	.cfi_endproc
.LFE3:
	.ident	"GCC: (Gentoo Hardened 7.1.0-r1 p1.1) 7.1.0"
	.section	.note.GNU-stack,"",@progbits

Note how h() does not prepare a PIC register, since it has no global accesses. Now look at the amd64 version:

Code: Select all

	.file	"p.c"
	.text
	.p2align 4,,15
	.globl	f
	.type	f, @function
f:
.LFB0:
	.cfi_startproc
	addl	$1, global(%rip)
	ret
	.cfi_endproc
.LFE0:
	.size	f, .-f
	.p2align 4,,15
	.globl	g
	.type	g, @function
g:
.LFB1:
	.cfi_startproc
	movl	global(%rip), %eax
	ret
	.cfi_endproc
.LFE1:
	.size	g, .-g
	.p2align 4,,15
	.globl	h
	.type	h, @function
h:
.LFB2:
	.cfi_startproc
	movl	$5, %eax
	ret
	.cfi_endproc
.LFE2:
	.size	h, .-h
	.comm	global,4,4
	.ident	"GCC: (Gentoo Hardened 7.1.0-r1 p1.1) 7.1.0"
	.section	.note.GNU-stack,"",@progbits

Observe how the accesses to the global are done via %rip, so there is no need to prepare a dedicated position independence register.

[Tony0945]

If you actually check compile times for individual packages there is not much of a difference.

I haven't finished my promised comparison because of some methodological issues. But the preliminary view is that for Athlon II/Phenom II computers there is maybe only a few percent (1-2) loss if any. Losses seem mostly on short compiles and who cares if a compile takes 3 seconds longer? On bigger packages, configuration, and linking, patching, and swapping seem more important than the actual compiling. The world emerge took almost twice as long as usual but I'm not seeing that on individual packages. I'm not sure if that was due to pie or maybe other changes in the profile. I seemed to spend an inordinate amount of time on qt stuff, but wxGTK stuff zips along.

I do agree with those that say we should have had the choice of migrating the profile or not, just on philosophical grounds. Are we going to to check the news some day and find that pulseaudio or systemd are now mandatory because the devs think it's the better choice?

EDIT: test results are at https://forums.gentoo.org/viewtopic-p-8 ... ml#8158478

[eccerr0r]

The problem is that building everything with -fPIC means that all binaries, even past compilation, will be affected - so this performance hit will extend past build.

I'm worried how much longer Firefox will take to parse a webpage, which will be affected by this change. Perhaps something that uses webkit-gtk won't change much, probably already compiled with PIC.