| View previous topic :: View next topic |
| Author |
Message |
transpetaflops
Apprentice
Joined: 16 May 2005
Posts: 159
|
 Posted: Sat Feb 03, 2018 9:05 am Post subject: |
 |
|
| mv wrote: | | portage does not care which compiler you use, i.e. these variables just refer to your currently configured compiler. |
If gcc and clang are using different parameters for the mitigations, do we just add them all to CFLAGS and the currently used compiler will just drop the parameters it doesn't understand or how do we handle this? |
|
| Back to top |
|
 |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sat Feb 03, 2018 4:52 pm Post subject: |
|
|
| transpetaflops wrote: | | If gcc and clang are using different parameters for the mitigations, do we just add them all to CFLAGS and the currently used compiler will just drop the parameters it doesn't understand or how do we handle this? |
The compiler might spit errors/warnings on unknown flags. If you use portage-bashrc-mv, it will filter the flags before they reach the compiler. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sat Feb 03, 2018 5:00 pm Post subject: |
|
|
world is now rebuilt with the new flags on x86 and am64.
On amd64, some standard programs (zsh, tmux, and xterm) sometimes segfaulted in glibc while compiling, but this might be due to a mixture of already loaded and freshly compiled libs in different formats.
After a reboot on amd64, X did not start: It seems that xorg-server and x11-drivers/* (at least xf86-input-libinput) do not like -fno-plt.
After recompiling these programs with -fno-plt filtered, X starts.
So far, everything appears to be stable on amd64.
x86 successfully recompiled, but it is not tested yet. |
|
| Back to top |
|
|
ChrisJumper
Advocate
Joined: 12 Mar 2005
Posts: 2400
Location: Germany
|
| Posted: Sun Feb 04, 2018 3:26 pm Post subject: |
|
|
| mv wrote: | world is now rebuilt with the new flags on x86 and am64.
|
Which Flags did you use?
| Code: | | -O2 -fno-plt -mretpoline |
| Code: | | O2 -fno-plt -mindirect-branch=thunk -mfunction-return=thunk |
And why no-plt in the first place? Did it affect the speculative execution/branch prediction in a Way that make an attack more difficult?
Gloss about plt:
Position independent Code (PIC)
plt (process linkage table)
Some Code seems to need the plt, especially if you have position dependent code (non-PIC), in combination with dynamically linked/use shared libraries. Because on position dependent code the compiler have no chance to forecast actual used address for functions, later at runtime. That depend on the used shared libraries, so the compiler just use an ordinary call instruction.
Now its the Linkers job when it recognize a relocation of a not locally used symbol to generate a plt entry that load the Address from the Global Offset Table and create a jump to it.
So with the plt you got a function call working on dynamically linked libraries, without a need to modify the position dependent Code (non-PIC).
I suppose those packages who dislike no-plt needs to be static linked? Did not try it by myself just a suggestion. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Feb 04, 2018 5:43 pm Post subject: |
|
|
| ChrisJumper wrote: | | Which Flags did you use? |
A lot of flags, but new were only
| Code: | | -fno-plt -mindirect-branch=thunk -mfunction-return=thunk |
For the records: My other “standard” flags are:
| Code: | CPPFLAGS='-DNDEBUG -DNO_DEBUG'
CXXFLAGS='-march=native -O2 -fno-ident -pipe -Wl,--hash-style=gnu -Wl,--sort-common -Wl,-O9 -Wl,--enable-new-dtags -Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack -Wl,-z,combreloc -Wl,--relax -Wl,--as-needed -Wl,--build-id=none -fstack-protector-strong -fstack-check=specific -fomit-frame-pointer -fno-common -g0 -ffast-math -fmerge-all-constants -ftree-partial-pre -fno-unwind-tables -fno-asynchronous-unwind-tables -fvect-cost-model -fgcse-sm -fgcse-las -fweb -finline-functions -fgcse-after-reload -fpredictive-commoning -fdirectives-only -ftree-switch-conversion -fira-loop-pressure -ftree-loop-distribution -ftree-loop-distribute-patterns -ftree-loop-im -fivopts -fdiagnostics-color=always -freorder-functions -fdevirtualize-speculatively -fno-semantic-interposition -frename-registers -flto -fuse-linker-plugin -flto-partition=none -flto-odr-type-merging -fvisibility-inlines-hidden -fno-enforce-eh-specs -fnothrow-opt -D_GLIBCXX_ASSERTIONS' |
(and CFLAGS, LDFLAGS, FFLAGS, FCFLAGS, F77FLAGS a certain subset of these), and I omitted some processor-specific flags in this list (which are contained in -march=native if the latter is not filtered).
However, do not consider this full list as a general recommendation: Some are quite risky, and I filter a lot of them for specific packages (see here for the exceptions)
| Quote: | | And why no-plt in the first place? Did it affect the speculative execution/branch prediction in a Way that make an attack more difficult? |
That's what I suppose. Of course, this cannot be really checked except by attempting to write an exploit...
| Quote: | | if you have position dependent code (non-PIC), in combination with dynamically linked/use shared libraries |
Nowadays, libraries with non-PIC practically don't exist. (Moreover, I use -pie -fPIE -Wl,-z,now -Wl,-z,relro since years, so even position-dependent non-libraries are rare on my systems.)
| Quote: | | I suppose those packages who dislike no-plt needs to be static linked? |
Essentially, this is xorg-server (and the X drivers), and these cannot be statically linked: The reason why they do not like this flag is that (according to my understanding) they do not use ld.so directly as other packages but instead some hand-crafted X-only runtime linker wrapper which has less/different features. To my knowledge this is one of the reasons why wayland was born: to get rid of such ancient bloat which really blocks progress.
My “solution” is to avoid -fno-plt for these few packages (I had done this earlier with -Wl,-z,now, of course).
Edit: Add other flags, refer to exceptions, fix typos. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Feb 04, 2018 6:55 pm Post subject: |
|
|
| mv wrote: | | x86 successfully recompiled, but it is not tested yet. |
A quick test (booting, running X, testing a few programs) showed so far no problems, either.
For neither system I could observe an obvious slowdown for my usual tasks. Of course, I expect that this might be different for certain long-running calculations, but for standard development (compiling etc, including the emerge -e world itself), I did not recognize an observable slowdown. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9853
Location: almost Mile High in the USA
|
| Posted: Sun Feb 04, 2018 9:15 pm Post subject: |
|
|
Is the only way to get x86 KPTI from a git repo or is there a released version now?
Have anyone seen of a live exploit now? I'd love to be wrong but still think a general purpose exploit is hard to write especially with KASLR.
| mv wrote: | | On amd64, some standard programs (zsh, tmux, and xterm) sometimes segfaulted in glibc while compiling, but this might be due to a mixture of already loaded and freshly compiled libs in different formats. |
Crap, more non-deterministic behavior due to ASLR? :-( One would hope things are deterministic.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Feb 04, 2018 10:07 pm Post subject: |
|
|
| eccerr0r wrote: | | Crap, more non-deterministic behavior due to ASLR? :-( One would hope things are deterministic. |
The crashes occurred only while working on the system during the world rebuild: After the reboot, I had no such crashes anymore (so far). So it seems that my conjecture is true that these crashes were caused by using libraries in mixed versions (partially through programs loaded before the rebuild and partially after the rebuild with the new flags -fno-plt ...). I do not think that ASLR has anything to do with this. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9853
Location: almost Mile High in the USA
|
| Posted: Sun Feb 04, 2018 10:13 pm Post subject: |
|
|
Did you have to do anything to get beyond the crash or simply restarting will succeed (regardless if incorrect versions are in play)? The latter would imply non-determinism. If you mean adding -f no-pit will workaround the crash, then that's okay...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
transpetaflops
Apprentice
Joined: 16 May 2005
Posts: 159
|
| Posted: Sun Feb 04, 2018 10:16 pm Post subject: |
|
|
| eccerr0r wrote: | Have anyone seen of a live exploit now? I'd love to be wrong but still think a general purpose exploit is hard to write especially with KASLR.
|
Symantec has a Trojan listed referencing CVE-2017-5754 at least or it may just be a general info. I'm not certain.
https://www.symantec.com/security_response/writeup.jsp?docid=2018-011115-0609-99 |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9853
Location: almost Mile High in the USA
|
| Posted: Sun Feb 04, 2018 11:07 pm Post subject: |
|
|
From the wording it seems like it's just a heuristic added to antivirus, but no actual code in the wild. Theoretically it should trigger off of the PoC code.
Also note "Risk Level 1: Very Low" which somewhat fits with my guess that it is hard to exploit but easy to demonstrate...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Feb 04, 2018 11:17 pm Post subject: |
|
|
| eccerr0r wrote: | | simply restarting will succeed |
Rebooting succeeded. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9853
Location: almost Mile High in the USA
|
| Posted: Mon Feb 05, 2018 1:08 am Post subject: |
|
|
| mv wrote: | | eccerr0r wrote: | | simply restarting will succeed |
Rebooting succeeded. |
Err. No, I meant when emerge/gcc fails, you had to do something to retry it, whether you did nothing and rerun emerge, or added an option to a config file and emerge. If you did nothing and restarted the emerge and it succeeded the second time around - this would be a determinism problem that would be alarming.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Mon Feb 05, 2018 7:12 am Post subject: |
|
|
| eccerr0r wrote: | | Err. No, I meant when emerge/gcc fails |
It was not emerge/gcc that segfaulted, but other programs I was using during the emerge (not related to the emerge): xterm, tmux, zsh, once also firefox crashed; usually when they should display something. The corresponding X session (and some or even all of these programs) had been open during the whole emerge world process. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9853
Location: almost Mile High in the USA
|
| Posted: Mon Feb 05, 2018 8:25 am Post subject: |
|
|
Ah, thanks for clearing that up. Something like that is quite expected indeed.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Sat Feb 10, 2018 2:22 pm Post subject: Intel microcode revision guide |
|
|
Intel just released a microcode revision guide, which contains detailed list of currently planned microcode updates (MCUs).
The list contains version numbers of
- pre-mitigation MCUs
- stopped MCUs
- new (planned) productions MCUs
I found the link in this message. |
|
| Back to top |
|
|
Luke-Jr
n00b
Joined: 28 Apr 2003
Posts: 33
Location: Jabber: luke@dashjr.org
|
| Posted: Sun Feb 11, 2018 8:28 pm Post subject: |
|
|
| mv wrote: | | Edit: Another surprising observation: -mindirect-branch=thunk without -O2 (or better) will not protect you... |
Why not? What part of -O2 is important? (-O2 contains optimizations that make debugging annoying...) |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Feb 11, 2018 8:48 pm Post subject: |
|
|
| Luke-Jr wrote: | | mv wrote: | | Edit: Another surprising observation: -mindirect-branch=thunk without -O2 (or better) will not protect you... |
Why not? What part of -O2 is important? |
I did not try the switches implied by -O2 individually, but -O1 alone was not enough.
My test is very trivial: I have just compiled the spectre test with -mindirect-branch=thunk and with/without -O2 ...
| Quote: | | O2 contains optimizations that make debugging annoying. |
Why would somebody want to enable spectre mitigation patches in program which is just compiled for being debugged?
(Also, in my experience, debugging is not really harder with -O2. But then again I usually find the bugs by reading the code carefully instead of running a debugger, unless it is a code generation or compiler optimization bug in which case I would have to use -O2 or better anyway...) |
|
| Back to top |
|
|
Luke-Jr
n00b
Joined: 28 Apr 2003
Posts: 33
Location: Jabber: luke@dashjr.org
|
| Posted: Sun Feb 11, 2018 9:52 pm Post subject: |
|
|
| mv wrote: | | Luke-Jr wrote: | | mv wrote: | | Edit: Another surprising observation: -mindirect-branch=thunk without -O2 (or better) will not protect you... |
Why not? What part of -O2 is important? |
I did not try the switches implied by -O2 individually, but -O1 alone was not enough.
My test is very trivial: I have just compiled the spectre test with -mindirect-branch=thunk and with/without -O2 ... |
AFAICT, that test is just for Spectre variant "1a" aka variant 4, which is NOT a CPU bug, but merely a bug in sandboxing frameworks.
Anyhow, strangely enough... turning on every -O2 option by hand does not cause that test to fail (although I confirmed -O2 does)!
So -O2 is doing something undocumented and that doesn't affect the output from -Q --help=optimizers,warnings,params,common,undocumented :/
The minimal I could get the test to fail with was: -O1 -fgcse -finline-small-functions
| mv wrote: |
| Quote: | | O2 contains optimizations that make debugging annoying. |
Why would somebody want to enable spectre mitigation patches in program which is just compiled for being debugged? |
I prefer that if a program crashes, I can immediately debug what happened, so I try to build everything debuggable.
BTW, a number of ebuilds ignore the CFLAGS, so I'm modifying my GCC's defaults instead.
Is -mindirect-branch-register completely unnecessary? (Why was it backported?) |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Mon Feb 12, 2018 5:32 am Post subject: |
|
|
| Luke-Jr wrote: | | So -O2 is doing something undocumented |
Not really. It is documented that it implies certain switches, not that it does nothing more than to enable these switches. I suppose that a whole optimization phase (or at least a considerable part of it) is missing without -O2.
| Quote: | | I prefer that if a program crashes, I can immediately debug what happened, so I try to build everything debuggable. |
For backtraces and such things, optimizations practically do not hurt: If one roughly knows where it crashed, one can guess whether it is a buffer overflow or a null pointer assignment or something else. There is no need to follow every single instruction step by step in such a case, in particular since a bug causing a crash usually happened somewhere else, anyway (wrong arguments to the crashing function or of other data, perhaps caused by a buffer overflow in a completely different place).
| Quote: | | BTW, a number of ebuilds ignore the CFLAGS, so I'm modifying my GCC's defaults instead. |
How do you do this? I never found a convenient way for it: AFAIK, there is not a file which is read on startup, but it seems to be compiled in hard, i.e. you really have to switch binaries?
| Quote: | | Is -mindirect-branch-register completely unnecessary? (Why was it backported?) |
I do not really understand the purpose of this switch. My guess is that it just modifies a detail in the implementation of -mindirect-branch (and of -mfunction-return?) which is only important in connection with =extern. In particular, my guess is that the "extern" part provided by the kernel will not work without this switch and that with =thunk it only influences the retpoline runtime (if at all). But this is only a guess, after I received no reply on my corresponding question. If somebody knows more, please tell... |
|
| Back to top |
|
|
Luke-Jr
n00b
Joined: 28 Apr 2003
Posts: 33
Location: Jabber: luke@dashjr.org
|
| Posted: Mon Feb 12, 2018 5:47 am Post subject: |
|
|
| mv wrote: | | Luke-Jr wrote: | | So -O2 is doing something undocumented |
Not really. It is documented that it implies certain switches, not that it does nothing more than to enable these switches. |
Not documented is the same as undocumented. 
| mv wrote: | | Quote: | | BTW, a number of ebuilds ignore the CFLAGS, so I'm modifying my GCC's defaults instead. |
How do you do this? I never found a convenient way for it: AFAIK, there is not a file which is read on startup, but it seems to be compiled in hard, i.e. you really have to switch binaries? |
I throw a patch file in /etc/portage/patches/sys-devel/gcc/
Still working on my revised one, however - it seems parts of libgcc (crtbegin/end?) are built with -fno-inline, which breaks the retpoline (and in my patch, throws an error at compile-time).
Fetching the GCC git overnight to see if I can identify the reason it's build with -fno-inline and whether it's safe to remove that...
| mv wrote: | | Quote: | | Is -mindirect-branch-register completely unnecessary? (Why was it backported?) |
I do not really understand the purpose of this switch. My guess is that it just modifies a detail in the implementation of -mindirect-branch (and of -mfunction-return?) which is only important in connection with =extern. In particular, my guess is that the "extern" part provided by the kernel will not work without this switch and that with =thunk it only influences the retpoline runtime (if at all). But this is only a guess, after I received no reply on my corresponding question. If somebody knows more, please tell... |
IIRC the kernel doesn't use the switch either. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Mon Feb 12, 2018 9:03 am Post subject: |
|
|
| Luke-Jr wrote: | | mv wrote: | | Luke-Jr wrote: | | So -O2 is doing something undocumented |
Not really. It is documented that it implies certain switches, not that it does nothing more than to enable these switches. |
Not documented is the same as undocumented. |
I think there is a misunderstanding of the double negation I used.
| Quote: | | I throw a patch file in /etc/portage/patches/sys-devel/gcc/ |
That's the inconvenient way I meant. So it is not possible to switch back easily (without implementing anti-options as well). For instance, while this might be the right approach for spectre in user space it calls for trouble for e.g. kernel compilation or kernel modules.
| Quote: | | IIRC the kernel doesn't use the switch either. |
| Code: | $ grep -R indirect-branch-register .
./arch/x86/Makefile: RETPOLINE_CFLAGS += $(call cc-option,-mindirect-branch=thunk-extern -mindirect-branch-register) |
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Mon Feb 12, 2018 9:26 am Post subject: |
|
|
The segfaults have occurred again.
They occurred while (and probably only while) I was re-compiling chromium. I had used jumbo-build because there was a speedup (I had 8GB RAM and 20 GB Swap); when disabling jumbo-build there was still a crash, but only one.
So it seems that the crashes are perhaps related with the kernel OOM-killer. Can it be that the OOM-killer does not log but only causes segfaults? Somehow I have doubts that this is related to retpoline. Here are 2 typical messages: | /var/log/syslog/current wrote: | 13:56:35 03.02.18 [kernel] zsh[8462]: segfault at 0 ip ... sp ... error 4 in libc-2.25.so[...]
13:58:48 03.02.18 [kernel] xterm[25816]: segfault at 18 ip ... sp ... error 4 in libc-2.25.so[...] |
Also a daemon written in perl segfaulted during chrome compilation while it did nothing else than listening to a socket... |
|
| Back to top |
|
|
Spargeltarzan
Guru
Joined: 23 Jul 2017
Posts: 328
|
| Posted: Mon Feb 12, 2018 3:23 pm Post subject: |
|
|
Hi,
I am not seeing the forest with all the trees any more. With kernel 4.14.18, microcode-update, gcc7.3 and binutils-2.30 the speed47 spectre-meltdown-checker reports "not vulnerable" for all three variants.
The output of /sys/devices/system/cpu/vulnerabilities/* is:
| Code: |
cat /sys/devices/system/cpu/vulnerabilities/*
Mitigation: PTI
Mitigation: __user pointer sanitization
Mitigation: Full generic retpoline
|
What do we win when modifying the CFLAGS? And what should we add, only "-mindirect-branch=thunk"? some posts before there was a discussion about it only when no microcode update is used, maybe someone can summarize us what we should or could do here...
Thank you!
_________________
___________________
Regards
Spargeltarzan
Notebook: Lenovo YOGA 900-13ISK: Gentoo stable amd64, GNOME systemd, KVM/QEMU
Desktop-PC: Intel Core i7-4770K, 8GB Ram, AMD Radeon R9 280X, ZFS Storage, GNOME openrc, Dantrell, Xen |
|
| Back to top |
|
|
Luke-Jr
n00b
Joined: 28 Apr 2003
Posts: 33
Location: Jabber: luke@dashjr.org
|
| Posted: Mon Feb 12, 2018 3:29 pm Post subject: |
|
|
| mv wrote: | | So it is not possible to switch back easily (without implementing anti-options as well). |
There are already anti-options. It's just a matter of defaults and errors to prevent accidentally breaking the retpoline. |
|
| Back to top |
|
|
|
|
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
|
|
Kernel & Hardware
