[gentoo-user] gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Adam Carter]

Comparing the contents of /sys/devices/system/cpu/vulnerabilities/spectre_v2

With gcc 7.2 + kernel 4.14.15;

Intel system shows; Vulnerable: Minimal generic ASM retpoline

AMD system shows: Vulnerable: Minimal AMD ASM retpoline

With gcc 7.3 + kernel 4.15.0;

Intel system shows; Mitigation: Full generic retpoline

AMD system shows' Mitigation: Full AMD retpoline

[Ian Zimmerman]

Is there a simple way, with the upstream (kernel.org) sources, to force
a compiler different from the system default? If there is, it's not in the
README, and a simple grep over the Makefiles also doesn't enlighten.

I am not ready to activate a keyworded gcc for general use.

--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

[Alexander Kapshuk]

To compile the kernel with a different compiler, the method shown
below may be used, e.g.:
make CC=clang

See [1], for details:
Building the kernel with Clang:
[1] https://lwn.net/Articles/734071/

[Mike Gilbert]

On Mon, Jan 29, 2018 at 12:50 PM, Ian Zimmerman <i...@very.loosely.org> wrote:
> On 2018-01-29 20:11, Adam Carter wrote:
>
>> Comparing the contents of /sys/devices/system/cpu/vulnerabilities/spectre_v2
>>
>> With gcc 7.2 + kernel 4.14.15;
>> Intel system shows; Vulnerable: Minimal generic ASM retpoline
>> AMD system shows: Vulnerable: Minimal AMD ASM retpoline
>>
>> With gcc 7.3 + kernel 4.15.0;
>> Intel system shows; Mitigation: Full generic retpoline
>> AMD system shows' Mitigation: Full AMD retpoline
>
> Is there a simple way, with the upstream (kernel.org) sources, to force
> a compiler different from the system default? If there is, it's not in the
> README, and a simple grep over the Makefiles also doesn't enlighten.
>
> I am not ready to activate a keyworded gcc for general use.

You could pass CC=gcc-7.3.0 to the make command, like so:

make -j6 CC=gcc-7.3.0

[Mick]

Shouldn't you have at least compiled your whole toolchain with gcc-7.3.0
first?

--
Regards,
Mick

[Mike Gilbert]

I don't see any reason that would be necessary.

[Henry Kohli]

Would it be usefull to do a emerge -e @world with the new GCC 7.3 ?

If yes, should we add /-mindirect-branch/, /-mindirect-branch-loop/,
/-mfunction-return/ and /-mindirect-branch-register to the CFLAGS ?/

[Nikos Chantziaras]

On 30/01/18 00:36, Henry Kohli wrote:
> Would it be usefull to do a emerge -e @world with the new GCC 7.3 ?

No. Unless there's a bug involved that would require a rebuild. There
doesn't seem to be such bug.

> If yes, should we add /-mindirect-branch/, /-mindirect-branch-loop/,
> /-mfunction-return/ and /-mindirect-branch-register to the CFLAGS ?/

No!

These flags are for *affected* applications only. That means application
that: a) run third-party code, and b) do so in a sandbox.

The vast majority of software doesn't do that. Examples that do are web
browsers (they run JIT compiled javascript), and the kernel.

Packages that benefit from these new flags will be updated and they will
use those flags on their own, as needed.

[Ian Zimmerman]

On 2018-01-29 20:35, Alexander Kapshuk wrote:

> To compile the kernel with a different compiler, the method shown
> below may be used, e.g.:
> make CC=clang

Unfortunately, this has the annoying side effect that kconfig forces a
full reconfiguration, asking every question. Maybe there is a way
around that but looking at the complexity of the Makefile, I'm scared
to mess with it.

What I did in the end was to prepend the following to PATH:

/usr/x86_64-pc-linux-gnu/gcc-bin/7.3.0:

I use a pretty complex script for building kernels, so adding this to
the script was small potatoes. And indeed, after a reboot I see I have
full mitigation against spectre_v2. Now what about spectre_v1?

[Rich Freeman]

On Mon, Jan 29, 2018 at 11:35 PM, Nikos Chantziaras <rea...@gmail.com> wrote:
> On 30/01/18 00:36, Henry Kohli wrote:
>>
>> Would it be usefull to do a emerge -e @world with the new GCC 7.3 ?
>

> These flags are for *affected* applications only. That means application
> that: a) run third-party code, and b) do so in a sandbox.

While I agree that it doesn't make sense to go rebuilding everything
right now, I did want to caution that Spectre is probably a bit
wider-reaching than you're suggesting.

The sandboxed code issue is actually more of a problem with meltdown
as it doesn't require vulnerable interfaces to work - but meltdown has
nothing to do with gcc 7.3. Meltdown does not require any process
vulnerability to work - it just requires a vulnerable CPU and data
mapped into virtual address space that shouldn't be accessible.

Spectre is more about having vulnerable functions in your code being
executable by untrusted code, acting on untrusted data. Now, a lot of
sandboxes do have APIs in them that would be vulnerable, but the
problem goes beyond this. Any kind of API/IPC mechanism, including
sockets, could potentially be exploitable, as long as it is
interacting with some kind of local process (perhaps indirectly).
Spectre is about using data to trick a process to leak state via the
side channel of the cache, and then using local code to probe the
cache.

If you had some program that listened on a socket and accepted a
length and a string and then did a bounds check using the length, it
might be exploitable if a local process could feed it data. Even if
the process only listened for outside connections it might be
vulnerable if a local process colluded with a remote host to make that
connection.

Now, the more directly coupled the untrusted process is to the
vulnerable one the easier this would probably be to pull off. This is
why the kernel system call interface is so attractive. That, and also
the fact that kernel memory is of course a high-value target.

How exploitable any particular process is depends a lot on the actual
code/etc. Spectre should be seen as a class of vulnerabilities just
like buffer overflows. Not every call to strcpy is vulnerable to a
buffer overflow, but it is certainly an opportunity for one. Well, in
the same way things like bounds checks or indirect calls that are
associated with untrusted input are also opportunities. I imagine
that other classes of Spectre will emerge over the coming years as
well. To some degree compilers might be able to become smart enough
on their own to detect vulnerable code and add protections. The
question is whether that can be done with little overhead, vs having
developers identify these points and mark them for the compiler (which
I think is the current approach).

Disclaimer: I'm definitely not a major authority in Spectre. However,
the attack should not be considered limited to sandboxes and JIT and
such.

--
Rich

[Nikos Chantziaras]

On 30/01/18 23:43, Rich Freeman wrote:
> If you had some program that listened on a socket and accepted a
> length and a string and then did a bounds check using the length, it
> might be exploitable if a local process could feed it data. Even if
> the process only listened for outside connections it might be
> vulnerable if a local process colluded with a remote host to make that
> connection.

Well, if you're running a local process that is trying to attack you,
you've been compromised already, imo.

Local processes are always trusted. If Spectre is a vulnerability that
can be exploited by trusted code, it's not really a vulnerability.
Trusted code is called "trusted" for a reason.

So, unless you're running some kind of server that offers execution time
to clients (the clients are untrusted then), there's not many instances
of Spectre actually being relevant. Amazon and Google etc might be
running around currently like headless chickens, but for desktop home
users, Spectre does not seem to have far reaching implications once
you've patched the kernel and the few packages that run untrusted code.

[Tai...@gmx.com]

On 01/31/2018 04:16 AM, Nikos Chantziaras wrote:

> On 30/01/18 23:43, Rich Freeman wrote:
>> If you had some program that listened on a socket and accepted a
>> length and a string and then did a bounds check using the length, it
>> might be exploitable if a local process could feed it data. Even if
>> the process only listened for outside connections it might be
>> vulnerable if a local process colluded with a remote host to make that
>> connection.
>
> Well, if you're running a local process that is trying to attack you,
> you've been compromised already, imo.
>
> Local processes are always trusted. If Spectre is a vulnerability that
> can be exploited by trusted code, it's not really a vulnerability.
> Trusted code is called "trusted" for a reason.

I wouldn't classify for instance running a multiplayer game in a VM as
"trusted" code, the whole point of hardware virtualization is that you
don't have to trust what is being executed there.

Not to mention the issue with most websites requiring javascript for no
reason to function properly.

[Nikos Chantziaras]

Yeah, that's the kind of software that benefits from the Spectre
mitigation patches. Like browsers, virtualization or emulation software,
the kernel, etc.

Rebuilding the whole system with these flags on doesn't sound like a
good idea. Now, I don't know if it would hurt anything, but it's not
uncommon for build flags to break random stuff.

I haven't seen any word from anyone yet as to whether these flags are
actually recommended or not on a system-wide basis. The GCC patches were
primarily developed for the kernel, but there was no word about whether
or not people should build all their software with these flags or not.

So my educated guess is: No. Don't do that. If a package is affected, it
stands to reason that the upstream of that package would change their
build system to use these new flags where needed.

But as always: I could be wrong :-)

[Martin Vaeth]

Nikos Chantziaras <rea...@gmail.com> wrote:
>
> Well, if you're running a local process that is trying to attack you,
> you've been compromised already, imo.

By your definition, you are compromised if you surf to the
wrong webpage with enabled javascript.

While this is arguably true, I would distinguish between various
degree of compromise and would prefer if nevertheless such webpages
would not be able to e.g. read the secret keys of a running gnupg
process.

> So, unless you're running some kind of server that offers execution time
> to clients

... or use your browser with not always disabled javascript ...

> and the few packages that run untrusted code.

You misunderstand: For the packages which run the code, the mitigations
like retpoline do not help much. It is the packages which _somehow_
react (or can be called) by such a code which need the protection by
retpoline built-in.
And this is an awful lot of packages since it includes also all libraries
which are possibly used by these packages, language interpreters used by
these packages, etc. If in doubt, I would re-emerge the
full -e @world with corresponding compiler switches enabled.

Of course, rebuilding @world without changing your C*FLAGS before
would be pointless.

[Martin Vaeth]

Nikos Chantziaras <rea...@gmail.com> wrote:
> Yeah, that's the kind of software that benefits from the Spectre
> mitigation patches. Like browsers, virtualization or emulation software,
> the kernel, etc.

No. It's software like gnupg, encfs, openssl and all the library they
use (glibc, glib, X etc) which need these patches.

> Rebuilding the whole system with these flags on doesn't sound like a
> good idea. Now, I don't know if it would hurt anything, but it's not
> uncommon for build flags to break random stuff.

Yep. On x86, gcc cannot compile itself if built with -fno-plt.

> I haven't seen any word from anyone yet as to whether these flags are
> actually recommended or not on a system-wide basis.

Actually, it is not even clear in the moment which flags should be
used in which settings. (There has been some discussion in the
gentoo forums but to no completely satisfactory result yet.)

> So my educated guess is: No. Don't do that.

Yes and no: It is probably recommended, but the flags are so no and
so poorly understood that people are hesitating with recommendations.
Also, spectre is hard to exploit, so it is perhaps better to wait in
the moment until some experience ins there.

> If a package is affected, it
> stands to reason that the upstream of that package would change their
> build system to use these new flags where needed.

No, for many reasons:

1. Packages often try to not add any flags; especially in gentoo it is a
policy that they _must_ not: If they do, it would get patched out in gentoo.

2. A library has no idea what it is used for. Why should it add something,
only because some program using it should be protected?

3. Adding the flags slows down the programs. It is the user who must
decide whether patches are desirable for his use case and architecture.
(Maybe this is less relevant know but in a while when versions of
processors "immune" to spectre come out.)

[Nikos Chantziaras]

On 31/01/18 13:17, Martin Vaeth wrote:
> Nikos Chantziaras <rea...@gmail.com> wrote:
>>
>> Well, if you're running a local process that is trying to attack you,
>> you've been compromised already, imo.
>
> By your definition, you are compromised if you surf to the
> wrong webpage with enabled javascript.

That's not what was said.

What was said is that software that executes untrusted code inside a
trusted container is affected. You trust the container mechanism, you
don't trust the code executing inside of it. So the container needs to
be protected.

For example, if you don't trust Firefox, don't install Firefox. But you
*do* trust Firefox. What you don't trust is the JS code Firefox is
executing. So Firefox needs protection.

> You misunderstand: For the packages which run the code, the mitigations
> like retpoline do not help much. It is the packages which _somehow_
> react (or can be called) by such a code which need the protection by
> retpoline built-in.
> And this is an awful lot of packages since it includes also all libraries
> which are possibly used by these packages, language interpreters used by
> these packages, etc. If in doubt, I would re-emerge the
> full -e @world with corresponding compiler switches enabled.

I was under the impression that it's the function that performs the call
that needs protection. The called function doesn't need protection,
because if it ends up being actually called, then it's too late already.

For example, if sandboxed, untrusted code wants to speculatively execute
a memcpy(), then the sandbox would need to call it on behalf of the
untrusted code. But if the sandbox is protected, the memcpy() call would
never be made speculatively, since retpoline will trap it. So memcpy()
itself doesn't need protection. If memcpy() ends up being called, then
it's too late. Protecting memcpy() doesn't do anything to prevent
memcpy() from being called, as it's been called already.

What am I missing here? :-P

[Mick]

Just to dilute my confusion on what I should do to keep desktops safe(r),
would someone please clarify:

Is it necessary to keyword gcc 7.3 + kernel 4.15 and emerge kernel 4.15 with
gcc 7.3, or wait until these versions have been stabilised in the tree?

What gcc version shall I use to update @world from then on?

PS. Some desktops are Intel, some are AMD and I also have 3-4 devices with ARM
in them ...
--
Regards,
Mick

[Nikos Chantziaras]

On 31/01/18 14:04, Mick wrote:
> Just to dilute my confusion on what I should do to keep desktops safe(r),
> would someone please clarify:
>
> Is it necessary to keyword gcc 7.3 + kernel 4.15 and emerge kernel 4.15 with
> gcc 7.3, or wait until these versions have been stabilised in the tree?
>
> What gcc version shall I use to update @world from then on?
>
> PS. Some desktops are Intel, some are AMD and I also have 3-4 devices with ARM
> in them ...

At the moment, you do need GCC 7.3. However, there is talk about these
new flags being ported to GCC 6 and possibly even older versions.

As for the kernel, you don't need 4.15. 4.14 is the latest LTS kernel,
and it has the needed patches. I think 4.9 (the previous LTS kernel) has
them too.

Currently, once you enable CONFIG_RETPOLINE in the kernel config and
rebuild with GCC 7.3, you should have all currently available kernel
mitigations. Which currently are:

$ cat /sys/devices/system/cpu/vulnerabilities/*
Mitigation: PTI
Vulnerable
Mitigation: Full generic retpoline

However, improvements to these mitigations will from now on happen for
kernel 4.16 first and backported later. 4.16 for example got mitigations
for ARM. It's how kernel upstream works; new stuff is done in the
current development version, and backported later to still supported
versions.

[Mick]

Thanks Nikos, I'm presently on 4.14.14, so I can update this to 4.14.15 and
compile it with gcc-7.3; then pick up future improvements as part of gentoo-
sources updates when kernels start being marked as stable.

--
Regards,
Mick

[Martin Vaeth]

Nikos Chantziaras <rea...@gmail.com> wrote:
>
> For example, if you don't trust Firefox, don't install Firefox. But you
> *do* trust Firefox. What you don't trust is the JS code Firefox is
> executing.

That's an artificial distinction, because it is actually firefox
which is executing the code during the interpretation of JS.

> So Firefox needs protection.

The only "protection" firefox could be giving is that interpreted
JS is not able to do anything (not access any file or any program
outside of a well-defined sandbox). For various reasons, this is
not the case and will not be the case in any foreseeable future.

What does need protection is all the programs which can be accessed
(almost no matter how indirectly) by JS code - which is almost everything
running on a typical desktop.

Admittedly, firefox can help by e.g. making it harder to use timers
for the precise time measurement needed for "simple" spectre exploits.
This is already happening, but this is independent of the mitigations
provided by the compiler.

> I was under the impression that it's the function that performs the call
> that needs protection. The called function doesn't need protection,
> because if it ends up being actually called, then it's too late already.

The opposite is true. There should be no problem for any code (even
untrusted) to query gnupg to verify the validity of the signature.
But with the spectre exploits, this query might be used to get the
secret key which gnupg must access. So it is gnupg which needs the
protection (unless you want to make it much harder to use gnupg).

> For example, if sandboxed, untrusted code wants to speculatively execute
> a memcpy(), then the sandbox would need to call it on behalf of the
> untrusted code.

In my above example, it is gnupg which speculatively executes some code
if queried e.g. to verify a signature. The "attacking" program then might
use this fact (under some conditions) to understand which secret key was
used.
Everything which untrusted code can influence (no matter how indirectly)
is possible subject to be exploited if it uses speculative execution.
Therefore, the only way to be on the safe side is to avoid speculative
execution altogether.

> But if the sandbox is protected, the memcpy() call would
> never be made speculatively, since retpoline will trap it.

This means that the sandbox-code itself is protected from being
"read" by other code. But already if e.g. a webpage uses libjpeg to
render a picture (even if it would do it inside of an otherwise
protected sandbox), and libjpeg uses speculative execution (which
it does if you do not have compiled it with the new compiler switches),
javascript might (theoretically) be used to get image data it normally
has no access to.

Admittedly, this is all very theoretical and whether it is
actually possible to write working exploits is a different story
(that's why I wrote "(under some conditions)" and "(theoretically)"):
Not every speculative execution actually _can_ be exploited,
but there is always a certain probability (the more direct the
victim program can be accessed by the thief code, the higher the
probability is).

[Rich Freeman]

On Wed, Jan 31, 2018 at 4:16 AM, Nikos Chantziaras <rea...@gmail.com> wrote:
> On 30/01/18 23:43, Rich Freeman wrote:
>>
>> If you had some program that listened on a socket and accepted a
>> length and a string and then did a bounds check using the length, it
>> might be exploitable if a local process could feed it data. Even if
>> the process only listened for outside connections it might be
>> vulnerable if a local process colluded with a remote host to make that
>> connection.
>
>
> Well, if you're running a local process that is trying to attack you, you've
> been compromised already, imo.
>
> Local processes are always trusted.

Not at all. This is the whole point of uids on linux and any POSIX
OS. There is separation of privilege.

I should be able to give you ssh access to my database server using a
UID different from my database server, and it should be impossible for
you to damage my database (particularly if I am using resource
limits/etc).

Spectre allows local processes to probe the cache to obtain data
leaked from other processes running under different UIDs (or even the
kernel) which they should not have access to.

If MariaDB has vulnerable code listening on its socket, and you can
talk to that socket, and run code under a different UID, then you
could in theory read arbitrary data from MariaDB's memory. That could
include tables you don't otherwise have privileges to read, or
possibly even credentials stored in memory that could allow you to
connect to the server and execute arbitrary queries.

Also, all this is requires is code running on the same CPU. It could
be in a different VM, or a different container.

However, I wouldn't completely neglect local priv escalation attacks.
Sure, every sysadmin would prefer to not have code running on their
server that they didn't put there, but there is still such a thing as
defense in depth. There is a reason we don't run all our daemons as
root. If your server's ntp client somehow has a vulnerability and now
there is malicious code running under the ntp UID, it would still be
preferable that this code STAY contained in the ntp UID vs having
access to more mission-critical processes on the server. Sure, you
will still want to wipe the server and install a clean one, but it
would be nice if you could do that after migrating your production
database/website/whatever to another server, versus having to revert
to the last backup.

--
Rich

[Rich Freeman]

On Wed, Jan 31, 2018 at 7:07 AM, Nikos Chantziaras <rea...@gmail.com> wrote:
>
> I was under the impression that it's the function that performs the call
> that needs protection. The called function doesn't need protection, because
> if it ends up being actually called, then it's too late already.
>
> For example, if sandboxed, untrusted code wants to speculatively execute a
> memcpy(), then the sandbox would need to call it on behalf of the untrusted
> code. But if the sandbox is protected, the memcpy() call would never be made
> speculatively, since retpoline will trap it. So memcpy() itself doesn't need
> protection. If memcpy() ends up being called, then it's too late. Protecting
> memcpy() doesn't do anything to prevent memcpy() from being called, as it's
> been called already.
>

I think there is some confusion here because in your scenario there
are actually 3 calls being made, and the sandbox is both being called,
and issuing a call.

In your scenario the code executing inside the sandbox calls an API in
the sandbox which in turn calls memcpy.

Code can be vulnerable to Spectre even if it doesn't call anything at
all (variant 2 of Spectre in particular does require a call, variant 1
does not, and who knows what other variants will be discovered in the
future).

In any case, the issue is that your untrusted code inside the sandbox
is calling trusted code via the sandbox API, and it is the sandbox API
that requires protection, as this is where there is a privilege
boundary.

Again, Spectre is not limited to code running in sandboxes. Your ssh
server could be vulnerable to an incoming ssh client connection if the
client is colluding with another process on the same physical CPU,
assuming your ssh server contains vulnerable code. Sandboxes are just
a particularly nasty and obvious target of this attack since they
routinely execute untrusted code on the same hardware as the software
being protected from the code.

However, this isn't a reason to just go rebuilding everything with
gcc-7.3 and assuming all is fine. The maintainers of the upstream
projects really need to assess their code for vulnerabilities, and
treat gcc as a tool that might help solve things.


--
Rich

[Mick]

On Wednesday, 31 January 2018 12:20:51 GMT Nikos Chantziaras wrote:

> On 31/01/18 14:04, Mick wrote:
> > Just to dilute my confusion on what I should do to keep desktops safe(r),
> > would someone please clarify:
> >
> > Is it necessary to keyword gcc 7.3 + kernel 4.15 and emerge kernel 4.15
> > with gcc 7.3, or wait until these versions have been stabilised in the
> > tree?
> >
> > What gcc version shall I use to update @world from then on?
> >
> > PS. Some desktops are Intel, some are AMD and I also have 3-4 devices with
> > ARM in them ...
>
> At the moment, you do need GCC 7.3. However, there is talk about these
> new flags being ported to GCC 6 and possibly even older versions.
>
> As for the kernel, you don't need 4.15. 4.14 is the latest LTS kernel,
> and it has the needed patches. I think 4.9 (the previous LTS kernel) has
> them too.

Kernel 4.14.15 has the latest patches, so I stayed with the 4.14 series.

> Currently, once you enable CONFIG_RETPOLINE in the kernel config and
> rebuild with GCC 7.3, you should have all currently available kernel
> mitigations. Which currently are:
>
> $ cat /sys/devices/system/cpu/vulnerabilities/*
> Mitigation: PTI
> Vulnerable
> Mitigation: Full generic retpoline

I'm good here:

$ dmesg | grep -i Spectre
[ 0.011822] Spectre V2 mitigation: Mitigation: Full generic retpoline

although this post indicates Skylake may still be vulnerable:

https://lkml.org/lkml/2018/1/4/724

Anyway, as I understand it, we'll have to wait for gcc-8.1 in March, which
utilises 'gcc -mindirect-branch=thunk-extern' to get the benefit of the
retpoline kernel patch.

> However, improvements to these mitigations will from now on happen for
> kernel 4.16 first and backported later. 4.16 for example got mitigations
> for ARM. It's how kernel upstream works; new stuff is done in the
> current development version, and backported later to still supported
> versions.

Spectre_v1 still shown as vulnerable on both Intel and AMD. Is there a fix
planned for this?

--
Regards,
Mick

[Nikos Chantziaras]

On 02/02/18 13:19, Mick wrote:
> Anyway, as I understand it, we'll have to wait for gcc-8.1 in March, which
> utilises 'gcc -mindirect-branch=thunk-extern' to get the benefit of the
> retpoline kernel patch.

No. You get that with GCC 7.3 already, which is in portage now.

>> However, improvements to these mitigations will from now on happen for
>> kernel 4.16 first and backported later. 4.16 for example got mitigations
>> for ARM. It's how kernel upstream works; new stuff is done in the
>> current development version, and backported later to still supported
>> versions.
>
> Spectre_v1 still shown as vulnerable on both Intel and AMD. Is there a fix
> planned for this?

I don't know, but it would be surprising if there wasn't.