1518491014 Q * Bertl_oO Ping timeout: 480 seconds 1518500953 J * Bertl_oO herbert@IRC.13thfloor.at 1518509769 J * nikolay ~nikolay@149.235.255.3 1518510013 M * Ghislain well i have no sanity left so i am fine 1518510030 M * Ghislain anyone has a 4.1.49 running ? 1518511797 M * Bertl_oO off for a nap ... bbl 1518511804 N * Bertl_oO Bertl_zZ 1518512330 M * Aiken my sanity is long gone so that is what I tried and the poor c2d which does not have pcid saw a bit over 100% increase in time where compiling a kernel 1518512358 M * Aiken got side tracked by life again and my vm box is currently 4.9.78-vs2.3.9.5 1518513943 Q * kolorafa_ Remote host closed the connection 1518514792 M * Ghislain i wonder if the pcid feature has been included in the 4.9 patches 1518514800 M * Ghislain but yes compiling kernel takes ages 1518514813 M * Ghislain i blame the floppy disk driver for that 1518515372 J * kolorafa ~quassel@root03.itdesk.eu 1518516244 M * Aiken I thought pcid was a cpu thing. Both my i5 and i7 show it but not the c2d 1518516575 M * Ghislain it is but the kernel need to get code that use it 1518516738 Q * kolorafa Remote host closed the connection 1518516792 J * kolorafa ~quassel@root03.itdesk.eu 1518518124 Q * ggherdov__ 1518518161 J * ggherdov__ sid11402@id-11402.hathersage.irccloud.com 1518528462 N * Bertl_zZ Bertl 1518528468 M * Bertl back now ... 1518531572 M * Le_Coyote For what it's worth, I've managed to build dietlibc *and* util-vserver with hardened gcc with very smiple patches 1518531588 M * Le_Coyote Going to send them on bugs.gentoo.org 1518531640 M * Bertl great! maybe also send them to daniel_hozac 1518531666 M * Le_Coyote Hah, except for the nopie/no-pie… the option changed syntax between gcc 5.4 and 6.4 apparently. How's that 1518531673 M * Le_Coyote Bertl: already asked him about that, no reply so far 1518531840 M * Bertl just send then to him, if they are reasonably unintrusive, I'm pretty sure he will incorporate them in one of the next releases 1518531985 M * Le_Coyote Well they simply remove the __constructor attribute from the "offending" fucntions (initHertz initSomething else, IIRC) 1518532000 M * Le_Coyote I need to polish the dietlibc ebuild, it seems 1518532087 M * Ghislain the question is what it does to have it and what does this mean to remove it. Without explanation of that it is hard to validate anything like security implications etc... 1518532362 M * daniel_hozac like i said before, fixing a toolchain problem without any reason other than "it doesn't work" in the source doesn't make sense. 1518532392 M * daniel_hozac figure out if your toolchain's behaviour is correct first, i.e. determine why it happens at all. 1518532523 M * Le_Coyote Well, I tried to explain it before 1518532552 M * Le_Coyote If the function declaration serves no purpose *and* it breaks SSP, is there any point in keeping it? 1518532590 M * daniel_hozac it does serve a purpose though, which is why it is there. 1518532600 M * Le_Coyote I *cannot* investigate things I do not understand, and I *cannot* be expected to learn about hairy stuff like GCC's SSP when I hardly know any C in the first place 1518532615 M * Le_Coyote I can only point out that, without these declarations, the problem goes away 1518532623 M * daniel_hozac which is fine, but i'm not going to investigate your odd toolchain. 1518532668 M * Le_Coyote daniel_hozac: which one is that though? From the gdb behaviour, I was under the impression that the init* functions were called either way, and that the __constructor didn't change aything 1518532675 M * Le_Coyote So I must be missing something, clearly. What is that? 1518532892 M * daniel_hozac either way, constructor is used in other places, where being a constructor is a requirement. how do you fix those? 1518532936 M * daniel_hozac without actually getting to the root cause, like dietlibc not implementing your new GCC's SSP requirements or whatever, your only moving your problem. 1518533190 M * Le_Coyote daniel_hozac: which is why I'm saying: I'm not qualified to investigate that. 1518533217 M * Le_Coyote I'm just saying that when I use a hardened gcc toolchain, ie. with SSP enabled among other things, it breaks vserver-stat, but not much else. 1518533225 M * Le_Coyote That is as the best I can do. 1518533249 M * Le_Coyote Where are other constructors that I could test? 1518533503 M * Le_Coyote daniel_hozac: apart from rpm_fake.c I cannot find any 1518533923 M * Le_Coyote daniel_hozac: let me rephrase: what are the consequences of *removing* the 2 declarations (initHertz and initPageSize) from vserver-stat.c? 1518536419 M * Bertl so how about creating a minimal test case which shows the problem (i.e. a __constructor causing the hardened toolchain to fail) and then asking the toolchain maintainer why that is so? 1518539869 Q * nikolay Quit: Leaving 1518541199 M * Le_Coyote Bertl: No idea. However : "It should also be noted that with the optimisations enabled via -O in GCC, the compiler may or may not "inline" a function. If a function has been inlined, then stack smash protection will not work for that function." 1518541206 M * Le_Coyote https://wiki.osdev.org/Stack_Smashing_Protector 1518541802 M * Bertl I've never understood the purpose of SSP 1518543325 M * Le_Coyote Well I certainly won't be able to do anything about that 1518551693 J * Long_yanG ~long@15255.s.t4vps.eu 1518552052 Q * LongyanG Ping timeout: 480 seconds 1518558417 M * obeardly Has anyone tried the psands kernels, or do you just roll your own? 1518561295 M * Bertl it is advised to tailor the kernel to your personal needs 1518561325 M * Bertl i.e. remove all the stuff you don't use 1518561847 M * Bertl off to bed now ... have a good one everyone! 1518561851 N * Bertl Bertl_zZ 1518562422 Q * yang Ping timeout: 480 seconds