Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Meltdown/Spectre: Unauthorized Disclosure of Kernel Memory
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 20, 21, 22, 23  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
watersb
Apprentice
Apprentice


Joined: 04 Sep 2002
Posts: 297
Location: where the hell is Tesuque, New Mexico?

PostPosted: Wed Feb 14, 2018 6:38 am    Post subject: Mac PPC32 G4 Reply with quote

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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6073

PostPosted: Wed Feb 14, 2018 7:46 am    Post subject: Re: Mac PPC32 G4 Reply with quote

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
View user's profile Send private message
watersb
Apprentice
Apprentice


Joined: 04 Sep 2002
Posts: 297
Location: where the hell is Tesuque, New Mexico?

PostPosted: Thu Feb 15, 2018 3:07 am    Post subject: Reply with quote

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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6073

PostPosted: Thu Feb 15, 2018 9:06 am    Post subject: Reply with quote

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
View user's profile Send private message
tholin
Tux's lil' helper
Tux's lil' helper


Joined: 04 Oct 2008
Posts: 121

PostPosted: Thu Feb 15, 2018 9:37 am    Post subject: Re: Mac PPC32 G4 Reply with quote

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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6073

PostPosted: Thu Feb 15, 2018 11:21 am    Post subject: Re: Mac PPC32 G4 Reply with quote

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
View user's profile Send private message
watersb
Apprentice
Apprentice


Joined: 04 Sep 2002
Posts: 297
Location: where the hell is Tesuque, New Mexico?

PostPosted: Sun Feb 18, 2018 4:02 am    Post subject: Re: Mac PPC32 G4 Reply with quote

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
View user's profile Send private message
blopsalot
Apprentice
Apprentice


Joined: 28 Jan 2017
Posts: 231

PostPosted: Tue Feb 20, 2018 4:17 pm    Post subject: Re: Mac PPC32 G4 Reply with quote

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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6073

PostPosted: Tue Feb 20, 2018 11:23 pm    Post subject: Re: Mac PPC32 G4 Reply with quote

blopsalot wrote:
added '-mindirect-branch*' to ALLOWED_FLAGS

How did you do that? Did you patch the gentoo repository locally?
Back to top
View user's profile Send private message
blopsalot
Apprentice
Apprentice


Joined: 28 Jan 2017
Posts: 231

PostPosted: Wed Feb 21, 2018 2:10 pm    Post subject: Reply with quote

yes, it's in flag-o-matic.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6073

PostPosted: Wed Feb 21, 2018 8:20 pm    Post subject: Reply with quote

blopsalot wrote:
yes

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
View user's profile Send private message
P.Kosunen
Apprentice
Apprentice


Joined: 21 Nov 2005
Posts: 253
Location: Finland

PostPosted: Thu Feb 22, 2018 10:52 am    Post subject: Reply with quote

https://newsroom.intel.com/news/latest-intel-security-news-updated-firmware-available/
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


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

PostPosted: Thu Feb 22, 2018 2:05 pm    Post subject: Reply with quote

mv wrote:
blopsalot wrote:
yes

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
View user's profile Send private message
pickd.mask
n00b
n00b


Joined: 02 Aug 2011
Posts: 11

PostPosted: Sat Feb 24, 2018 9:56 am    Post subject: Reply with quote

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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6073

PostPosted: Sun Feb 25, 2018 7:18 am    Post subject: Reply with quote

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
View user's profile Send private message
Hossie
Tux's lil' helper
Tux's lil' helper


Joined: 08 Dec 2005
Posts: 108

PostPosted: Sun Feb 25, 2018 9:43 am    Post subject: Reply with quote

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
View user's profile Send private message
pickd.mask
n00b
n00b


Joined: 02 Aug 2011
Posts: 11

PostPosted: Sun Feb 25, 2018 11:52 am    Post subject: Reply with quote

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
View user's profile Send private message
MaDDeePee
Guru
Guru


Joined: 18 Aug 2004
Posts: 343
Location: Germany

PostPosted: Sun Feb 25, 2018 2:09 pm    Post subject: Reply with quote

Sry if this is a stupid question....but may i ask:

Is this current problem the reason why all kernels since 4.9.76 are still marked "testing"?
We're at 4.15.4 right now...
https://packages.gentoo.org/packages/sys-kernel/gentoo-sources

Thanks :)
Back to top
View user's profile Send private message
benchaney
n00b
n00b


Joined: 28 Dec 2017
Posts: 26

PostPosted: Sun Feb 25, 2018 7:18 pm    Post subject: Reply with quote

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
View user's profile Send private message
Luke-Jr
n00b
n00b


Joined: 28 Apr 2003
Posts: 33
Location: Jabber: luke@dashjr.org

PostPosted: Sun Feb 25, 2018 8:19 pm    Post subject: Re: Mac PPC32 G4 Reply with quote

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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6073

PostPosted: Sun Feb 25, 2018 11:00 pm    Post subject: Re: Mac PPC32 G4 Reply with quote

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
View user's profile Send private message
Luke-Jr
n00b
n00b


Joined: 28 Apr 2003
Posts: 33
Location: Jabber: luke@dashjr.org

PostPosted: Mon Feb 26, 2018 1:40 am    Post subject: Re: Mac PPC32 G4 Reply with quote

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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6073

PostPosted: Mon Feb 26, 2018 7:45 am    Post subject: Re: Mac PPC32 G4 Reply with quote

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
View user's profile Send private message
tholin
Tux's lil' helper
Tux's lil' helper


Joined: 04 Oct 2008
Posts: 121

PostPosted: Mon Feb 26, 2018 11:21 am    Post subject: Re: Mac PPC32 G4 Reply with quote

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.

Luke-Jr wrote:
I modified the sample code to read from a write-only mmap (https://gist.github.com/f90e7b91c847e7a0339105fffd1cdffd)

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
View user's profile Send private message
Luke-Jr
n00b
n00b


Joined: 28 Apr 2003
Posts: 33
Location: Jabber: luke@dashjr.org

PostPosted: Mon Feb 26, 2018 1:45 pm    Post subject: Re: Mac PPC32 G4 Reply with quote

tholin wrote:
Luke-Jr wrote:
I modified the sample code to read from a write-only mmap (https://gist.github.com/f90e7b91c847e7a0339105fffd1cdffd)

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3 ... 20, 21, 22, 23  Next
Page 21 of 23

 
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