From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Eugene Syromiatnikov <esyr@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, Kees Cook <keescook@chromium.org>,
Kai-Heng Feng <kai.heng.feng@canonical.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Alexei Starovoitov <ast@kernel.org>,
Jonathan Corbet <corbet@lwn.net>, Jiri Olsa <jolsa@kernel.org>,
brouer@redhat.com
Subject: Re: [PATCH bpf-next v2 0/3] bpf: add boot parameters for sysctl knobs
Date: Thu, 24 May 2018 09:41:08 +0200 [thread overview]
Message-ID: <20180524094108.066d885a@redhat.com> (raw)
In-Reply-To: <20180523220244.a4u25kapqbjnmpr4@ast-mbp>
On Wed, 23 May 2018 15:02:45 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> On Wed, May 23, 2018 at 02:18:19PM +0200, Eugene Syromiatnikov wrote:
> > Some BPF sysctl knobs affect the loading of BPF programs, and during
> > system boot/init stages these sysctls are not yet configured.
> > A concrete example is systemd, that has implemented loading of BPF
> > programs.
> >
> > Thus, to allow controlling these setting at early boot, this patch set
> > adds the ability to change the default setting of these sysctl knobs
> > as well as option to override them via a boot-time kernel parameter
> > (in order to avoid rebuilding kernel each time a need of changing these
> > defaults arises).
> >
> > The sysctl knobs in question are kernel.unprivileged_bpf_disable,
> > net.core.bpf_jit_harden, and net.core.bpf_jit_kallsyms.
>
> - systemd is root. today it only uses cgroup-bpf progs which require root,
> so disabling unpriv during boot time makes no difference to systemd.
> what is the actual reason to present time?
>
> - say in the future systemd wants to use so_reuseport+bpf for faster
> networking. With unpriv disable during boot, it will force systemd
> to do such networking from root, which will lower its security barrier.
> How that make sense?
>
> - bpf_jit_kallsyms sysctl has immediate effect on loaded programs.
> Flipping it during the boot or right after or any time after
> is the same thing. Why add such boot flag then?
>
> - jit_harden can be turned on by systemd. so turning it during the boot
> will make systemd progs to be constant blinded.
> Constant blinding protects kernel from unprivileged JIT spraying.
> Are you worried that systemd will attack the kernel with JIT spraying?
I think you are missing that, we want the ability to change these
defaults in-order to avoid depending on /etc/sysctl.conf settings, and
that the these sysctl.conf setting happen too late.
For example with jit_harden, there will be a difference between the
loaded BPF program that got loaded at boot-time with systemd (no
constant blinding) and when someone reloads that systemd service after
/etc/sysctl.conf have been evaluated and setting bpf_jit_harden (now
slower due to constant blinding). This is inconsistent behavior.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Eugene Syromiatnikov <esyr@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, Kees Cook <keescook@chromium.org>,
Kai-Heng Feng <kai.heng.feng@canonical.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Alexei Starovoitov <ast@kernel.org>,
Jonathan Corbet <corbet@lwn.net>, Jiri Olsa <jolsa@kernel.org>,
brouer@redhat.com
Subject: Re: [PATCH bpf-next v2 0/3] bpf: add boot parameters for sysctl knobs
Date: Thu, 24 May 2018 09:41:08 +0200 [thread overview]
Message-ID: <20180524094108.066d885a@redhat.com> (raw)
In-Reply-To: <20180523220244.a4u25kapqbjnmpr4@ast-mbp>
On Wed, 23 May 2018 15:02:45 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> On Wed, May 23, 2018 at 02:18:19PM +0200, Eugene Syromiatnikov wrote:
> > Some BPF sysctl knobs affect the loading of BPF programs, and during
> > system boot/init stages these sysctls are not yet configured.
> > A concrete example is systemd, that has implemented loading of BPF
> > programs.
> >
> > Thus, to allow controlling these setting at early boot, this patch set
> > adds the ability to change the default setting of these sysctl knobs
> > as well as option to override them via a boot-time kernel parameter
> > (in order to avoid rebuilding kernel each time a need of changing these
> > defaults arises).
> >
> > The sysctl knobs in question are kernel.unprivileged_bpf_disable,
> > net.core.bpf_jit_harden, and net.core.bpf_jit_kallsyms.
>
> - systemd is root. today it only uses cgroup-bpf progs which require root,
> so disabling unpriv during boot time makes no difference to systemd.
> what is the actual reason to present time?
>
> - say in the future systemd wants to use so_reuseport+bpf for faster
> networking. With unpriv disable during boot, it will force systemd
> to do such networking from root, which will lower its security barrier.
> How that make sense?
>
> - bpf_jit_kallsyms sysctl has immediate effect on loaded programs.
> Flipping it during the boot or right after or any time after
> is the same thing. Why add such boot flag then?
>
> - jit_harden can be turned on by systemd. so turning it during the boot
> will make systemd progs to be constant blinded.
> Constant blinding protects kernel from unprivileged JIT spraying.
> Are you worried that systemd will attack the kernel with JIT spraying?
I think you are missing that, we want the ability to change these
defaults in-order to avoid depending on /etc/sysctl.conf settings, and
that the these sysctl.conf setting happen too late.
For example with jit_harden, there will be a difference between the
loaded BPF program that got loaded at boot-time with systemd (no
constant blinding) and when someone reloads that systemd service after
/etc/sysctl.conf have been evaluated and setting bpf_jit_harden (now
slower due to constant blinding). This is inconsistent behavior.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2018-05-24 7:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-23 12:18 [PATCH bpf-next v2 0/3] bpf: add boot parameters for sysctl knobs Eugene Syromiatnikov
2018-05-23 12:18 ` Eugene Syromiatnikov
2018-05-23 22:02 ` Alexei Starovoitov
2018-05-23 22:02 ` Alexei Starovoitov
2018-05-24 7:41 ` Jesper Dangaard Brouer [this message]
2018-05-24 7:41 ` Jesper Dangaard Brouer
2018-05-24 23:34 ` Alexei Starovoitov
2018-05-24 23:34 ` Alexei Starovoitov
2018-05-25 16:50 ` Eugene Syromiatnikov
2018-05-25 16:50 ` Eugene Syromiatnikov
2018-05-25 19:44 ` Alexei Starovoitov
2018-05-25 19:44 ` Alexei Starovoitov
2018-05-29 8:37 ` Jesper Dangaard Brouer
2018-05-29 8:37 ` Jesper Dangaard Brouer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180524094108.066d885a@redhat.com \
--to=brouer@redhat.com \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=corbet@lwn.net \
--cc=daniel@iogearbox.net \
--cc=esyr@redhat.com \
--cc=jolsa@kernel.org \
--cc=kai.heng.feng@canonical.com \
--cc=keescook@chromium.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.