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

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

[P Levine]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

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
<https://hothardware.com/news/intel-cpu-bug-kernel-memory-isolation-linux-windows-macos>
 and Meltdown and Spectre <https://meltdownattack.com/>.

Reported at Bug 643360 <https://bugs.gentoo.org/643360>.

[-- Attachment #2: Type: text/html, Size: 958 bytes --]

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

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

On Thu, Jan 4, 2018 at 2:15 PM, P Levine <plevine457@gmail.com> 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
> <https://hothardware.com/news/intel-cpu-bug-kernel-memory-isolation-linux-windows-macos>
>  and Meltdown and Spectre <https://meltdownattack.com/>.
>
> Reported at Bug 643360 <https://bugs.gentoo.org/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&item=linux-more-x86pti&num=1

[-- Attachment #2: Type: text/html, Size: 2379 bytes --]

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

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

>
> 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&item=linux-
> more-x86pti&num=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&px=Linux-Tip-Git-Disable-x86-PTI
*"Update:* Linus Torvalds has now ended up pulling
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=00a5ae218d57741088068799b810416ac249a9ce&utm_source=anz>
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. "

[-- Attachment #2: Type: text/html, Size: 2106 bytes --]

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
>     <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&item=linux-more-x86pti&num=1
>     <https://www.phoronix.com/scan.php?page=article&item=linux-more-x86pti&num=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&px=Linux-Tip-Git-Disable-x86-PTI*
> *
> *"Update:* Linus Torvalds has now ended up pulling
> <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=00a5ae218d57741088068799b810416ac249a9ce&utm_source=anz>
> 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

[Rich Freeman]

On Thu, Jan 4, 2018 at 8:44 AM, Corbin Bird <corbinbird@charter.net> 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/04/2018 08:17 AM, Rich Freeman wrote:
> On Thu, Jan 4, 2018 at 8:44 AM, Corbin Bird <corbinbird@charter.net> 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

[R0b0t1]

On Thu, Jan 4, 2018 at 8:17 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, Jan 4, 2018 at 8:44 AM, Corbin Bird <corbinbird@charter.net> 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

[R0b0t1]

On Thu, Jan 4, 2018 at 9:44 AM, R0b0t1 <r030t1@gmail.com> 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

[Rich Freeman]

On Thu, Jan 4, 2018 at 10:44 AM, R0b0t1 <r030t1@gmail.com> 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 <r030t1@gmail.com> 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

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

[Nikos Chantziaras]

On 04/01/18 18:18, Rich Freeman wrote:
> For variant 1 the only known vulnerability is BPF which probably
> next to nobody uses

I had to enable various BPF settings in the kernel because systemd 
wouldn't shut up about it. It prints warning messages during boot that 
the system doesn't support BPF. After enabling it, systemd was happy and 
stopped barking at me.

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

[Nikos Chantziaras]

On 04/01/18 23:39, Nikos Chantziaras wrote:
> On 04/01/18 18:18, Rich Freeman wrote:
>> For variant 1 the only known vulnerability is BPF which probably
>> next to nobody uses
> 
> I had to enable various BPF settings in the kernel because systemd 
> wouldn't shut up about it. It prints warning messages during boot that 
> the system doesn't support BPF. After enabling it, systemd was happy and 
> stopped barking at me.

https://github.com/systemd/systemd/issues/7188

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

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

On Fri, Jan 5, 2018 at 8:39 AM, Nikos Chantziaras <realnc@gmail.com> wrote:

> On 04/01/18 18:18, Rich Freeman wrote:
>
>> For variant 1 the only known vulnerability is BPF which probably
>> next to nobody uses
>>
>
> I had to enable various BPF settings in the kernel because systemd
> wouldn't shut up about it. It prints warning messages during boot that the
> system doesn't support BPF. After enabling it, systemd was happy and
> stopped barking at me.
>
>
The vulnerability specifically mentions EBPF and JIT so I'd say its
CONFIG_HAVE_EBPF_JIT, but there's also CONFIG_BPF_JIT.

I notice EBPF_JIT is =y in my .config, grepping the sysctl -a output for
bpf only returns;
kernel.unprivileged_bpf_disabled = 0
And
https://github.com/linuxkit/linuxkit/commit/720fb219cea1fea99c2bba1d01f771eb43b2000b
"On 4.9.x and 4.14.x kernels ebpf verifier bugs allow ebpf programs to
access (read/write) random memory. Setting
kernel.unprivileged_bpf_disabled=1 mitigates this somewhat until it is
fixed upstream."

[-- Attachment #2: Type: text/html, Size: 2224 bytes --]

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

[Rich Freeman]

On Thu, Jan 4, 2018 at 7:51 PM, Adam Carter <adamcarter3@gmail.com> wrote:
> On Fri, Jan 5, 2018 at 8:39 AM, Nikos Chantziaras <realnc@gmail.com> wrote:
>>
>> On 04/01/18 18:18, Rich Freeman wrote:
>>>
>>> For variant 1 the only known vulnerability is BPF which probably
>>> next to nobody uses
>>
>>
>> I had to enable various BPF settings in the kernel because systemd
>> wouldn't shut up about it. It prints warning messages during boot that the
>> system doesn't support BPF. After enabling it, systemd was happy and stopped
>> barking at me.
>>
>
> The vulnerability specifically mentions EBPF and JIT so I'd say its
> CONFIG_HAVE_EBPF_JIT, but there's also CONFIG_BPF_JIT.
>
> I notice EBPF_JIT is =y in my .config, grepping the sysctl -a output for bpf
> only returns;
> kernel.unprivileged_bpf_disabled = 0

The settings relevant to Spectre are:
CONFIG_BPF_JIT - this being set to y is enough to make Intel
processors vulnerable to variant 1/2.  This being set to y is
necessary, but not sufficient, for making AMD vulnerable to variant 1.
net.core.bpf_jit_enable - this being set to 1 along with the config
option being set is sufficient to make AMD vulnerable to variant 1.
This setting has no effect on making Intel vulnerable to variant 1 or
2.  I suspect this sysctl item won't appear unless it is loaded into
the kernel in the first place.

I believe CONFIG_HAVE_EBPF_JIT isn't actually modifiable via make
config - it is a dependency and I think it is there to indicate
whether the feature is supported (maybe it is arch-specific, or there
is some complex rule for it being available - I didn't dig through the
Makefiles).

I don't think either of these need to be set for systemd.  The
settings referenced in that issue are CONFIG_CGROUP_BPF and
CONFIG_BPF_SYSCALL.  I wouldn't be surprised if at some point BPF_JIT
gets patched to block Spectre, but that hasn't happened yet.

-- 
Rich

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

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

>
> The settings relevant to Spectre are:
> CONFIG_BPF_JIT - this being set to y is enough to make Intel
> processors vulnerable to variant 1/2.  This being set to y is
> necessary, but not sufficient, for making AMD vulnerable to variant 1.
> net.core.bpf_jit_enable - this being set to 1 along with the config
> option being set is sufficient to make AMD vulnerable to variant 1.
> This setting has no effect on making Intel vulnerable to variant 1 or
> 2.  I suspect this sysctl item won't appear unless it is loaded into
> the kernel in the first place.


Thanks for the clarification. I checked my three systemd systems and all
are;
# CONFIG_BPF_JIT is not set

systemd ebuild is looking for;
$ grep -i bpf /usr/portage/sys-apps/systemd/systemd-2*
/usr/portage/sys-apps/systemd/systemd-235-r1.ebuild:        kernel_is -ge 4
10 && CONFIG_CHECK+=" ~CGROUP_BPF"
/usr/portage/sys-apps/systemd/systemd-236-r4.ebuild:        kernel_is -ge 4
10 && CONFIG_CHECK+=" ~CGROUP_BPF"

[-- Attachment #2: Type: text/html, Size: 1396 bytes --]

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

[Peter Humphrey]

On Friday, 5 January 2018 01:18:23 GMT Rich Freeman wrote:

> I believe CONFIG_HAVE_EBPF_JIT isn't actually modifiable via make
> config - it is a dependency and I think it is there to indicate
> whether the feature is supported (maybe it is arch-specific, or there
> is some complex rule for it being available - I didn't dig through the
> Makefiles).

Just to confirm that, menuconfig here shows:

Symbol: HAVE_EBPF_JIT [=y]                                                                  
│
│ Type  : boolean                                                                               
│   Defined at net/Kconfig:436                                                                  
│   Selected by: X86 [=y] && X86_64 [=y]                                                      

So it's on, like it or not. This is kernel 4.9.72 on an i7-5820K.

-- 
Regards,
Peter.

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

[Ian Zimmerman]

On 2018-01-05 11:10, Peter Humphrey wrote:

> Symbol: HAVE_EBPF_JIT [=y]                                                                  
> │
> │ Type  : boolean
> │   Defined at net/Kconfig:436
> │   Selected by: X86 [=y] && X86_64 [=y]                                                      
> 
> So it's on, like it or not. This is kernel 4.9.72 on an i7-5820K.

As Rich writes, the HAVE_* symbols are not settable via the UI, and in
fact do not toggle the inclusion of any code; they are automatically set
by kconfig to record the _availability_ of some features on the system,
based on given constraints such as architecture and memory model.

So, HAVE_EBPF_JIT=y just means that BPF JIT _can_ be done on x86.  There
is a separate BPF_JIT setting to actually enable it.

-- 
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.

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

[Peter Humphrey]

On Friday, 5 January 2018 18:04:10 GMT Ian Zimmerman wrote:
> On 2018-01-05 11:10, Peter Humphrey wrote:
> > Symbol: HAVE_EBPF_JIT [=y]
> > │
> > │ Type  : boolean
> > │   Defined at net/Kconfig:436
> > │   Selected by: X86 [=y] && X86_64 [=y]
> > 
> > So it's on, like it or not. This is kernel 4.9.72 on an i7-5820K.
> 
> As Rich writes, the HAVE_* symbols are not settable via the UI, and in
> fact do not toggle the inclusion of any code; they are automatically set
> by kconfig to record the _availability_ of some features on the system,
> based on given constraints such as architecture and memory model.

I didn't read that in what Rich wrote, but it's useful anyway - thanks.

> So, HAVE_EBPF_JIT=y just means that BPF JIT _can_ be done on x86.  There
> is a separate BPF_JIT setting to actually enable it.

Well, that doesn't seem to be present here. Just the HAVE_ symbol.

-- 
Regards,
Peter.

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

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

>
> > So, HAVE_EBPF_JIT=y just means that BPF JIT _can_ be done on x86.  There
> > is a separate BPF_JIT setting to actually enable it.
>
> Well, that doesn't seem to be present here. Just the HAVE_ symbol.


Careful, there's BPF and EBPF.

$ zgrep BPF /proc/config.gz
CONFIG_CGROUP_BPF=y
CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
# CONFIG_NETFILTER_XT_MATCH_BPF is not set
# CONFIG_NET_CLS_BPF is not set
# CONFIG_NET_ACT_BPF is not set
# CONFIG_BPF_JIT is not set
# CONFIG_BPF_STREAM_PARSER is not set
CONFIG_HAVE_EBPF_JIT=y
# CONFIG_TEST_BPF is not set

[-- Attachment #2: Type: text/html, Size: 923 bytes --]

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

[Rich Freeman]

On Fri, Jan 5, 2018 at 7:26 PM, Adam Carter <adamcarter3@gmail.com> wrote:
>> > So, HAVE_EBPF_JIT=y just means that BPF JIT _can_ be done on x86.  There
>> > is a separate BPF_JIT setting to actually enable it.
>>
>> Well, that doesn't seem to be present here. Just the HAVE_ symbol.
>
>
> Careful, there's BPF and EBPF.
>
> $ zgrep BPF /proc/config.gz
> CONFIG_CGROUP_BPF=y
> CONFIG_BPF=y
> CONFIG_BPF_SYSCALL=y
> # CONFIG_NETFILTER_XT_MATCH_BPF is not set
> # CONFIG_NET_CLS_BPF is not set
> # CONFIG_NET_ACT_BPF is not set
> # CONFIG_BPF_JIT is not set
> # CONFIG_BPF_STREAM_PARSER is not set
> CONFIG_HAVE_EBPF_JIT=y
> # CONFIG_TEST_BPF is not set
>

In this context they're the same thing.  The only use of "EBPF" is
that internal dependency, which might be why nobody bothered to try to
change it.

-- 
Rich

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

[Walter Dnes]

On Sat, Jan 06, 2018 at 11:26:43AM +1100, Adam Carter wrote
> >
> > > So, HAVE_EBPF_JIT=y just means that BPF JIT _can_ be done on x86.  There
> > > is a separate BPF_JIT setting to actually enable it.
> >
> > Well, that doesn't seem to be present here. Just the HAVE_ symbol.
> 
> 
> Careful, there's BPF and EBPF.
> 
> $ zgrep BPF /proc/config.gz
> CONFIG_CGROUP_BPF=y
> CONFIG_BPF=y
> CONFIG_BPF_SYSCALL=y
> # CONFIG_NETFILTER_XT_MATCH_BPF is not set
> # CONFIG_NET_CLS_BPF is not set
> # CONFIG_NET_ACT_BPF is not set
> # CONFIG_BPF_JIT is not set
> # CONFIG_BPF_STREAM_PARSER is not set
> CONFIG_HAVE_EBPF_JIT=y
> # CONFIG_TEST_BPF is not set

  I'm running openrc.  On my 32-bit install, Intel Core2 duo, I get...

zgrep BPF /proc/config.gz
CONFIG_BPF=y
# CONFIG_BPF_SYSCALL is not set
# CONFIG_NETFILTER_XT_MATCH_BPF is not set
# CONFIG_TEST_BPF is not set

  On my 64-bit install, Intel Silvermont (Atom), I get...

zgrep BPF /proc/config.gz
CONFIG_BPF=y
# CONFIG_BPF_SYSCALL is not set
# CONFIG_NETFILTER_XT_MATCH_BPF is not set
# CONFIG_BPF_JIT is not set
CONFIG_HAVE_EBPF_JIT=y
# CONFIG_TEST_BPF is not set

  Does this improve security at all versus meltdown/spectre?  Any
suggestions for changes?

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Rich Freeman]

On Sat, Jan 6, 2018 at 8:58 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>
>   I'm running openrc.  On my 32-bit install, Intel Core2 duo, I get...
>
> zgrep BPF /proc/config.gz
> CONFIG_BPF=y
> # CONFIG_BPF_SYSCALL is not set
> # CONFIG_NETFILTER_XT_MATCH_BPF is not set
> # CONFIG_TEST_BPF is not set
>
>   On my 64-bit install, Intel Silvermont (Atom), I get...
>
> zgrep BPF /proc/config.gz
> CONFIG_BPF=y
> # CONFIG_BPF_SYSCALL is not set
> # CONFIG_NETFILTER_XT_MATCH_BPF is not set
> # CONFIG_BPF_JIT is not set
> CONFIG_HAVE_EBPF_JIT=y
> # CONFIG_TEST_BPF is not set
>
>   Does this improve security at all versus meltdown/spectre?  Any
> suggestions for changes?

Intel hardware is vulnerable to Spectre variant 1, and Meltdown,
regardless of any kernel settings, unless the kernel is patched to
defeat it.  I'm less sure about whether you're vulnerable to Spectre
variant 2 with JIT BPF turned off.  PTI is required to defeat Meltdown
on Intel hardware.  I don't think a patch to Spectre is in the stable
linux kernel yet, though it seems like Redhat may have pushed out some
kind of patch for it (possibly in conjunction with a microcode update
to enable it).

Disabling BPF JIT (which is the default state) does defeat the known
Spectre attacks on AMD hardware, and AMD hardware is immune to
Meltdown.

Note that this is only talking about the kernel.  Userspace code can
also be vulnerable to cross-process Spectre attacks (particularly
browsers) and those require specific hardening as well at the software
level.  On Gentoo we would get the benefit that if a gcc-level fix is
developed we could harden everything at once with a complete rebuild.
However, at this time gcc hasn't been patched.  There is plenty of
talk of it though.  Some of the proposed solutions also need CPU
microcode updates to enable them.  The idea is that gcc would insert
instructions in sensitive locations to fence in speculative execution,
and the microcode would get the CPU to respect these boundaries.

Intel has published this regarding their hardware:
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf

(This is targeted more at developers than users, including OS developers.)

-- 
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 <rich0@gentoo.org> wrote:
> On Thu, Jan 4, 2018 at 10:44 AM, R0b0t1 <r030t1@gmail.com> 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+&cd=4&hl=en&ct=clnk&gl=us

>> On Thu, Jan 4, 2018 at 9:44 AM, R0b0t1 <r030t1@gmail.com> 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 9:22 PM, R0b0t1 <r030t1@gmail.com> 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

[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&item=linux-
>> more-x86pti&num=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&px=Linux-Tip-Git-Disable-x86-PTI
> *"Update:* Linus Torvalds has now ended up pulling
> <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=00a5ae218d57741088068799b810416ac249a9ce&utm_source=anz>
> 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 8:52 PM, Jalus Bilieyich <countolaf17@gmail.com> 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

[Joerg Schilling]

Rich Freeman <rich0@gentoo.org> wrote:

> On Thu, Jan 4, 2018 at 8:52 PM, Jalus Bilieyich <countolaf17@gmail.com> 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:joerg@schily.net                    (home) Jörg Schilling D-13353 Berlin
    joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'