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  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] 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 
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 Fri, Jan 5, 2018 at 7:26 PM, 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
>

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

[Adam Carter]

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

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

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

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

[Adam Carter]

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

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  wrote:
> On Fri, Jan 5, 2018 at 8:39 AM, 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.
>>
>
> 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]

On Fri, Jan 5, 2018 at 8:39 AM, 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.
>
>
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."