| View previous topic :: View next topic |
| Author |
Message |
watersb
Apprentice
Joined: 04 Sep 2002
Posts: 297
Location: take a left turn in Tesuque
|
 Posted: Wed Feb 14, 2018 6:38 am Post subject: Mac PPC32 G4 |
 |
|
I found a fork of the Spectre demo that was tweaked for Mac PowerPC, and warped it very slightly to compile on Linux with GCC 7.3.0 -- mostly a matter of replacing calls to ppc_intrinsics with their GCC_builtin equivalents.
Spectre Demo Source.c via Github Gist
The minimal set of CFLAGS that would toggle the success of the Spectre demo were | Code: | | -O2 -fno-plt -fno-common |
. I don't know if that holds up in general. I was also able to mitigate against the demo attack with -Og.
Note that this attack relies upon cached data; it is interesting (for some value of...) to run the demo binary repeatedly, and see how the snooped data comes and goes. Optimization levels below -O2 or -Og and the secret string shows up almost immediately, if not then it converges on the secret string. With -O2, any portions of the secret string seem to quickly get flushed out: the hack can't get to the secret, and repeated attempts seem to make it less successful rather than more so.
| Code: | CFLAGS = -std=c99 -D__POWERPC__
MITIGATE = -O2 -pipe -fno-plt -fno-common
PROGRAM = spectre.out
SOURCE = Source.c
all: $(PROGRAM)
$(PROGRAM): $(SOURCE) ; $(CC) $(CFLAGS) -o $(PROGRAM) $(SOURCE)
clean: ; rm -f $(PROGRAM)
safe: $(SOURCE)
$(CC) $(CFLAGS) $(MITIGATE) -o $(PROGRAM) $(SOURCE)
|
"make safe" to compile with those additional flags, or just "make" to build the demo without them.
----
Linux g2ppc-mini 4.15.3-gentoo #1 Tue Feb 13 20:18:30 MST 2018 ppc 7447A, altivec supported PowerMac10,1 GNU/Linux |
|
| Back to top |
|
 |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Wed Feb 14, 2018 7:46 am Post subject: Re: Mac PPC32 G4 |
|
|
| watersb wrote: | The minimal set of CFLAGS that would toggle the success of the Spectre demo were | Code: | | -O2 -fno-plt -fno-common |
|
I can confirm that this also suffices on x86_64 (for the unforked code). |
|
| Back to top |
|
|
watersb
Apprentice
Joined: 04 Sep 2002
Posts: 297
Location: take a left turn in Tesuque
|
| Posted: Thu Feb 15, 2018 3:07 am Post subject: |
|
|
Thanks mv for your per-package CFLAGS system.
I am able to set a global CFLAGS for Spectre Mitigation, but I have already run into some packages that run afoul of multiple symbol definitions with -fno-common.
/etc/portage/package.cflags makes it easy to filter CFLAGS.
| Code: | | net-misc/openntpd +fno-common |
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Thu Feb 15, 2018 9:06 am Post subject: |
|
|
| watersb wrote: | | some packages that run afoul of multiple symbol definitions with -fno-common. |
The file portage-env-mv/package.cflags/all-systems contains filtering rules for this (and several other flags); flags with more exceptions (pie, flto, ...) are covered in separate flies in portage-env-mv. |
|
| Back to top |
|
|
tholin
Apprentice
Joined: 04 Oct 2008
Posts: 205
|
| Posted: Thu Feb 15, 2018 9:37 am Post subject: Re: Mac PPC32 G4 |
|
|
| watersb wrote: | Spectre Demo Source.c via Github Gist
The minimal set of CFLAGS that would toggle the success of the Spectre demo were | Code: | | -O2 -fno-plt -fno-common |
. I don't know if that holds up in general. I was also able to mitigate against the demo attack with -Og. |
The vulnerable code (victim_function) and the attacking code (readMemoryByte) are in the same program and are compiled with the same flags. You don't know if the CFLAGS makes the vulnerable code less vulnerable or the attacking code less potent. Even if the CFLAGS somehow makes the vulnerable code less vulnerable that's just by chance. The demo is a PoC for Spectre V1 and the compiler/toolchain mitigations are for Spectre V2. To mitigate V1 in the compiler you would have to identify all vulnerable code paths using static analysis but that's impossible since the compiler have no way of knowing which inputs are untrusted. Mitigating all conditional branches is possible but the slowdown would be enormous. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Thu Feb 15, 2018 11:21 am Post subject: Re: Mac PPC32 G4 |
|
|
| tholin wrote: | | Even if the CFLAGS somehow makes the vulnerable code less vulnerable that's just by chance. |
True: there is no guarantee that the code is non-vulnerable, only because certain CFLAGS are used.
But if these CFLAGS make the compiler produce less vulnerable code in at least some typical exploit scenarios, one should better use these. |
|
| Back to top |
|
|
watersb
Apprentice
Joined: 04 Sep 2002
Posts: 297
Location: take a left turn in Tesuque
|
| Posted: Sun Feb 18, 2018 4:02 am Post subject: Re: Mac PPC32 G4 |
|
|
| tholin wrote: | | You don't know if the CFLAGS makes the vulnerable code less vulnerable or the attacking code less potent. Even if the CFLAGS somehow makes the vulnerable code less vulnerable that's just by chance. The demo is a PoC for Spectre V1 and the compiler/toolchain mitigations are for Spectre V2. To mitigate V1 in the compiler you would have to identify all vulnerable code paths using static analysis but that's impossible since the compiler have no way of knowing which inputs are untrusted. Mitigating all conditional branches is possible but the slowdown would be enormous. |
(emphasis mine)
Yes. Crucial to understand these flags are not everything needed, and that we cannot defend against all such attacks with compile-time settings.
I do like to explore the compiler results, and simple Proof-of-Concept toys are fun for me; I lack the experience which might lead me to spot vulnerabilities myself. As the toolchain gets better at explaining potential errors, I try to learn from the warnings and look at source code.
If the mitigations lead to better-behaved code, then that's a win. I hope. Alas, "better-behaved" is of course not the same for all of this code: adheres to formal spec? doesn't crash? rejects insane input?
Thanks, tholin, for the does of reality.  |
|
| Back to top |
|
|
blopsalot
Apprentice
Joined: 28 Jan 2017
Posts: 231
|
| Posted: Tue Feb 20, 2018 4:17 pm Post subject: Re: Mac PPC32 G4 |
|
|
here's my little update. i have added '-mindirect-branch*' to ALLOWED_FLAGS and have been testing using -mindirect-branch=thunk-inline universally. i am stabilizing gold and lto as well, so i cannot say safe for production yet, but I have experienced ZERO build failures as a result of using thunk-inline with otherwise safe flags.
ps: here's everything u need to know about setting per package compiler options:
https://wiki.gentoo.org/wiki//etc/portage/package.env
https://wiki.gentoo.org/wiki/Clang |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Tue Feb 20, 2018 11:23 pm Post subject: Re: Mac PPC32 G4 |
|
|
| blopsalot wrote: | | added '-mindirect-branch*' to ALLOWED_FLAGS |
How did you do that? Did you patch the gentoo repository locally? |
|
| Back to top |
|
|
blopsalot
Apprentice
Joined: 28 Jan 2017
Posts: 231
|
| Posted: Wed Feb 21, 2018 2:10 pm Post subject: |
|
|
| yes, it's in flag-o-matic. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Wed Feb 21, 2018 8:20 pm Post subject: |
|
|
I meant: How do you prevent that your change to the eclass is removed with every sync? Do you modify the eclass manually (or by a script) after every sync? Or do you maintain and merge your own git branch? |
|
| Back to top |
|
|
P.Kosunen
Guru
Joined: 21 Nov 2005
Posts: 309
Location: Finland
|
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Thu Feb 22, 2018 2:05 pm Post subject: |
|
|
| mv wrote: |
I meant: How do you prevent that your change to the eclass is removed with every sync? Do you modify the eclass manually (or by a script) after every sync? Or do you maintain and merge your own git branch? |
IIRC, an eclass in /usr/local/portage will override one in /usr/portage. I have some old ebuilds with eclasses that have been removed from the tree in my /usr/local/portage. Also, you could add a script to postsync_hooks (sic?) that copies the altered eclass over after every sync. |
|
| Back to top |
|
|
pickd.mask
n00b
Joined: 02 Aug 2011
Posts: 28
|
| Posted: Sat Feb 24, 2018 9:56 am Post subject: |
|
|
Hello.
When I was checking my system vulnerabilities using Spectre and Meltdown mitigation detection tool v0.35, it also said that:
| Quote: | CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel has array_index_mask_nospec: YES (1 occurence(s) found of 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch: NO
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization) |
I've tried to find info about this patch myself, but it seems like it's either hard to find or my english makes it hard.
So i'm curious if anybody knows what this patch is and if we, Gentoo users, actually need it or not.
Any advice would be appreciated. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Feb 25, 2018 7:18 am Post subject: |
|
|
| Tony0945 wrote: | | IIRC, an eclass in /usr/local/portage will override one in /usr/portage. |
I haven't checked, but I doubt it. For instance, one can configure portage to store the repository in /srv/... or /var/...; from where should the overrides come? Still some hard-coded /usr/local/portage?
It is possible to specify the repository's masters, but unfortunately, this information is stored in the repository itself: This can be overridden, but then you also have to override e.g. every layman repository you use. (Moreover, I think the repository itself is checked for the eclasses before checking the masters, so perhaps it won't even work to override eclasses but just to provide removed eclasses. With this restriction it also makes sense why that information is stored in the repository itself.)
| Quote: | | Also, you could add a script to postsync_hooks |
Yes, this is one of the ideas I mentioned in my post, but it is a horrible hack which one day will fall back on you. (It might also conflict with git syncing...) Also, it breaks the md5 cache, so the metadata information of the ebuilds becomes worthless and has to be regenerated. |
|
| Back to top |
|
|
Hossie
Tux's lil' helper
Joined: 08 Dec 2005
Posts: 116
|
| Posted: Sun Feb 25, 2018 9:43 am Post subject: |
|
|
| pickd.mask wrote: | Hello.
When I was checking my system vulnerabilities using Spectre and Meltdown mitigation detection tool v0.35, it also said that:
| Quote: | CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel has array_index_mask_nospec: YES (1 occurence(s) found of 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch: NO
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization) |
I've tried to find info about this patch myself, but it seems like it's either hard to find or my english makes it hard.
So i'm curious if anybody knows what this patch is and if we, Gentoo users, actually need it or not.
Any advice would be appreciated. |
As far as I can tell, the "redhat patch" is just the addition of IBRS and IBPB. This is also consistent with the comments in the script (see comments in the function check_redhat_canonical_spectre). This is the "intel way" in addition with microcode updates, the same as linus rejected.
The patch itself is not needed, but you possibly have VMs running with this patch, so hypevisor support for IBRS (with microcode) is still needed.
Dont take this all as facts, just my state of knowledge. |
|
| Back to top |
|
|
pickd.mask
n00b
Joined: 02 Aug 2011
Posts: 28
|
| Posted: Sun Feb 25, 2018 11:52 am Post subject: |
|
|
| Hossie wrote: |
As far as I can tell, the "redhat patch" is just the addition of IBRS and IBPB. This is also consistent with the comments in the script (see comments in the function check_redhat_canonical_spectre). This is the "intel way" in addition with microcode updates, the same as linus rejected.
The patch itself is not needed, but you possibly have VMs running with this patch, so hypevisor support for IBRS (with microcode) is still needed.
Dont take this all as facts, just my state of knowledge. |
Thanks, that's valuable info |
|
| Back to top |
|
|
MaDDeePee
Guru
Joined: 18 Aug 2004
Posts: 393
Location: Germany
|
|
| Back to top |
|
|
benchaney
n00b
Joined: 28 Dec 2017
Posts: 30
|
| Posted: Sun Feb 25, 2018 7:18 pm Post subject: |
|
|
| Sort of. There was an unrelated issue that cause all 4.14 kernels to be marked as unstable. But I do think that this issue is related to why we some other versions are slow to make it in to stable. |
|
| Back to top |
|
|
Luke-Jr
n00b
Joined: 28 Apr 2003
Posts: 33
Location: Jabber: luke@dashjr.org
|
| Posted: Sun Feb 25, 2018 8:19 pm Post subject: Re: Mac PPC32 G4 |
|
|
| tholin wrote: | | watersb wrote: | Spectre Demo Source.c via Github Gist
The minimal set of CFLAGS that would toggle the success of the Spectre demo were | Code: | | -O2 -fno-plt -fno-common |
. I don't know if that holds up in general. I was also able to mitigate against the demo attack with -Og. |
The vulnerable code (victim_function) and the attacking code (readMemoryByte) are in the same program and are compiled with the same flags. You don't know if the CFLAGS makes the vulnerable code less vulnerable or the attacking code less potent. |
This doesn't make sense to me. The victim is the "secret" variable, not code. If you "fix" victim_function, an attacker could always make their own victim_function without the fix applied, no? Am I missing something?
I modified the sample code to read from a write-only mmap (https://gist.github.com/f90e7b91c847e7a0339105fffd1cdffd). Assuming the attacker can use assembly, I don't see any way to get effective protection against this attack... :/ |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Feb 25, 2018 11:00 pm Post subject: Re: Mac PPC32 G4 |
|
|
| Luke-Jr wrote: | | If you "fix" victim_function, an attacker could always make their own victim_function without the fix applied, no? |
If he could make this, he could simply read the data directly. For real exploits the victim runs in a different context than the attacker (either with different privileges, or the attacker is somehow otherwise limited by a sandbox of some sort, e.g. in a browser). |
|
| Back to top |
|
|
Luke-Jr
n00b
Joined: 28 Apr 2003
Posts: 33
Location: Jabber: luke@dashjr.org
|
| Posted: Mon Feb 26, 2018 1:40 am Post subject: Re: Mac PPC32 G4 |
|
|
| mv wrote: | | Luke-Jr wrote: | | If you "fix" victim_function, an attacker could always make their own victim_function without the fix applied, no? |
If he could make this, he could simply read the data directly. For real exploits the victim runs in a different context than the attacker (either with different privileges, or the attacker is somehow otherwise limited by a sandbox of some sort, e.g. in a browser). |
Does that mean my mmap example is actually new Spectre variant? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Mon Feb 26, 2018 7:45 am Post subject: Re: Mac PPC32 G4 |
|
|
| Luke-Jr wrote: | | mv wrote: | | Luke-Jr wrote: | | If you "fix" victim_function, an attacker could always make their own victim_function without the fix applied, no? |
If he could make this, he could simply read the data directly. For real exploits the victim runs in a different context than the attacker (either with different privileges, or the attacker is somehow otherwise limited by a sandbox of some sort, e.g. in a browser). |
Does that mean my mmap example is actually new Spectre variant? |
??? Your question has not the slightest relation with my answer. Your "victiim" simply runs in a context which can read the mmap anyway. |
|
| Back to top |
|
|
tholin
Apprentice
Joined: 04 Oct 2008
Posts: 205
|
| Posted: Mon Feb 26, 2018 11:21 am Post subject: Re: Mac PPC32 G4 |
|
|
| Luke-Jr wrote: | | If you "fix" victim_function, an attacker could always make their own victim_function without the fix applied, no? |
That assumes the attacker can put arbitrary code in a process, but if that is possible the attacker can read the process memory even without specter vulnerabilities. That PoC only demonstrates that the cpu got the spectre v1 vulnerably. C code is used and the vulnerable code and attacking code is put in the same program because it's easier to demonstrate the vulnerability that way. Assuming that an attacker can't put arbitrary machine code in a process the attacker has to get the vulnerable code snippet into the victim some other way. Perhaps it was there all along because the programmer put it there without realizing it's dangerous or perhaps the attacker can inject it using the victims own JIT compiler. That's how google's PoC worked.
To fix the vulnerability you have to do something like this to all vulnerable code patterns.
| Code: | void NOINLINE victim_function(size_t x) {
if (x < array1_size) {
+ _mm_lfence();
temp &= array2[array1[x] * 512];
}
} |
Assuming the lfence instruction is serializing this will prevent the vulnerable code pattern from being speculatively executed before the boundcheck completes.
X86 page tables doesn't have the concept of write-only mappings. Only a single bit is used for the permission. If it's set the page is R+W and if it's clear RO. If you set PROT_WRITE you'll get a R+W mapping even without setting PROT_READ. |
|
| Back to top |
|
|
Luke-Jr
n00b
Joined: 28 Apr 2003
Posts: 33
Location: Jabber: luke@dashjr.org
|
| Posted: Mon Feb 26, 2018 1:45 pm Post subject: Re: Mac PPC32 G4 |
|
|
| tholin wrote: |
X86 page tables doesn't have the concept of write-only mappings. Only a single bit is used for the permission. If it's set the page is R+W and if it's clear RO. If you set PROT_WRITE you'll get a R+W mapping even without setting PROT_READ. |
But the program segfaults if I try to read directly from it...? |
|
| Back to top |
|
|
|
Kernel & Hardware
