Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Joerg Schilling]

Rich Freeman  wrote:

> On Thu, Jan 4, 2018 at 8:52 PM, Jalus Bilieyich  wrote:
> > Is my Pentium D from 2007 affected?
> >
>
> Any Intel x86 chip after and including the Pentium Pro should be
> affected.  That came out in 1995.  The Pentium D is almost certainly
> vulnerable.

There was a statement from previous Sun people that claim 64 bit Solaris 
kernels on Sparc are not affected because they use a separate context for user 
and kernel space. 

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Rich Freeman]

On Thu, Jan 4, 2018 at 9:22 PM, R0b0t1  wrote:
>
> I think referring to BPF is a red herring, because it is really the
> processor that is at fault. Not BPF. And yes, I'm aware of what AMD
> claims.

Of course the processor is at fault.  However, in order to exploit the
fault on an AMD processor you have to target a function running in the
correct priv level.  BPF JIT was a way to accomplish this on Linux,
because it can be made to run code.

If the kernel doesn't contain any susceptible code, then it can't be
exploited, because for Spectre to work part of the code has to run
with kernel privs.  Otherwise an AMD CPU will block the memory
accesses before they affect the cache.

The only exploit that works entirely with code in userspace is variant
3 (Meltdown), which is Intel-only, because Intel processors will
speculatively fetch data at the wrong priv level which affects the
cache (though the instruction will not retire).

I'm willing to believe that there could be other functions in the
kernel other than BPF which are also vulnerable, but which haven't
been discovered.  If somebody builds a compiler-level fix for this
then that could address the problem more completely.  I wouldn't be
surprised if they're discovering variants of this for a while.  Short
of disabling cache updates during speculative execution entirely I'm
not sure Spectre can be solved at the hardware level, and that
probably would have a big performance impact.


-- 
Rich

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[R0b0t1]

On Thu, Jan 4, 2018 at 10:18 AM, Rich Freeman  wrote:
> On Thu, Jan 4, 2018 at 10:44 AM, R0b0t1  wrote:
>>
>> I am still working through the information myself, but it looks like
>> BPF filters are an easy way to make sure you have something to look
>> for in kernelspace.
>
> My understanding is that for exploit 1 to work you need to have the
> kernel execute some code for you, and BPF is a way to do that because
> it is a JIT compiler.
>
> The bits about finding where BPF is in kernelspace is for exploit 2,
> which requires branching into that code, which requires knowing its
> address.
>

What I think is missing is the full details of the cache behavior,
because I saw some (ad hoc) proposals that the situation may be very,
very bad indeed. I'll see if I can find the explanation involving only
usermode code.

The original recommendation from CERT was to fully replace all
hardware: 
https://webcache.googleusercontent.com/search?q=cache:rzc6iQmgrIcJ:https://www.kb.cert.org/vuls/id/584653+=4=en=clnk=us

>> On Thu, Jan 4, 2018 at 9:44 AM, R0b0t1  wrote:
>>> But, if they do,
>>
>> then AMD processors are susceptible in the same way, and the issue can
>> not be fixed. There are some news pieces and commenters claiming that
>> AMD processors suffer similar issues.
>
> AMD published this:
> https://www.amd.com/en/corporate/speculative-execution
>
> This tends to go along with Google's statement that AMD is vulnerable
> to variant 1, but not 2 or 3.
>
> There is plenty of speculation going on with the hazy info that was
> provided, but none of the original sources suggest that AMD is
> vulnerable to variant 3.  For variants 1/2 Google says that AMD is
> susceptible to only 1, and the white paper says that they're
> vulnerable to either 1/2 but they don't say which specifically.
>
> In any case, short of somebody publishing actual exploit code so that
> people can run their own tests, I'm going to go with AMD.  Nobody
> reputable is outright contradicting their statements.  For variant 1
> the only known vulnerability is BPF which probably next to nobody
> uses, and for variant 2 there really aren't any alternatives available
> right now anyway.
>

I think referring to BPF is a red herring, because it is really the
processor that is at fault. Not BPF. And yes, I'm aware of what AMD
claims.

Cheers,
 R0b0t1

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Rich Freeman]

On Thu, Jan 4, 2018 at 8:52 PM, Jalus Bilieyich  wrote:
> Is my Pentium D from 2007 affected?
>

Any Intel x86 chip after and including the Pentium Pro should be
affected.  That came out in 1995.  The Pentium D is almost certainly
vulnerable.

-- 
Rich

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Jalus Bilieyich]

Is my Pentium D from 2007 affected?

On 01/03/2018 09:34 PM, Adam Carter wrote:
>>
>> Project Zero (Google) found it;
>> https://googleprojectzero.blogspot.com.au/2018/01/
>> reading-privileged-memory-with-side.html
>>
>> Phoronix has done some benchmarks on the impact of the kernel based
>> workaround ([Kernel] Page Table Isolation (PSI) nee Kaiser)
>> https://www.phoronix.com/scan.php?page=article=linux-
>> more-x86pti=1
>>
>>
> Re:AMD  - Looks like Linus agrees that PTI is not required for AMD CPUs.
> Note that the project zero blog mentions that some AMD chips are subject to
> some issues*. *There's three CVEs
> *.*
> 
> From:
> https://www.phoronix.com/scan.php?page=news_item=Linux-Tip-Git-Disable-x86-PTI
> *"Update:* Linus Torvalds has now ended up pulling
> 
> the latest PTI fixes that also include the change to disable page table
> isolation for now on all AMD CPUs. The commit is in mainline for Linux 4.15
> along with a few basic fixes and ensuring PAGE_TABLE_ISOLATION is enabled
> by default. "
> 

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Rich Freeman]

On Thu, Jan 4, 2018 at 10:44 AM, R0b0t1  wrote:
>
> I am still working through the information myself, but it looks like
> BPF filters are an easy way to make sure you have something to look
> for in kernelspace.

My understanding is that for exploit 1 to work you need to have the
kernel execute some code for you, and BPF is a way to do that because
it is a JIT compiler.

The bits about finding where BPF is in kernelspace is for exploit 2,
which requires branching into that code, which requires knowing its
address.

> On Thu, Jan 4, 2018 at 9:44 AM, R0b0t1  wrote:
>> But, if they do,
>
> then AMD processors are susceptible in the same way, and the issue can
> not be fixed. There are some news pieces and commenters claiming that
> AMD processors suffer similar issues.

AMD published this:
https://www.amd.com/en/corporate/speculative-execution

This tends to go along with Google's statement that AMD is vulnerable
to variant 1, but not 2 or 3.

There is plenty of speculation going on with the hazy info that was
provided, but none of the original sources suggest that AMD is
vulnerable to variant 3.  For variants 1/2 Google says that AMD is
susceptible to only 1, and the white paper says that they're
vulnerable to either 1/2 but they don't say which specifically.

In any case, short of somebody publishing actual exploit code so that
people can run their own tests, I'm going to go with AMD.  Nobody
reputable is outright contradicting their statements.  For variant 1
the only known vulnerability is BPF which probably next to nobody
uses, and for variant 2 there really aren't any alternatives available
right now anyway.

-- 
Rich

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[R0b0t1]

On Thu, Jan 4, 2018 at 9:44 AM, R0b0t1  wrote:
> But, if they do,

then AMD processors are susceptible in the same way, and the issue can
not be fixed. There are some news pieces and commenters claiming that
AMD processors suffer similar issues.

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[R0b0t1]

On Thu, Jan 4, 2018 at 8:17 AM, Rich Freeman  wrote:
> On Thu, Jan 4, 2018 at 8:44 AM, Corbin Bird  wrote:
>>
>> According to the Project Zero documentation  having BPF JIT enabled
>> is the key to the exploit.
>>
>> The way the docs read ... can it be assumed that by having BPF JIT
>> disabled on an AMD, that blocks this exploit?
>>
>
> I'm still working through the details, but AMD seems to only be
> vulnerable to variant 1 (based on AMD's reports), and for Linux that
> requires that BPF JIT be both built into the kernel (compile-time),
> and enabled in sysctl (net.core.bpf_jit_enable).  From what I can tell
> variant 1 requires that the vulnerable code actually be executed in
> the kernel security context.  I'm sure a fix to BPF will be made to
> close that.  There might also be some other code that can be tricked
> in the kernel but there are no reports of this.
>
> For variant 2 (not exploitable on AMD), it sounds like the BPF code
> need merely be present in kernel virtual memory while running in user
> security context.  That would mean that it would need to be built at
> compile-time, and loaded (if in a module), but it wouldn't have to be
> enabled in sysctl.  I didn't see any mention of it but I would think
> that the PTI fixes might close this hole on Intel, since then when the
> CPU is in user security context the BPF code would not be present in
> virtual memory.  Intel posted a separate compile-time fix to lkml
> yesterday as well, with an amusing response from Linus in his usual
> style, and an even more amusing subsequent joke about needing to add a
> perl interpreter to the kernel.
>
> Variant 1 does exploit CPU behavior, but I suspect it could be fixed
> with a change to gcc to recognize these kinds of indirect memory
> references and ensure they're not executed speculatively.  That fix
> would be applicable to anything that runs untrusted code in a sandbox,
> such as browsers.  That variant isn't about crossing CPU privilege
> boundaries so much as getting code that is legitimately being run to
> leak state through the cache as a backchannel.
>
> Note: I'm not an expert on any of this stuff, and if somebody wants to
> chime in with details/adjustments to the above I'm all ears.
>

I think this is missing the point - this specific attack may be tied
to BPF, but disabling BPF does not remove the underlying cause, which
is speculatively executed instructions modifying the processor state.
When news pieces are claiming that there is no way to fix this problem
save changing the hardware or taking a huge execution penalty they are
right.

I am still working through the information myself, but it looks like
BPF filters are an easy way to make sure you have something to look
for in kernelspace. Since you have something to look for, you can then
start asking yes or no questions about what is in cache that is
mirroring kernelspace memory. Once you find it, you can start to look
for other kernel structures that may contain more interesting
information (private keys), and then ask questions like "are the bytes
of the private key at position X equal to Y?" Eventually, you can read
arbitrary memory.

There are pieces claiming the details of the full attack allows
writing to kernel memory, and I suspect it is far easier in practice
to do the things detailed above. If AMD is not susceptible to one of
the attacks, that is because speculatively executed instructions do
not update the cache. But, if they do,

It is likely we will need to wait for the full details to be released
once the problem is addressed in secret.

Cheers,
 R0b0t1

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Corbin Bird]

On 01/04/2018 08:17 AM, Rich Freeman wrote:
> On Thu, Jan 4, 2018 at 8:44 AM, Corbin Bird  wrote:
>> According to the Project Zero documentation  having BPF JIT enabled
>> is the key to the exploit.
>>
>> The way the docs read ... can it be assumed that by having BPF JIT
>> disabled on an AMD, that blocks this exploit?
>>
> I'm still working through the details, but AMD seems to only be
> vulnerable to variant 1 (based on AMD's reports), and for Linux that
> requires that BPF JIT be both built into the kernel (compile-time),
> and enabled in sysctl (net.core.bpf_jit_enable).  From what I can tell
> variant 1 requires that the vulnerable code actually be executed in
> the kernel security context.  I'm sure a fix to BPF will be made to
> close that.  There might also be some other code that can be tricked
> in the kernel but there are no reports of this.
>
> For variant 2 (not exploitable on AMD), it sounds like the BPF code
> need merely be present in kernel virtual memory while running in user
> security context.  That would mean that it would need to be built at
> compile-time, and loaded (if in a module), but it wouldn't have to be
> enabled in sysctl.  I didn't see any mention of it but I would think
> that the PTI fixes might close this hole on Intel, since then when the
> CPU is in user security context the BPF code would not be present in
> virtual memory.  Intel posted a separate compile-time fix to lkml
> yesterday as well, with an amusing response from Linus in his usual
> style, and an even more amusing subsequent joke about needing to add a
> perl interpreter to the kernel.
>
> Variant 1 does exploit CPU behavior, but I suspect it could be fixed
> with a change to gcc to recognize these kinds of indirect memory
> references and ensure they're not executed speculatively.  That fix
> would be applicable to anything that runs untrusted code in a sandbox,
> such as browsers.  That variant isn't about crossing CPU privilege
> boundaries so much as getting code that is legitimately being run to
> leak state through the cache as a backchannel.
>
> Note: I'm not an expert on any of this stuff, and if somebody wants to
> chime in with details/adjustments to the above I'm all ears.
>

So  kill all BPF JIT support / leave BPF JIT out of the kernel / no
kernel modules either == attack Variant #1 fails.
The "current workaround" ( for AMD CPU's ) is how I read it.

Thanks for the info.

Corbin

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Rich Freeman]

On Thu, Jan 4, 2018 at 8:44 AM, Corbin Bird  wrote:
>
> According to the Project Zero documentation  having BPF JIT enabled
> is the key to the exploit.
>
> The way the docs read ... can it be assumed that by having BPF JIT
> disabled on an AMD, that blocks this exploit?
>

I'm still working through the details, but AMD seems to only be
vulnerable to variant 1 (based on AMD's reports), and for Linux that
requires that BPF JIT be both built into the kernel (compile-time),
and enabled in sysctl (net.core.bpf_jit_enable).  From what I can tell
variant 1 requires that the vulnerable code actually be executed in
the kernel security context.  I'm sure a fix to BPF will be made to
close that.  There might also be some other code that can be tricked
in the kernel but there are no reports of this.

For variant 2 (not exploitable on AMD), it sounds like the BPF code
need merely be present in kernel virtual memory while running in user
security context.  That would mean that it would need to be built at
compile-time, and loaded (if in a module), but it wouldn't have to be
enabled in sysctl.  I didn't see any mention of it but I would think
that the PTI fixes might close this hole on Intel, since then when the
CPU is in user security context the BPF code would not be present in
virtual memory.  Intel posted a separate compile-time fix to lkml
yesterday as well, with an amusing response from Linus in his usual
style, and an even more amusing subsequent joke about needing to add a
perl interpreter to the kernel.

Variant 1 does exploit CPU behavior, but I suspect it could be fixed
with a change to gcc to recognize these kinds of indirect memory
references and ensure they're not executed speculatively.  That fix
would be applicable to anything that runs untrusted code in a sandbox,
such as browsers.  That variant isn't about crossing CPU privilege
boundaries so much as getting code that is legitimately being run to
leak state through the cache as a backchannel.

Note: I'm not an expert on any of this stuff, and if somebody wants to
chime in with details/adjustments to the above I'm all ears.

-- 
Rich

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Corbin Bird]

On 01/03/2018 09:34 PM, Adam Carter wrote:
>
> Project Zero (Google) found it;
> 
> https://googleprojectzero.blogspot.com.au/2018/01/reading-privileged-memory-with-side.html
> 
> 
>
>
> Phoronix has done some benchmarks on the impact of the kernel
> based workaround ([Kernel] Page Table Isolation (PSI) nee Kaiser)
> 
> https://www.phoronix.com/scan.php?page=article=linux-more-x86pti=1
> 
> 
>
>
> *
> *
> Re:AMD  - Looks like Linus agrees that PTI is not required for AMD
> CPUs. Note that the project zero blog mentions that some AMD chips are
> subject to some issues*. *There's three CVEs*.
> *
> *
> *
> From:
> https://www.phoronix.com/scan.php?page=news_item=Linux-Tip-Git-Disable-x86-PTI*
> *
> *"Update:* Linus Torvalds has now ended up pulling
> 
> the latest PTI fixes that also include the change to disable page
> table isolation for now on all AMD CPUs. The commit is in mainline for
> Linux 4.15 along with a few basic fixes and ensuring
> PAGE_TABLE_ISOLATION is enabled by default. "

According to the Project Zero documentation  having BPF JIT enabled
is the key to the exploit.

The way the docs read ... can it be assumed that by having BPF JIT
disabled on an AMD, that blocks this exploit?

Corbin

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Adam Carter]

>
> Project Zero (Google) found it;
> https://googleprojectzero.blogspot.com.au/2018/01/
> reading-privileged-memory-with-side.html
>
> Phoronix has done some benchmarks on the impact of the kernel based
> workaround ([Kernel] Page Table Isolation (PSI) nee Kaiser)
> https://www.phoronix.com/scan.php?page=article=linux-
> more-x86pti=1
>
>
Re:AMD  - Looks like Linus agrees that PTI is not required for AMD CPUs.
Note that the project zero blog mentions that some AMD chips are subject to
some issues*. *There's three CVEs
*.*

From:
https://www.phoronix.com/scan.php?page=news_item=Linux-Tip-Git-Disable-x86-PTI
*"Update:* Linus Torvalds has now ended up pulling

the latest PTI fixes that also include the change to disable page table
isolation for now on all AMD CPUs. The commit is in mainline for Linux 4.15
along with a few basic fixes and ensuring PAGE_TABLE_ISOLATION is enabled
by default. "

Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Adam Carter]

On Thu, Jan 4, 2018 at 2:15 PM, P Levine  wrote:

> I'm not sure if it's been mentioned here before but there apparently is a
> bug affecting all Intel CPUs manufactured in the last 10 years or so, in
> which protected kernel memory is leaked to userspace.  It can't be patched
> in microcode and will lead to some serious overhead to patch in the OS.
> See, Huge Intel CPU Bug Allegedly Causes Kernel Memory Vulnerability With
> Up To 30% Performance Hit In Windows And Linux
> 
>  and Meltdown and Spectre .
>
> Reported at Bug 643360 .
>

Its been mentioned in another thread, but I guess its a bit off topic there.

Project Zero (Google) found it;
https://googleprojectzero.blogspot.com.au/2018/01/reading-privileged-memory-with-side.html

Phoronix has done some benchmarks on the impact of the kernel based
workaround ([Kernel] Page Table Isolation (PSI) nee Kaiser)
https://www.phoronix.com/scan.php?page=article=linux-more-x86pti=1

[gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[P Levine]

I'm not sure if it's been mentioned here before but there apparently is a
bug affecting all Intel CPUs manufactured in the last 10 years or so, in
which protected kernel memory is leaked to userspace.  It can't be patched
in microcode and will lead to some serious overhead to patch in the OS.
See, Huge Intel CPU Bug Allegedly Causes Kernel Memory Vulnerability With
Up To 30% Performance Hit In Windows And Linux

 and Meltdown and Spectre .

Reported at Bug 643360 .