Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Profile 17.0
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 6, 7, 8 ... 10, 11, 12  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
Ralphred
Tux's lil' helper
Tux's lil' helper


Joined: 31 Dec 2013
Posts: 78

PostPosted: Sun Dec 10, 2017 5:18 am    Post subject: Reply with quote

Should I be concerned about seeing
Code:
-fno-PIE -c -fno-PIE
in a post profile change gcc build?
Portage is behaving correctly regarding the use of the use flags...
Back to top
View user's profile Send private message
Mr. T.
Guru
Guru


Joined: 26 Dec 2016
Posts: 477

PostPosted: Sun Dec 10, 2017 11:35 am    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 3182
Location: Gainesville, Florida

PostPosted: Sun Dec 10, 2017 7:55 pm    Post subject: Reply with quote

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
Code:
kernel.randomize_va_space = 0
to /etc/sysctl.conf

Over on https://wiki.gentoo.org/wiki/Ryzen some users have reported that disabling ASLR resolves the segfault issues. I know I had the problem on two Gentoo installs and had to RMA my original 1707SUT (got a nice 1733SUS) but have still left the /etc/sysctl.conf edit in.

Having just found out about the new 17.0 and the move to PIE which essentially appears to be on track for eventually being mandatory, I'm kind of concerned this could be a major problem for owners of the first round of AM4/Ryzen hardware. In other words, what are the implications of disabling ALSR (if necessary) and using a 17.0 PIE profile if you are on a Ryzen system still running an effected cpu (an RMA, or not)?

Still lacking enough knowledge, I haven't decided what's the best course, -PIE or PIE, and I certainly don't want performance hits, and am yet unconvinced I actually need a PIE compiled system.

How long is profile 13.0/desktop/plasma going to remain viable?

Are my concerns really no big deal, and any problems will be able to be addressed without too much trouble?
_________________
Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.27-r6, gcc-8.2.0-r3 kernel-4.18.15-gentoo USE=experimental
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6242

PostPosted: Sun Dec 10, 2017 8:54 pm    Post subject: Reply with quote

eccerr0r wrote:
mv wrote:
There is a huge difference between gcc-4 and gcc-7 (which I used), especially if one just uses generic options like -O2 since a lot of what was previously -O3 is now contained in -O2.

Now you're spreading something that isn't quantified.

There were quite some options which had been included in -O2, but I really forgot them meanwhile. You would need to reread all release notes since then in detail if you want to know it exactly.
One remarkable thing I remember is that -fstrict-aliasing has been added to -O2 in some gcc version which brought some surprising changes in the produced code. But there were other changes as well: some mild loop unrolling was added, some gcse stuff removed, some loop pressure parameters have been tuned, …
Quote:
As witnessed by the first paper, sometimes -O3 is worse than -O2, so there's no guarantee these optimizations actually improve runtime.

Exactly. Just as I said that there is no guarantee that -pie will improve running time compared to +pie. In both cases, there is only a certain probability that it will, and "usually" it will (for the right definition of "usually" ;) ).

Anyway, this was not the reason why I mentioned the optimizations: My point was that with these optimizations (no matter whether they are advantageous or not) it might very well be that the effect of +pie vs. -pie is much less visible.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6242

PostPosted: Sun Dec 10, 2017 9:18 pm    Post subject: Reply with quote

wrc1944 wrote:
disabling ASLR resolves the segfault issues.

pie without aslr is rather pointless from a security point of view.

However, if disabling ASLR really solves segfaults, this is just the case "by accident": You have not cured the symptom or avoided the problem, but you are perhaps by accident in a situation where the problem occurs less frequently.

I read that amd replaces the buggy early processors for free.
Maybe later series could be fixed by some firmware (microcode) update.

Until this happens, you have probably no other choice than to disable aslr if your system really crashes with it.
You might use pie anyway so that you will not have to recompile once ryzen's problem is fixed. I have no idea about the ryzen architecture, so I cannot answer your other questions.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13043

PostPosted: Sun Dec 10, 2017 11:23 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 6936
Location: almost Mile High in the USA

PostPosted: Mon Dec 11, 2017 10:50 am    Post subject: Reply with quote

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@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1327

PostPosted: Mon Dec 11, 2017 4:20 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Right no, as long as pie in consistent, nothing breaks.
We have gcc-6.4 with and without pie.

If you want -pie, go for it but on the /17.x/ profile. 17.1 is in the wings too.

Going forward, nothing will be tested or supported -pie.
Thanks. Maybe someone can clarify a few things...looking at some of this in detail I'm suddenly a bit confused:

I actually haven't installed gcc 6.4 as yet...had it masked until I figured out what I was doing. However I can see that with the existing 13.x profiles, gcc 6.4 would in fact get installed with pie disabled. As I understand it, with the 17.x profiles, pie would be enabled for gcc, and could only be disabled by first unmasking the USE flag with a file under /etc/portage/profile (does the name of this file matter?), and then adding -pie to my USE in make.conf.

What has me totally confused is the distinction between pie being enabled for gcc, and what affect that has on the compilation and/or the pie USE flags of other packages. For example, when I look for existing packages currently have a pie use flag, I can see that only a few, for example openssh and pam have that...and it's currently on for me. What exactly is gcc 5.4 doing there?...I see that it has only a nopie USE flag which is disabled.

If I unmask the use flag when I switch to 17.x and add -pie to my global USE setting, it would presumably change openssh and pam to -pie as well...not sure if that's what I want or not. Seriously confusing.

EDIT: As to my question about the file name under /etc/portage/profile specifically...suggestions here use the file name package.use.force. Is that file name functionally different from, for example, package.use.mask?

Tom
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 41729
Location: 56N 3W

PostPosted: Mon Dec 11, 2017 4:32 pm    Post subject: Reply with quote

tld,

Code:
USE=pie emerge gcc
builds a gcc that emits pie code everywhere unless its told not to.
Code:
USE=-pie emerge gcc
builds a gcc that does not emit pie code unless its told to.

It changes the default behaviour of gcc. The default can be overridden in all the usual ways with -fpie/-fno-pie
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1327

PostPosted: Mon Dec 11, 2017 6:20 pm    Post subject: Reply with quote

NeddySeagoon wrote:
It changes the default behaviour of gcc. The default can be overridden in all the usual ways with -fpie/-fno-pie
Ahhh...OK. That makes sense...thanks for the clarification.
I'm still a little unclear as to whether I should be using -pie on packages such as openssh and pam that were already using +pie by default apparently. Maybe that's not of any great consequence.
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 6936
Location: almost Mile High in the USA

PostPosted: Mon Dec 11, 2017 9:53 pm    Post subject: Reply with quote

When building gcc:6.4.0 I noticed my poor P4 seemed to have got stuck on this:
Code:
21097 portage   20   0    8568    832    708 R  33.3  0.0 218:45.41 genhooks   
21098 portage   20   0    8568    832    704 R  33.3  0.0 218:42.78 genhooks   
21104 portage   20   0    8344    928    800 R  33.3  0.0 218:44.17 genmodes   
21109 portage   20   0    8340    832    712 R  33.3  0.0 218:43.91 genmddeps   
21115 portage   20   0    8344    908    788 R  33.3  0.0 218:43.69 genmodes   
21101 portage   20   0    8568    840    712 R  32.3  0.0 218:40.85 genhooks   

Wow this is taking forever. I wonder if I should kill this and start over...

This is a dual threaded P4, so only 1 core is running all 6 threads and probably thrashing the cache pretty badly though it has plenty of RAM to keep from thrashing swap. How long should this phase actually take, or perhaps it's deadlocked now? Thinking I should kill this because my Atom didn't take this long to finish gcc-6...

[edit]
Killing it. Looks like it's gotten itself into an endless loop somehow. Ugh, now to figure out how it got into this mess.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 6936
Location: almost Mile High in the USA

PostPosted: Tue Dec 12, 2017 1:04 am    Post subject: Reply with quote

tld wrote:
I'm still a little unclear as to whether I should be using -pie on packages such as openssh and pam that were already using +pie by default apparently. Maybe that's not of any great consequence.

I'm probably just going ahead and leaving PIE for these, likely no big loss especially for pam as it's one of those touch and go. Openssh if you're using it for scp/sftp may have some consequence but it too has a lot of dead time due to network. I may need to experiment to see if one is faster than the other, though openssh/pam shouldn't take long to build...
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1327

PostPosted: Tue Dec 12, 2017 2:41 am    Post subject: Reply with quote

eccerr0r wrote:
Wow this is taking forever. I wonder if I should kill this and start over...
I compiled gcc 6.4 today on this x86 machine and it took about 5-1/2 hours. Sort of surprised me for sure. I don't know offhand how long gcc 5.4 took but I don't think it was that long.

Tom
Back to top
View user's profile Send private message
proteusx
Apprentice
Apprentice


Joined: 21 Jan 2008
Posts: 208

PostPosted: Tue Dec 12, 2017 3:32 am    Post subject: Reply with quote

tld
Code:
genlop -t sys-devel/gcc
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 6936
Location: almost Mile High in the USA

PostPosted: Tue Dec 12, 2017 3:43 am    Post subject: Reply with quote

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@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
lyallp
Veteran
Veteran


Joined: 15 Jul 2004
Posts: 1389
Location: Adelaide/Australia

PostPosted: Tue Dec 12, 2017 4:17 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3567
Location: Dallas area

PostPosted: Tue Dec 12, 2017 10:42 am    Post subject: Reply with quote

What's the downside of sticking with profile 13 other than "it will be depreciated"?
_________________
Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
4.14.62 kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 7.3.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 6624
Location: Austria

PostPosted: Tue Dec 12, 2017 10:45 am    Post subject: Reply with quote

It will be removed.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3567
Location: Dallas area

PostPosted: Tue Dec 12, 2017 11:15 am    Post subject: Reply with quote

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
_________________
Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
4.14.62 kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 7.3.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 2689
Location: Illinois, USA

PostPosted: Tue Dec 12, 2017 2:21 pm    Post subject: Reply with quote

Anon-E-moose wrote:
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.

Can you post a link? I'm interested for 32 bit where I don't want to lose a register, I might try 17.0 and see what the performance hit is, but I'd like a fallback other than not updating the box.
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1327

PostPosted: Tue Dec 12, 2017 3:07 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 6624
Location: Austria

PostPosted: Tue Dec 12, 2017 3:42 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Didn't really answer my question. But I made an assumption that someone would grasp that I would have a local copy.

But why would you do that, rather than switch to 17.0 and simply disabling pie in CFLAGS...
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 41729
Location: 56N 3W

PostPosted: Tue Dec 12, 2017 5:18 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 6624
Location: Austria

PostPosted: Tue Dec 12, 2017 5:21 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Some ebuilds filter CFLAGS so that may not be safe.

I wouldn't worry too much about that, but if you want to make sure....
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3567
Location: Dallas area

PostPosted: Tue Dec 12, 2017 6:11 pm    Post subject: Reply with quote

Tony0945 wrote:
Anon-E-moose wrote:
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.

Can you post a link? I'm interested for 32 bit where I don't want to lose a register, I might try 17.0 and see what the performance hit is, but I'd like a fallback other than not updating the box.


https://wiki.gentoo.org/wiki/Profile_%28Portage%29

Edit to add: what I did was just copy all of /usr/portage/profiles to /usr/local/portage/profiles while not overwriting /usr/local/portage/profiles/repo_name
Made a backup of /usr/local/portage/profiles/profiles.desc and then edited it to just be the few that I want to show up in "eselect profile list"
It now shows this
Code:
  [35]  hardened/linux/uclibc/amd64
  [36]  local:default/linux/amd64/13.0/desktop


Asturm for the question as to why not update, I'm still using gcc 4.9.4 and really don't have a desire to update to gcc 5 or later, at this point in time, I may jump to 6 or 7 when it stabilizes (yes I''m aware that I'll need to recompile stuff the same as moving to gcc 5.* ).
_________________
Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
4.14.62 kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 7.3.0, eudev, openrc, openbox, palemoon


Last edited by Anon-E-moose on Tue Dec 12, 2017 9:24 pm; edited 2 times in total
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2, 3 ... 6, 7, 8 ... 10, 11, 12  Next
Page 7 of 12

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum