Profile 17.0

Ralphred · Guru Joined: 31 Dec 2013 Posts: 501

Should I be concerned about seeing

Mr. T. · Guru Joined: 26 Dec 2016 Posts: 477

What is the full title for profile 17?

I use an experimental stage 3 and I think the profile list displayed by eselect is different. My profile is named "hardened/linux/musl/amd64",
is numbered 32 but I use the vanilla stage 3 (musl with no hardening).

wrc1944 · Posted: Sun Dec 10, 2017 7:55 pm Post subject:

I'm wondering about how the 17.0 profile change to PIE will function on AM4/Ryzen systems which have a problem with
memory randomization and segfaults, and some users found setting the option

mv · Watchman Joined: 20 Apr 2005 Posts: 6747

mv · Watchman Joined: 20 Apr 2005 Posts: 6747

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

ASLR without position independence is so painful that nobody does it if avoidable. ASLR with position independence is free (relative to non-ASLR with position independence; the cost of PIE vs non-PIE is architecture dependent, and PIE is not free on all architectures).

Disabling ASLR means you're effectively rolling always the same position instead of a random layout. No comment on whether disabling ASLR fixes the Ryzen problem due to some happy accident or because the Ryzen erratum specifically conflicts with ASLR. Until we see a statement from a well-informed party (whether AMD or some particularly clever third party) that describes the erratum's trigger condition, expected results, and actual results, it's hard to guess which errata mitigations work by chance (and may break randomly) versus which work because they specifically avoid the erratum's trigger condition.

Remember also that your shared libraries are already position independent. PIE is only about the executable.

eccerr0r · Posted: Mon Dec 11, 2017 10:50 am Post subject:

Just in case anyone's wondering, here I start one of my (second) slowest amd64 boxes: a HT P4 at 3.4GHz. Libtool completed, just started going through gcc, binutils, and glibc. I think I'm going to pull the trigger on an x86 box soon along with the rest of my amd64 boxes.

(My slowest amd64 box is probably the real 1.8GHz AMD Opteron, but that box doesn't have Linux on it, so I guess I can't upgrade that. Then again the P4 is probably pretty close though, but the P4 has more RAM than the Opteron. Slowest x86 box goes all the way down...)
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

tld · Veteran Joined: 09 Dec 2003 Posts: 1816

NeddySeagoon · Posted: Mon Dec 11, 2017 4:32 pm Post subject:

tld,

tld · Veteran Joined: 09 Dec 2003 Posts: 1816

eccerr0r · Posted: Mon Dec 11, 2017 9:53 pm Post subject:

When building gcc:6.4.0 I noticed my poor P4 seemed to have got stuck on this:

eccerr0r · Posted: Tue Dec 12, 2017 1:04 am Post subject:

tld · Veteran Joined: 09 Dec 2003 Posts: 1816

proteusx · Guru Joined: 21 Jan 2008 Posts: 338

tld

eccerr0r · Posted: Tue Dec 12, 2017 3:43 am Post subject:

It took 7 hours to build gcc6.4 on my atom 1.6 GHz. But the compiler you had, probably gcc-5.4 has some blame as it did the stage1 compilation...

My P4 (amd64) finally finished gcc-6.4, it took 4 hours to complete on the second try.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

lyallp · Posted: Tue Dec 12, 2017 4:17 am Post subject:

Question: The switch to profile 17 is focused on gcc, what about clang?

I have a system that builds almost exclusively with clang/clang++/llvm, with the only exceptions being packages that do not build successfully, such as kernel, glibc, efiutils, etc, that use gcc specific features.

Is profile 17 going to affect clang appropriately as well or is there additional changes I need to do to make things hum along?
_________________
...Lyall

Anon-E-moose · Posted: Tue Dec 12, 2017 10:42 am Post subject:

What's the downside of sticking with profile 13 other than "it will be depreciated"?
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

asturm · Developer Joined: 05 Apr 2007 Posts: 8936

It will be removed.

Anon-E-moose · Posted: Tue Dec 12, 2017 11:15 am Post subject:

Didn't really answer my question. But I made an assumption that someone would grasp that I would have a local copy.

So let me clarify.

What's the downside of sticking with profile 13 other than "it will be depreciated" if I have a copy of profile 13 in my local portage?
And yes, I'm aware that I might have to update eapi when it gets changed to a newer version. Any other gotcha's?

Edit to add: Nevermind, I found an article on creating your own profile, and should be able to just copy all of 13.0 to my local portage.

Thanks
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

Tony0945 · Posted: Tue Dec 12, 2017 2:21 pm Post subject:

tld · Veteran Joined: 09 Dec 2003 Posts: 1816

My plan (aside from unmasking pie using /etc/portage/profile/package.use.force and adding -pie to my USE in make.conf) was to switch to the new profile, and then simply tweak my USE in make.conf until there were as few as possible differences from what I had. Since I won't be recompiling for pie, except for possible cases where USE flags might be masked, I may not have to recompile much at all...unless there's something more to the profiles than I'm aware of.

asturm · Developer Joined: 05 Apr 2007 Posts: 8936

NeddySeagoon · Posted: Tue Dec 12, 2017 5:18 pm Post subject:

asturm,

Some ebuilds filter CFLAGS so that may not be safe.

Better to switcd to /17.x/ so you get all the other goodies and unmask (pie) so it can be turned off on gcc.
That beats the CFLAGS filter.
_________________
Regards,

NeddySeagoon

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

asturm · Developer Joined: 05 Apr 2007 Posts: 8936

Anon-E-moose · Posted: Tue Dec 12, 2017 6:11 pm Post subject: