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.
_________________
Regards,

NeddySeagoon

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

[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
_________________
Regards,

NeddySeagoon

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

[Fitzcarraldo]

[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]

[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]

[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.

[mv]

[slackline]

[pablo_supertux]

[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.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[proteusx]

[tld]

[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).
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[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:

[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.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.

[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.

[Tony0945]

[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.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?